ERC-205: 对合约ABI的ENS支持

简短概要

本EIP提出了一种在ENS中存储ABI定义的机制，以便调用者可以轻松查找合约接口。

摘要

ABI是与大多数合约交互所需的重要元数据。目前，它们通常是带外提供的，这给与合约的交互增加了额外的负担，尤其是在一次性交互或ABI可能随时间更新的情况下。ABI的小尺寸允许另一种解决方案，将其存储在ENS中，允许通过相同的过程进行名称查找和ABI发现。

ABI通常非常紧凑；我们能找到的最大的在用ABI，即DAO的ABI，是9450字节的未压缩JSON，6920字节的未压缩CBOR，以及1128字节的zlib压缩JSON形式。使用允许消除重复字符串的CBOR扩展，可以进一步提高CBOR编码的增益，该特性在ABI中广泛使用。然而，大多数ABI比这短得多，仅包含几百字节的未压缩JSON。

本EIP定义了一个用于检索合约ABI的解析器配置文件，以及用于存储不同应用程序的ABI的编码标准，允许用户根据其对紧凑性的需求以及其他考虑因素（如链上访问）在不同的表示形式之间进行选择。

规范

ABI编码

为了允许在链上大小和可访问性之间进行不同的权衡，定义了几种ABI编码。每种ABI编码都由一个唯一常量定义，该常量仅设置一个位，从而允许在单个uint中指定256种唯一编码。

当前公认的编码是：

将来可以通过EIP流程扩展此表。

编码类型1指定未压缩的纯文本JSON；这是ABI通常编码的标准格式，但也是最庞大的，并且不易在链上解析。

编码类型2指定zlib压缩的JSON。这比未压缩的JSON小得多，并且可以简单地在链下解码。但是，对于链上消费者来说，使用起来不切实际。

编码类型4是CBOR。CBOR是一种二进制编码格式，是JSON的超集，并且更紧凑，并且更易于在EVM等有限环境中解析。强烈建议支持CBOR的消费者也支持CBOR的stringref扩展，这可以显着减少编码大小。

编码类型8表示可以在指定的URI中的其他位置找到ABI。这通常是受支持的形式中最紧凑的，但也为实现者增加了外部依赖性。指定的URI可以使用任何schema，但是HTTP、IPFS和Swarm有望成为最常见的。

解析器配置文件

定义了一个新的解析器接口，包括以下方法：

function ABI(bytes32 node, uint256 contentType) constant returns (uint256, bytes);

该接口的接口ID为0x2203ab56。

contentType是一个位域，是调用者将接受的所有编码类型的按位OR。实现此接口的解析器必须返回使用请求格式之一编码的ABI，如果它们没有此功能的ABI，或者不支持任何请求的格式，则返回(0, "")。

abi解析器配置文件在正向和反向记录上均有效。

ABI查找过程

当尝试基于ENS名称获取ABI时，实现者应首先尝试对名称本身进行ABI查找。如果该查找未返回任何结果，则他们应尝试对该名称解析为的以太坊地址进行反向查找。

实现者应支持尽可能多的ABI编码格式。

理由

在链上存储ABI避免了为希望获取它们的应用程序引入其他依赖项的需求，例如swarm或HTTP访问。鉴于ABI的典型紧凑性，我们认为在许多情况下，这都是值得的权衡。

两步解析过程允许不同的名称为同一合约提供不同的ABI，例如，在某些情况下，为某些调用者提供最小的ABI很有用，以及为未指定自己的ABI的合约指定ABI。回退到在反向记录上查找ABI允许合约指定其自己的规范ABI，并避免了在多个名称引用同一合约而不需要不同ABI时进行复制。

版权

通过CC0放弃版权和相关权利。

Citation

Please cite this document as:

Nick Johnson <nick@ethereum.org>, "ERC-205: 对合约ABI的ENS支持 [DRAFT]," Ethereum Improvement Proposals, no. 205, February 2017. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-205.