ERC-165 照不到的角落
智能合约靠 ERC-165 的 supportsInterface 自报家门，调用方查一下就知对方接不接某个接口。但以太坊里有两类对象天生答不了这个问题：普通外部账户没有代码，无法应答任何查询；代理合约能应答，可它自己只是转发层，真正实现的接口在逻辑合约里。ERC-1820 用一句『伪自省』概括它的补丁：合约答不了或答不准的，去一张公共登记处问。
这张登记处就是一张接口实现者注册表：以地址加接口哈希为键，值是实现该接口的合约地址。接口哈希就是接口名字符串的 keccak256 哈希，比如 ERC777TokensRecipient 这个名字直接算哈希得到键值，任何能算哈希的客户端都能自行拼出键名，无需中央名录。
一张所有人共享、无人拥有的表
ERC-1820 最出名的设计是部署方式。注册表合约约定部署在固定地址：先由人类确定性地造出一串以 1820 重复为图案的 r 与 s 签名参数，从这组可预测参数恢复出一个一次性发送账户，再向该账户存入零点零八以太，然后用这笔公开挂出的原始交易把注册表代码发进去。因为签名参数是公开算出来的，任何人都能推断没有人掌握那个账户的私钥。结果是任何按此流程部署过的链上，这张表地址都分毫不差；规范也明说它可以在任意链上部署并共享同一地址。
写入权限的归属链条很清晰：每个地址的经理默认是自己，本人调用登记函数，把某接口哈希对应到某实现合约；也可以把经理权交给别的地址，交回零地址则恢复默认。普通账户登记后，查询方按约定去实现合约上调用对应回调；合约登记则用于代理场景——代理声明实现者在别处，替逻辑合约转述。
谁在真正用它
ERC-1820 是 ERC-777 的配套基建：代币合约把某地址登记为回调实现者后，转账时改调回调而非直转，让合约钱包无需 approve 陷阱也能感知入账。后来的 ERC-1363 等支付型接口也沿用同一登记约定。代价是每个链上第一次用到某接口时可能触发注册写入，且查询方与实现方都要守约——表本身只存映射，不验证实现者真能完成回调，这一点规范坦承为伪自省的伪：声明可信度来自登记流程，不来自密码学证明。此外，注册表在每条链上都是独立合约，以太坊主网的表和某条新测试网的表只是同址不同物，跨链工具不能假设数据互通。
一次查询的完整旅程
把视角切回调用方：合约想转账给一个地址并确认对方能接收回调，第一步查注册表，键是对方地址加对应接口哈希；查到非零实现者地址，就转去调用实现合约上的回调函数，期待返回那串约定的接受魔术值；查不到，再按规范回退到 ERC-165 的直连探测；还失败，按标准约定走普通转账路径。三步走完，合约无需信任任何一方，只是依次问了三个越来越基础的问题。
快速问答
问：普通地址能直接实现 ERC-165 吗？ 答：不能。外部账户无代码，这正是伪自省注册表补的洞。
问：注册表本身能被改坏吗？ 答：它没有超级管理员，各地址只能由自己或其指定的经理改自己的条目；表结构固定，没有可升级的存储布局。
一条判断线
评估一个依赖 ERC-1820 的合约，可以按两步走：先确认目标链上注册表确实存在于约定地址，再确认查询失败时的兜底路径——按规范，找不到登记时应回退到标准转账流程。一个连注册表缺失都要崩溃的合约，才是真正的不兼容。
风险提示：本文介绍合约标准机制，不构成投资建议；与合约交互前请核验其在目标链的实际状态。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。