摘要

ABI 是与大多数合约交互所需的重要元数据。目前，它们通常是在带外提供的，这给与合约交互增加了额外的负担，特别是在一次性的基础上，或者 ABI 可能会随着时间的推移而更新。由于 ABI 的体积较小，因此可以采用另一种解决方案，即将其存储在 ENS 中，然后通过相同的过程进行名称查找和 ABI 发现。

ABI 通常是非常紧凑。对于 DAO，我们能够找到的在用的最大 ABI，是 9450 字节的未压缩 JSON、6920 字节的未压缩 CBOR，以及使用 zlib 压缩 JSON 表单后的1128字节。通过使用允许消除重复字符串的 CBOR 扩展，可以在 CBOR 编码上获得进一步的增益，这在 ABI 中被广泛采用。然而，大多数 ABI 都比这个短得多，只包含几百个字节的未压缩 JSON。

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

规范

ABI 编码

为了在链上体积和可访问性之间实现不同的权衡，定义了几种 ABI 编码。每种 ABI 编码由一个唯一的常数定义，它只有一个位集，允许在一个单位中指定 256 个唯一的编码。

目前承认的编码有:

这个表将来可能会通过 ENSIP 程序进行扩展。

编码类型 1 表示明文 JSON，未压缩。这是 ABI 通常编码的标准格式，但也是最庞大的，不容易在链上解析。

编码类型 2 表示 zlib 压缩的 JSON。这比未压缩的 JSON 要小得多，而且可以直接从链下解码。然而，对于链上用户来说，这是不现实的。

编码类型 4 表示 CBOR。CBOR 是一种二进制编码格式，是 JSON 的超集，在 EVM 等有限的环境中更紧凑，也更容易解析。强烈鼓励支持 CBOR 的用户也支持对 CBOR 的 stringref 扩展，这大大减少了编码大小。

编码类型 8 表示可以通过指定的 URI 找到 ABI。这通常是受支持的表单中最紧凑的，但也为实现者增加了外部依赖。指定的 URI 可以使用任何模式，但 HTTP、IPFS 和 Swarm 应该是最常见的模式。

解析器配置

定义了一个新的解析器接口，由以下方法组成:

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

该接口的接口 ID 为 0x2203ab56。

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

abi 解析器配置对于正向和反向解析都有效。

ABI 查询过程

当试图根据 ENS 名称获取 ABI 时，实现者应该首先尝试对名称本身进行 ABI 查找。如果查找没有返回结果，他们应该尝试对该名称解析到的以太坊地址进行反向查找。

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

原理

在链上存储 ABI 使得希望获取它们的应用程序不必再引入额外依赖项，比如 Swarm 或 HTTP 访问。考虑到 ABI 的典型压缩性，我们认为在许多情况下这是一个有价值的折衷。

两步解析过程允许不同的名称为相同的合约提供不同的 ABI，例如，向一些调用者提供最小的 ABI 很有用，以及为没有指定自己的合约指定 ABI。在反向记录上查找 ABI 的方法允许合约指定它们自己的规范 ABI，并防止在多个名称引用同一个合约而不需要使用不同的 ABI 时出现重复。

版权

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