From 78d65c34be73b05b388ab9ed21d9fa37224cabdb Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Mon, 6 Feb 2017 11:46:18 +0000 Subject: [PATCH 1/6] Draft EIP for ENS support for contract ABIs --- EIPS/eip-ens-abi-lookup.md | 70 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 EIPS/eip-ens-abi-lookup.md diff --git a/EIPS/eip-ens-abi-lookup.md b/EIPS/eip-ens-abi-lookup.md new file mode 100644 index 00000000000000..4146740cb25585 --- /dev/null +++ b/EIPS/eip-ens-abi-lookup.md @@ -0,0 +1,70 @@ +## Preamble + + EIP: + Title: ENS support for contract ABIs + Author: Nick Johnson + Type: Standard Track + Category: ERCs + Status: Draft + Created: 2017-02-06 + Requires: 137, 181 + + +## Simple Summary +This EIP proposes a mechanism for storing ABI definitions in ENS, for easy lookup of contract interfaces by callers. + +## Abstract +ABIs are important metadata required for interacting with most contracts. At present, they are typically supplied out-of-band, which adds an additional burden to interacting with contracts, particularly on a one-off basis or where the ABI may be updated over time. The small size of ABIs permits an alternative solution, storing them in ENS, permitting name lookup and ABI discovery via the same process. + +ABIs are typically quite compact; the largest in-use ABI we could find, that for the DAO, is 9450 bytes uncompressed JSON, 6920 bytes uncompressed CBOR, and 1128 bytes when the JSON form is compressed with zlib. Further gains on CBOR encoding are possible using a CBOR extension that permits eliminating repeated strings, which feature extensively in ABIs. Most ABIs, however, are far shorter than this, consisting of only a few hundred bytes of uncompressed JSON. + +This EIP defines a resolver profile for retrieving contract ABIs, as well as encoding standards for storing ABIs for different applications, allowing the user to select between different representations based on their need for compactness and other considerations such as onchain access. + +## Specification +### ABI encodings +In order to allow for different tradeoffs between onchain size and accessibility, several ABI encodings are defined. Each ABI encoding is defined by a unique constant with only a single bit set, allowing for the specification of 256 unique encodings in a single uint. + +The currently recognised encodings are: + +| ID | Description | +|----|----------------------| +| 1 | JSON | +| 2 | zlib-compressed JSON | +| 4 | CBOR | +| 8 | URI | + +This table may be extended in future through the EIP process. + +Encoding type 1 specifies plaintext JSON, uncompressed; this is the standard format in which ABIs are typically encoded, but also the bulkiest, and is not easily parseable onchain. + +Encoding type 2 specifies zlib-compressed JSON. This is significantly smaller than uncompressed JSON, and is straightforward to decode offchain. However, it is impracticalfor onchain consumers to use. + +Encoding type 4 is [CBOR](http://cbor.io/). CBOR is a binary encoding format that is a superset of JSON, and is both more compact and easier to parse in limited environments such as the EVM. Consumers that support CBOR are strongly encouraged to also support the [stringref extension](http://cbor.schmorp.de/stringref) to CBOR, which provides significant additional reduction in encoded size. + +Encoding type 8 indicates that the ABI can be found elsewhere, at the specified URI. This is typically the most compact of the supported forms, but also adds external dependencies for implementers. The specified URI may use any schema, but HTTP, IPFS, and Swarm are expected to be the most common. + +### Resolver profile +A new resolver interface is defined, consisting of the following method: + + function abi(uint256 contentType) constant returns (uint256, bytes); + +The interface ID of this interface is 0xe0a8166a. + +contentType is a bitfield, and is the bitwise OR of all the encoding types the caller will accept. Resolvers that implement this interface must return an ABI encoded using one of the requested formats, or `(0, "")` if they do not have an ABI for this function, or do not support any of the requested formats. + +The `abi` resolver profile is valid on both forward and reverse records. + +### ABI lookup process + +When attempting to fetch an ABI based on an ENS name, implementers should first attempt an ABI lookup on the name itself. If that lookup returns no results, they should attempt a reverse lookup on the Ethereum address the name resolves to. + +Implementers should support as many of the ABI encoding formats as practical. + +## Rationale + +Storing ABIs onchain avoids the need to introduce additional dependencies for applications wishing to fetch them, such as swarm or HTTP access. Given the typical compactness of ABIs, we believe this is a worthwhile tradeoff in many cases. + +The two-step resolution process permits different names to provide different ABIs for the same contract, such as in the case where it's useful to provide a minimal ABI to some callers, as well as specifying ABIs for contracts that did not specify one of their own. The fallback to looking up an ABI on the reverse record permits contracts to specify their own canonical ABI, and prevents the need for duplication when multiple names reference the same contract without the need for different ABIs. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From b784a5daa403a2acea91242a0766effc105ca519 Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Mon, 6 Feb 2017 13:54:44 +0000 Subject: [PATCH 2/6] Fix signature for resolver function --- EIPS/eip-ens-abi-lookup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-ens-abi-lookup.md b/EIPS/eip-ens-abi-lookup.md index 4146740cb25585..b3062d63c17d19 100644 --- a/EIPS/eip-ens-abi-lookup.md +++ b/EIPS/eip-ens-abi-lookup.md @@ -46,9 +46,9 @@ Encoding type 8 indicates that the ABI can be found elsewhere, at the specified ### Resolver profile A new resolver interface is defined, consisting of the following method: - function abi(uint256 contentType) constant returns (uint256, bytes); + function abi(bytes32 node, uint256 contentType) constant returns (uint256, bytes); -The interface ID of this interface is 0xe0a8166a. +The interface ID of this interface is 0x83ee6bd2. contentType is a bitfield, and is the bitwise OR of all the encoding types the caller will accept. Resolvers that implement this interface must return an ABI encoded using one of the requested formats, or `(0, "")` if they do not have an ABI for this function, or do not support any of the requested formats. From b3e5913daa0da4fe8a949911c4ff6f190effadcf Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Mon, 6 Feb 2017 15:56:01 +0000 Subject: [PATCH 3/6] Rename abi to ABI to avoid name clashes --- EIPS/eip-ens-abi-lookup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-ens-abi-lookup.md b/EIPS/eip-ens-abi-lookup.md index b3062d63c17d19..db3a027ed91984 100644 --- a/EIPS/eip-ens-abi-lookup.md +++ b/EIPS/eip-ens-abi-lookup.md @@ -46,9 +46,9 @@ Encoding type 8 indicates that the ABI can be found elsewhere, at the specified ### Resolver profile A new resolver interface is defined, consisting of the following method: - function abi(bytes32 node, uint256 contentType) constant returns (uint256, bytes); + function ABI(bytes32 node, uint256 contentType) constant returns (uint256, bytes); -The interface ID of this interface is 0x83ee6bd2. +The interface ID of this interface is 0x2203ab56. contentType is a bitfield, and is the bitwise OR of all the encoding types the caller will accept. Resolvers that implement this interface must return an ABI encoded using one of the requested formats, or `(0, "")` if they do not have an ABI for this function, or do not support any of the requested formats. From 2a105007c83bc682349dba51f70534cca84f838d Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Thu, 13 Sep 2018 09:05:29 +0100 Subject: [PATCH 4/6] Update and rename eip-ens-abi-lookup.md to eip-634.md --- EIPS/{eip-ens-abi-lookup.md => eip-634.md} | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) rename EIPS/{eip-ens-abi-lookup.md => eip-634.md} (95%) diff --git a/EIPS/eip-ens-abi-lookup.md b/EIPS/eip-634.md similarity index 95% rename from EIPS/eip-ens-abi-lookup.md rename to EIPS/eip-634.md index db3a027ed91984..fdcb9b2a42a13f 100644 --- a/EIPS/eip-ens-abi-lookup.md +++ b/EIPS/eip-634.md @@ -1,14 +1,13 @@ -## Preamble - - EIP: - Title: ENS support for contract ABIs - Author: Nick Johnson - Type: Standard Track - Category: ERCs - Status: Draft - Created: 2017-02-06 - Requires: 137, 181 - +--- +eip: 634 +title: ENS support for contract ABIs +author: Nick Johnson +type: Standard Track +category: ERCs +status: Draft +created: 2017-02-06 +requires: 137, 181 +--- ## Simple Summary This EIP proposes a mechanism for storing ABI definitions in ENS, for easy lookup of contract interfaces by callers. From 6c821a12e8741e04895b5124b77719c26fb111d5 Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Thu, 13 Sep 2018 09:05:41 +0100 Subject: [PATCH 5/6] Update eip-634.md --- EIPS/eip-634.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-634.md b/EIPS/eip-634.md index fdcb9b2a42a13f..1b74051363e9a8 100644 --- a/EIPS/eip-634.md +++ b/EIPS/eip-634.md @@ -2,7 +2,7 @@ eip: 634 title: ENS support for contract ABIs author: Nick Johnson -type: Standard Track +type: Standards Track category: ERCs status: Draft created: 2017-02-06 From c17cb78fd287bd76bd3bbd563a3ae914bab313bb Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Thu, 13 Sep 2018 09:23:23 +0100 Subject: [PATCH 6/6] Update eip-634.md --- EIPS/eip-634.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-634.md b/EIPS/eip-634.md index 1b74051363e9a8..b1167773e1bf7d 100644 --- a/EIPS/eip-634.md +++ b/EIPS/eip-634.md @@ -3,7 +3,7 @@ eip: 634 title: ENS support for contract ABIs author: Nick Johnson type: Standards Track -category: ERCs +category: ERC status: Draft created: 2017-02-06 requires: 137, 181