ERC-1921 函数注册表：把合约函数登记成链上可检索条目的尝试

部署到以太坊上的合约函数，链上只留下字节码和选择器。选择器是函数签名哈希的前四个字节，工具要靠一份 ABI 文件才知道 0x 后面那串数字对应哪个函数、参数怎么解读。ERC-1921 提出的方案是把这件事反过来：让函数本身成为链上注册条目，任何工具查注册表就能重建调用所需的全部信息。这份创建于 2019 年 4 月 6 日、状态为 Stagnant 的标准是 dType 去中心化类型系统系列的一环，读它能看清”链上 ABI 目录”这个构想缺了哪块拼图。

一条函数记录长什么样

标准要求每个登记条目针对纯函数或只读函数，包含五个字段。name 是唯一可读名字；types 按 dType 定义登记每个输入的类型与标签；outputs 登记输出的类型与标签——这是相对 ERC-1900 类型定义新增的字段；contractAddress 记录函数所在的合约地址，对纯接口定义可以留空；source 是一个指向外部源码文件的字节引用。标准还给出一个 JSON 形式的注册对象示例，结构上就是把这些字段写进类型注册表的一条数据里。

接口层面提供两个换算函数：getSignatureBytes4 返回四字节选择器，getSignatureBytes32 返回三十二字节签名哈希。有了这两个函数，注册表条目和 EVM 实际执行时看到的选择器之间就有了双向通道——从可读名字算出字节，也能拿字节反查登记记录。

五个字段各自回答什么问题

拆开看，这条记录回答了调用一个函数需要的全部前置问题：叫什么、参数是什么类型、返回什么类型、去哪调用、源码在哪。前四个字段解决了 ABI 重建，第五个 source 字段把证据链延伸到可读源码，思路与后来验证过的合约源码类似，只是它指向的是外部文件引用而非直接放源码。理论上，区块浏览器可以不再依赖开发者手动上传 ABI，IDE 可以按类型拼出调用，安全分析工具能按类型筛出所有处理同一类数据的函数。

依赖的注册机制没有落地

这份标准的宿命由它依赖的 ERC-1900 决定。dType 系列设想的注册表要求所有登记走一个链上共识流程来防止重复与污染，而这等于要在以太坊上加一层”元协议”：先有可信的类型注册表，函数注册才有意义。历史上的现实走向是，链下注册表承担了同样的角色——ABI 数据库、验证过的合约源码、子图之类的索引协议，各自用中心化或半中心化方式解决了同一个问题，成本远低于给链上再加一套共识登记机制。dType 系列因此整组停在 Stagnant，ERC-1921 的五个字段也就成了纸面设计。

对普通读者的意义

标准给出的注册示例把对象形状摆得很直：一个 JSON 记录以 name 开头写着 setStaked 这样的函数名，types 数组逐项列出每个输入的类型定义与标签，outputs 列输出，再附上合约地址与源码引用。规范还限定登记对象只针对纯函数和只读函数——这两类函数不改变状态，重复执行结果一致，才适合被当作可安全重放的目录条目。这个限定透露了设计意图：注册表首先是给自动化调用准备的，工具可以放心地在目录里挑函数执行而不担心副作用，写函数则留在常规交易路径里。

这个选题的实用价值在一处细节：它提醒函数签名的四字节选择器本质上只是一段哈希前缀，不存在全局唯一保证。工具链里”按选择器识别函数”的常规做法，遇到精心构造的碰撞或仿冒合约时可能张冠李戴。凡是签名授权、批量调用类操作，核对完整函数名与参数类型，永远比只核对四个字节的前缀更稳。本文为机制说明，不构成任何投资建议。