在以太坊上部署合约，老玩家熟悉的路线是 CREATE 或 CREATE2 指令，再配合一段叫 initcode 的初始化代码：先执行这段临时代码，它跑完时把真正的合约字节码返回出来，协议把返回值存成新合约的代码。EOF（EVM Object Format）改变了这一切的前提——它把合约装进带段的容器后，取消了运行前执行 initcode 的机制，CODECOPY 一类窥探代码的指令也被废掉。旧指令没法继续工作，总得有人接班，EIP-7620 就提出了 EOFCREATE 与 RETURNCODE 这对新指令。
为什么旧 CREATE 在 EOF 里活不下来
经典 CREATE 的设计依赖一个事实：initcode 和目标代码都是裸字节串，谁都能用 CODECOPY 读到。这个可观察性在 EOF 的世界观里是安全漏洞的来源——同一份代码在不同环境可能被动态改写。EOF 要求部署时代码就固定为容器，不再有一段先跑的初始化程序。于是问题变成：既然没有 initcode，那工厂合约（用自己的一部分逻辑批量生成新合约的合约）怎么办？答案是把初始化逻辑内嵌进容器本身。
一对指令的分工
RETURNCODE 类比旧的 RETURN：它出现在容器内嵌初始化段（initcontainer）的末尾，作用是声明这次部署产出的代码段是哪一段，并携带一段立即数数据，在部署时拼接到新合约代码末尾。EOFCREATE 则类似 CREATE2：接受 salt、初始化容器索引、地址推导要素与传入值，执行目标容器里的初始化段，再按把 initcode 哈希当输入的 CREATE2 式公式算出新地址。
细节上它与 CREATE2 高度对齐：地址碰撞、访问集合记账、新合约的 nonce 处理、值转账等行为，原文明确说除特别列出外与 CREATE2 相同或类推。常量方面，提案沿用创建交易成本 32000 Gas、代码入库每字节 200 Gas、调用栈深度一千零二十四这一组现行参数，没有另起炉灶。拼接在末尾的立即数意味着同一份初始化容器可以用不同后缀铸造出地址各不相同的同族合约——这正是 CREATE2 加构造参数那套玩法的容器版替身。
现状与意义
按 eips.ethereum.org 标注，EIP-7620 创建于 2024 年 2 月 12 日，状态 Stagnant；EOF 整体（EIP-7692 元提案）也因长期无活动处于 Stagnant，主网合约至今仍是经典字节码格式，CREATE 与 CREATE2 照常工作。换句话说，这对指令是为一艘尚未起航的船准备的发动机。但它的思路本身有独立价值：把合约创建从先跑一段临时程序改为在固定容器内完成，等于把部署行为完全静态化——地址可以用静态分析预计算、创建路径上没有可被窥探或篡改的裸码。如果未来某个版本重新拾起 EOF，EOFCREATE 与 RETURNCODE 大概率原样回归；如果不，这段设计也会留在合约创建机制演化的参考资料里。
对开发者的可操作结论：现有项目不需要为它做任何适配；预测地址部署继续用 CREATE2；把 EIP 状态当作路标而非时刻表，任何以 EOF 特性为前提的产品承诺都应在上线前重新核验状态页。
一条迁移直觉
回看合约创建机制的演化，会发现一条朴素规律：每次格式改革，官方都尽量让旧概念带着原语义搬家，而不是发明一套新词。EOFCREATE 照搬 CREATE2 的地址直觉，RETURNCODE 照搬 RETURN 的位置职责，连Gas常量都直接引用现行数值。对开发者，这条规律的实用价值是给未来的迁移画了安全区——今天你对 CREATE2 地址预计算、工厂模式、同族合约的全部肌肉记忆，大概率能原样带进新容器时代；反过来，任何声称要重新定义创建语义的提案，都值得先追问旧概念的去向。
快速问答
问：EOFCREATE 部署的地址还能像 CREATE2 一样预计算吗？ 答：可以，它的地址公式同样是发起者、salt、哈希参数的组合，静态可推。
问：initcontainer 和旧 initcode 最大区别？ 答：前者是容器里固定的一段代码，部署时已完整存在；后者是随交易现场提供的裸字节，可被检查、可被改写，这正是 EOF 想消灭的东西。
问：这个提案和被搁置的 EOF 是什么关系？ 答：它是 EOF 部件链上的一环，EOF 不落地它就没有生效场景，命运绑定。
风险提示：本文介绍提案机制与状态，不构成投资建议；链上部署行为请以当前主网实际规则为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。