ERC-926 地址元数据登记处：一个地址如何挂上自己的“说明页”

很多场景需要知道“这个地址对某类链上动作是什么态度”：收币前的确认偏好、能不能代理办事、有没有挂过声明。2018 年 3 月 12 日创建的 ERC-926 为此提出一张地址元数据登记表，让合约和普通账户都能向链上与链下的调用方提供元数据。按 ercs 仓库记录，这份标准状态为 Stagnant，但它的思路在后续多个提案里反复出现。

两个函数的登记处

整张表的接口只有两行：provider(target) 查询某地址的元数据登记处挂在哪个合约上，setProvider(provider) 设置指向。合约参考实现更简单——一个 address => address 的公开映射加一个写入函数，谁调用就登记谁自己。标准还设想这个登记处用约定好的 Solidity 版本编译、以信任无关的方式部署到固定地址，可以在各链复制。也就是说，地址本身不需要任何代码，只需在表上指一个方向。

提供者合约的规矩

真正干活的是被指向的“提供者合约”。规矩有三条。第一，提供者必须实现 ERC-165 的 supportsInterface，并且对接口自身的标识值 0x01ffc9a7 永远返回真；遇到不支持的函数编号必须直接抛错。第二，所有提供者函数的第一个参数必须是被查询的地址，这让一个提供者合约可以同时服务多个用户，即所谓多用户提供者。第三，一个记录类型若需要多个函数，提供者必须全实现或一个都不实现，防止半套接口误导查询方。标准还预留了一张“已标准化记录类型”的表格，供未来提案往里填。值得注意：这份原文的表格里一个条目都没有——地基画好了，房间始终没盖起来。

为什么选间接指向

设计说明里比较了两条路：像这里一样做“间接指向”，或者直接做一个通用的键值存储。前者的代价是多一次合约调用、提供者需要随时间维护；好处是灵活性远大于键值存储——提供者可以在回答里带逻辑，而不只是返回死数据。标准选了间接指向，代价换来表达力。

能说明什么

XOR、抛错与一张空表：规范文本里的三个记号

原文还有三个记号值得留意。其一在接口标识的计算规则里：接口标识等于该接口所有函数签名哈希的异或值，单函数接口就是那个函数自己的哈希——这是 ERC-165 家族通用的“指纹算术”，读任何注册表类提案都会再遇到它。其二是对失败的态度：提供者合约遇到不支持的函数编号必须直接抛错，而不是返回假或零值。这条规矩的用意是防止误读：调用方拿到的“假”只代表“不支持此函数”，不能同时兼任“不支持此功能”，两种语义必须分开。其三就是那张空表。标准列了一张“当前已标准化的提供者接口”表格作为扩展入口，未来任何 EIP 想定义新的记录类型都往里加一行；可表格从创建到停止推进始终一行都没填上。

正因为地基没有配套房间，普通用户从来不是这份标准的直接受益者，它的读者始终是协议作者。把 setProvider 想成 DNS 的 CNAME：地址本身不变，指向的说明页随时可换、可指错，也可能指向一个后来改性的合约——登记处忠实地回答“指到哪”，不承担“那页写了什么”的可信度。

登记表能说明的是：某地址在某个键上留下了一个指向，后续查询会按这个指向去问。不能说明的是：提供者合约的回答诚实、及时，或它与地址主人仍然利益一致。提供者本身是第三方合约，改逻辑、被替换都在意料之中——把“查到了元数据”当成“确认了对方的真实态度”之间，还隔着对提供者地址的一层审查。本文把这套地基讲清，是下一篇讲通用授权的前置。本文为机制说明，不构成任何投资建议。