以太坊上找合约，今天只有一条路：先知道地址。地址是部署时算出来的，同一段代码部署一百万次就有一百万个互不相关的地址；套上代理合约，地址与代码的对应关系还可以随时改。EIP-7784 想补上反向的那一半：给定一段字节码的哈希，链上直接回答”谁装着这段代码”。具体形态是一个新操作码 GETCONTRACT（编号 0x4f，提案 2024 年 10 月创建，现处 Review 阶段）：从栈上弹出一个 32 字节哈希，如果状态里存在部署了这段字节码的合约，就把对应地址压回栈，否则压零，固定 150 gas。
内容寻址为什么值钱
按内容而不是按位置索引数据，是数据库设计的常规武器：内容哈希天然防篡改，也天然去重。搬到以太坊上，提案给了几类直接受益者。审计场景：审计师可以对”字节码哈希为 H 的代码”出具意见，而不必先绑定某一次部署的参数与存储初值——验证代码完整性不等于审计整个合约状态。白名单场景：基础设施可以先对某段尚未部署的代码给预批准，等它出现在链上时按哈希放行，开发者不必提前公开源码地址。复用场景：dApp 需要引用某个成熟代码库时，用哈希锁定比引用地址更稳——地址引用随时可能被代理换心，哈希引用则指着死死的字节序列。提案还举了协议层的例子：EIP-7702 这类机制可以让外部账户一次性挂上”哈希为 H 的临时逻辑”，用 GETCONTRACT 按哈希解析目标代码，而不指定可能被移动的地址。
索引从哪来：一条写入规则
反向查询要成立，节点必须维护一张以 keccak256(字节码) 为键的表。提案的规范写法是：每一个存入 EVM 的合约都要以代码哈希为键进入这棵索引树，但有三类例外——调用过 SELFDESTRUCT 的合约不进；已经存在的条目不重复进；以及 EXTCODEHASH 等于 keccak256(0xef01) 的那个特殊值不配拥有条目。第三条值得解释：那个哈希（0xeadc 开头的一串）是协议给”存在但只挂了 EIP-7702 委托指针的账户”规定的代码哈希——它不是可独立寻址的完整字节码，把它当作代码索引的键会把”钱包”混进”代码库”里，所以规范用一条哈希值点名排除。
硬币的另一面：谁为索引付钱
这个提案最硬的争议点不在语义而在成本：给每个合约部署多加一次”按哈希写索引”的开销，并且索引本身是一棵全量状态树，永久增大节点负担；同一代码多次部署时第一次付索引费、后续查找复用，看似省，但部署费上升对所有新合约一刀切生效。另外哈希只认”逐字节相同”：构造函数参数写进部署后代码的常规做法、哪怕一个字节的元数据差异，都会让两段功能相同的代码落在不同哈希上——想按哈希找”同类”，需要先学会按哈希找”同一份”。这些问题不否定机制本身，但决定了它长期停留在提案讨论而不是随分叉上车的速度。
与链下代码索引的分工
同方向还有一个纯应用层方案（ERC-7744），用一笔合约交易把”哈希到地址”的映射登记在链上合约里，节点与浏览器再自愿镜像其内容。两条路线回答同一个搜索问题，区别在于权威来源：操作码方案让 EVM 状态自己作证，代价是全链为索引付费；注册表方案让登记行为作证，代价是要信任”登记是否完整诚实”。理解这两种取舍，比记住任何一侧的宣传语更有用。
快速问答
问：哈希查到地址，就说明这个地址没作恶过吗？ 答：只说明字节码逐字节相同；部署参数、管理员动作与状态历史都不在哈希里。
问：一段代码部署多次，GETCONTRACT 返回哪个？ 答：内容寻址同一份字节码只有一个键；同代码多地址的取舍正是提案需要回答的问题之一。
问：现在能用吗？ 答：Review 阶段的提案，主网无此操作码。
风险提示：合约引用与白名单决策请以独立核验为准，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。