0x04 的来世今生
以太坊从创世起就在地址 0x0000000000000000000000000000000000000004 放了一个”身份”功能：CALL 进去多少字节的输入，就原封不动返回多少字节，唯一副作用是按输入长度扣 gas。当年放它进来，是给合约一种”把数据碰一遍并为此付费”的手段。十几年过去，这个特殊地址越来越像技术债：每个客户端都要为它写一条原生代码路径，共识测试要为它维护独立用例，预编译列表每加一条，这类双边成本就再叠一层。
EVM化：搬家而不是拆除
EIP-7666 的动作只有一句话：删掉 0x04 的预编译实现，在激活它的那个区块开头，往这个地址写入一小段完成同样事情的 EVM 字节码。此后调用 0x04 就是在调用一个普通合约——有自己的代码哈希、走标准解释器、不再需要任何特殊照顾。恒等逻辑用字节码表达并不难：把 calldata 拷进内存再 RETURN，几行汇编的事。真正的工程量在”完全一样”四个字：gas 计费的逐项核对（内存扩展费、基础调用费）、返回数据的边界条件、空调用与带值调用的行为、静态上下文的语义，全部要在激活前后对得上。
它想撬动的大石头
这条 EIP 自我定位是预编译瘦身计划的排头兵：列表越短，新客户端实现门槛越低，共识分歧的表面积越小，无状态化、并行执行这类远期工程要模拟的执行环境也更干净。选择恒等预编译开刀，因为它是全列表里语义最平庸的一个——搬动它几乎不触碰真实业务合约，风险最低，最适合当路线验证。反对与疑虑同样清楚：链上有没有合约依赖了预编译与合约之间在 gas 细节上的细微差异（比如某些场景下内存计费的不同），需要一次全量链上扫描才有答案；一旦漏算某个冷门调用方，激活当天它会静默多花或者少花 gas。提案状态是 Draft，创建于 2024 年 3 月底，尚无客户端排期。
预编译与合约的差异清单
要理解风险清单为什么存在，得列出两类地址的现实差别：预编译没有代码，EXTCODESIZE、EXTCODECOPY、DELEGATECALL 等依赖代码字节的操作在两种实现下行为不同；预编译的 gas 消耗由客户端函数直接决定，不走解释器计费公式；预编译调用与合约调用的日志、回滚语义在边角情况也可能分叉。EVM 化等于把这些差异全部对齐，方向上收敛，代价是必须穷举谁在依赖差异。这也是这类”技术卫生”型提案的共同难题：收益分散在所有未来开发者头上，成本集中在一个不确定的审计里。
谁在用它，谁会受影响
身份预编译的真实用户比想象中少而专：最典型的用法是把一段数据喂给它再写进日志，为链下索引器留一份可检索的痕迹；另一些合约用它做廉价的数据触达和 gas 估算探针。这些用户恰恰是要做全量扫描才能确认迁移安全的原因——调用量小意味着它们在灰度测试里几乎不冒泡，问题只会在激活后由真实调用方撞上。反过来看，搬家的收益同样具体：无状态化路线里，每减少一个预编译，见证格式就少一类特殊分支；多客户端一致性测试少一条专用用例；未来的 zkEVM 之类兼容层少实现一段原生逻辑。0x04 是全列表里语义最空的地址，选它当第一刀，就是要用最低风险把”怎么搬”这套手术流程先跑通——流程本身比这条 EIP 的命运更有公共价值。
快速问答
问：把预编译换成合约，调用它会变贵吗？ 答：按提案意图不会——目标就是等价替换，gas 模型对表后才谈得上激活。
问：0x04 地址上不是不能部署合约吗？ 答：它是系统预留地址，普通创建机制碰不到；本提案恰是借助协议激活时在创世规则之外的一次系统写入完成搬家。
问：其他预编译会跟着搬吗？ 答：这正是提案的言外之意：如果恒等搬家的方法被证明稳妥，哈希与曲线类预编译就有了同一路径；但每条都有自己的依赖审计要做。
风险提示：本文为协议草案解读，不构成投资建议；是否激活、如何修改以官方升级公告为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。