一份 ERC 标准的核心是接口：函数叫什么、参数什么类型、返回什么。这些描述最终都要落成合约 ABI——合约间调用约定的机器可读格式，标准形式是一段 JSON。麻烦在于，早期的提案大多把接口写成 Solidity 源码或 interface 文件交差。EIP-2069 在 2017 年 2 月由 Alex Beregszaszi 提出，主张提案里应当用 YAML 来承载 ABI 描述，这份 Informational 类型的提案现标 Stagnant。
Solidity 当说明书的三个坑
提案点名了源码当规范的代价。其一，偏科：标准用哪门语言写，哪门语言就占了定义权，其他语言的工具链只能反推语法糖，新的合约语言生态被无形的天花板压着。其二，锁版本：接口定义里出现 Solidity 特定关键字后，这门语言本身升级、换语法，提案文本就得跟着改，标准被实现语言绑架。其三，泄漏细节：Solidity 的语法元素可以表达很多根本不属于 ABI 层的东西，读规范的人分不清哪句是网络级承诺、哪句只是某个编译器的口味。
JSON 与 YAML 的互补
合约 ABI 的官方表示本来就是 JSON，编译器、节点、钱包都靠它做编码解码，这没有问题。唯一的短板是 JSON 语法禁止注释——一段接口定义里没法写”这个函数在余额不足时返回假而不是抛错”这类关键说明。YAML 恰好兼容 JSON 且原生支持注释，工具间互转也很成熟。于是提案的推荐很务实：规范正文给 YAML 版 ABI 并鼓励带注释，机器需要的 JSON 随时可以转换得到。提案用 transfer 函数做了对照演示：YAML 里用两行井号讲清入参含义和返回值语义，等价 JSON 则是一板一眼的嵌套数组——同一份事实，一种给人读，一种给机器读。
为什么停在 Stagnant
这份提案不动任何共识规则，纯粹是写作建议，推进全靠社区习惯。现实走向和多数文档规范一样：Solidity 仍是 ERC 事实上的描述语言，后来更主流的附录做法是提案附一份编译产物 ABI JSON、再配自然语言章节。YAML 方案既没有形成工具链惯性，也谈不上失败——它提出的问题至今有效：凡是被多方语言实现的标准，规范层就必须与实现语言解耦。评估一份 ERC 时先找语言无关的接口描述、再对照源码，仍是防误读的第一课。
快速问答
问：ABI 和字节码是一回事吗？ 答：不是。ABI 描述函数签名、参数类型和打包规则，让人和工具知道怎么构造调用数据；字节码是合约实现本身。同一份 ABI 可以由不同语言、不同实现的合约满足。
问：看到接口定义里有 payable、external 这类词，说明什么？ 答：多半是 Solidity 视角的写法。payable 属于 ABI 关心的属性，external 只是编译器的可见性标记，不进入 ABI——这正是提案警告的细节泄漏。
一份规范的三个层次
把接口想象成三层：最底层是网络上真正交换的字节怎么编码，规则写在合约 ABI 规范里，谁实现都得遵守；中间层是函数与事件的名字和类型清单，ABI 的 JSON 描述就是它的机器形态；最上面才是给人读的语义说明——什么条件返回假、谁会拒绝、重复调用发生什么。Solidity 源码当规范的问题在于三层被揉成一段代码，读者分不清哪行属于哪层。EIP-2069 的 YAML 建议本质是给第二、三层一个共存的载体：字段清单加注释。哪怕没被广泛采纳，这条分层视角也成了后来评估任何跨语言标准的默认检查表：问一句”字节层、结构层、语义层各写在哪个文件”，含糊的项目当场现形。
与相邻标准的接力
YAML 方案之外，接口描述还有第三条路在同期生长：把函数清单直接嵌进链上字节码里供工具查询的金属数据标准。三条路各管一段——字节码内嵌利于运行时发现，规范正文里的注释利于人读，机器对机器的编码真相始终在 ABI 规范。写 EIP 时理想的做法是三样都有：接口章节用语言无关清单，附录给可编译参考，链上部署再挂一层可索引描述。读者评估标准时也照此清单验收，缺哪一环就补哪一环，比迷信任何单一文件更可靠。
风险提示：接口理解错误可能导致合约交互事故，操作前请以链上字节码与官方工具为准；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。