以太坊的预编译合约住在主网地址零一排下去的低位地址上：零一是签名验证、零二是哈希、零六是比特币哈希、零九是 BLAKE2 压缩函数。它们是写进客户端原生代码的功能插槽，与普通合约最大的区别在于——没有销毁机制。一旦上线，除非某次硬分叉明确宣判，插槽永远有效，哪怕从没人用。EIP-7266 是以太坊历史上罕见的认真尝试：给一个名存实亡的插槽送终，顺便测试死亡程序本身。
七年二万两千次调用
提案用数据开庭。blake2f 预编译随伊斯坦布尔升级在 2019 年 12 月 7 日激活（区块高度 9069000），设计动机主要是让以太坊哈希与 Zcash 体系互通、服务跨链与混合证明场景。提案统计截至 2023 年 7 月：四年半里地址 0x09 总共被调用两万两千一百三一次，最后一次发生在 2022 年 10 月 6 日——此后彻底静默。作为对照，同期哈希与签名类预编译的调用量以亿计。EIP-152 设想的用例从未在真实世界里长大，提案把这归因于入选前没有验证过任何具体需求。它进而引用黄皮书对预编译的原始定位——先用预编译试水、成熟后转成原生指令——并指出四年半的沉默已足够宣判这条路走不通。
送终的具体做法
方案干净利落：所有 CALL、CALLCODE、DELEGATECALL、STATICCALL 调用 0x09 一律进入异常中止——烧光传入的全部 Gas、不带任何返回数据。注意这不是把地址变成不存在（那会让调用静默成功返回空数据，反而可能悄悄改变依赖方的行为），而是让每一次误用都以最响的方式失败，给存量集成方最明确的警报。提案评估这对仍在使用它的项目影响面很小，留六到十二个月迁移期足够；因为改变共识规则，需硬分叉。它也不掩饰实验性质：预编译 0x09 可以被安全地当作以太坊第一次预编译退休流程的试点，为将来清理更多遗产蹚路。
只进不出的惯性
预编译机制的尴尬正在这件事上显形：它是协议里唯一只进不出的功能区。新增有 EIP 流程、评审、测试网、升级清单；移除没有任何流程存在过，因为此前根本没人提议过。每轮升级客户端团队都要继续为这些地址维持实现、测试向量与规范文档，哪怕其中部分自创世以来功能上已成化石。0x09 的特殊之处还在于它是少数语义上可以被纯软件哈希函数替代的预编译——合约里用Solidity内联汇编实现BLAKE2压缩并非不可能，只是Gas贵；这也正是它被选中当试点的原因之一：移除的经济损害最接近零。
按官方页标注，EIP-7266 创建于 2023 年 7 月 3 日，状态 Stagnant，0x09 至今仍在主网正常应答。但送终提案的遗产不在是否执行，而在它把预编译生命周期管理摆上桌面：此后讨论清理无人认领插槽时，都会引用这份文件里那组两万两千次调用数据，作为以太坊版的第一块墓碑模板。
一段历史教训
协议遗产的处置并不新鲜，以太坊自己就交过学费。曾长期可用的自毁机制最初被视为中性工具，多年间长出依赖与攻击面，最终经多轮提案才收敛为受限规则；比特币在 2010 年因安全缺陷批量禁用过一批操作码，同样先付了事故成本。这些案例的共同轨迹是：协议里的门装上容易、拆掉极难，于是新增环节的审慎会随时间变成存量环节的债务。预编译领域此前没有对应的拆除流程，7266 的送终方案——响亮失败、宽限半年、公开数据论证——即使随提案一起搁置，也把流程草案留在了公共文档里，供下一个候选插槽直接引用。
快速问答
问：为什么预编译不能像普通合约一样自毁？ 答：它们不是合约，是客户端代码里的分支，没有账户状态，也就不存在自毁语义。
问：调用一个异常中止的预编译会退回Gas吗？ 答：不，异常中止规则照常烧光调用给到的Gas，这与调用不存在的地址行为不同。
问：还有别的移除预编译提案吗？ 答：历史上对个别插槽有过零星讨论，但像本提案这样给出完整迁移论证的仅此一家。
风险提示：本文不构成投资建议；预编译状态以主网客户端实现为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。