创建交易被关上门之后：EIP-7873 的 TXCREATE 与它没保住的类型字节

一扇门焊死带来的连锁封路

EVM 对象格式（EOF）给合约立了一条铁律：代码不可被观察——合约读不了别人的字节码，也读不了自己的，一切靠内省取巧的写法（代理探测、自修改代码、运行时拼装字节码）从此物理灭绝。但这条铁律顺手掰断了三条老路：to 字段为空的创建交易、CREATE 指令、CREATE2 指令，三者在 EOF 规则下都不许再部署 EOF 代码——否则攻击者把 EOF 容器藏在创建数据里，配合可观察性就能重建偷看通道。问题是创建路径被封，EOA 连「把一个 EOF 合约放上链」都做不到。EIP-7873 在 2025 年 1 月 31 日提交，由 EOF 团队核心成员署名，专补这一下：给交易加一个专门的 initcode 快递口。按仓库原文核验时，该提案处于 Stagnant。

创建交易被关上门之后：EIP-7873 的 TXCREATE 与它没保住的类型字节图 2 — 创建交易被关上门之后：EIP-7873 的 TXCREATE 与它没保住的类型字节 · 图 2

InitcodeTransaction：一辆只装初始化码的专车

新交易类型 InitcodeTransaction 在 EIP-1559 类型二的基础上加一个字段 initcodes：一组字节串列表，上限 256 项、每项不超过 49152 字节（由 EIP-3860 的初始化码上限定义，即两倍代码上限）。配套新指令 TXCREATE 是这些字节的唯一取货口——执行到这条指令时，从列表里按下标取出对应 initcode 去创建合约，创建成本沿用固定的 32000 Gas 起价。原文特别点出它的双重身份：既让 EOA 能直接用交易数据部署 EOF 合约，也让合约之间不必再把初始化码塞进 calldata 层层转交——老 EVM 里合约想转发 initcode，得先 CREATE 配合数据加载指令绕路。费用上，initcodes 按与 calldata 同口径的按字节计费（原文引用 EIP-7623 的令牌计费约定），所以这辆车不收特权费，只是装卸口换了地方。它和 EIP-7620 的 EOFCREATE、RETURNCODE 指令构成互补：容器内置码用 EOFCREATE，外部大初始化码走 TXCREATE，两类需求都有出口。

0x06 号门牌：登记了又被收回

类型字节的选号史是这篇提案最有信息量的脚注。7873 把 INITCODE_TX_TYPE 定在 Bytes1(0x06)——当时的交易类型表里 0x06 确实空着。但到 2026 年，把交易拆成多段帧结构做验证与代付分离的 EIP-8141 把 FRAME_TX_TYPE 同样标成 0x06，两份提案之间没有引用也没有协调，类型字节登记表再度出现「一号两主」。本栏目在操作码谱系那篇里写过同样的剧本在操作码槽位反复上演，见同一个操作码位为什么两次易主：2330、2936、2542 与 8141 的谱系：先登记先得，后来者要么改号要么让路。区别在于交易类型的竞争更麻烦——类型字节决定节点解析整笔交易的入口，不可能允许两个含义并存太久，任何一份先激活，另一份的编号必然作废重选。对读提案的人，这是一条纪律：看到「类型 0x06」，永远先问是哪份文档、哪一年的语境。

部署路径演化与钱包用户的关系

普通用户与这些机制的交集通常发生一次：给自己的智能账户钱包合约做链上部署。路径表值得记牢——今天部署合约的通用方式仍是 to 为空的创建交易，工厂合约代你部署则走 CREATE2（可预测地址那条路），若未来某次升级引入 EOF，这三条路的适用边界会重画：创建交易部署 EOF 被禁，EOA 改用 InitcodeTransaction，工厂模式改走 EOFCREATE。无论门怎么换，有一条用户侧纪律不变：合约地址由「部署者加随机数/盐」推导，和初始化码走哪个字段无关，所以「先算地址后部署」的收款核验习惯在任何一代格式下都成立；反过来，凡是部署后声称「地址可能变化」的话术都值得警惕，正规部署机制不提供事后改地址的能力。

停摆状态的正确读法

EIP-7873 标注 Stagnant，与它绑定的 EOFv1 全家（EIP-7692 元提案及其十余份子提案）长期未获升级排期，属于「配套路先停工、支线自然搁置」的典型。读这类提案的正确姿势是把它的规格当作「如果走 EOF 路线、流程会是什么样」的参考设计，而不是预测它某天原样复活：历史上被搁置的部署方案复活时几乎都改了编号与参数。用户唯一需要提前记住的是，部署机制的变化不影响资产安全模型——私钥、授权、代理升级权限这三样没有一样藏在你部署用的交易类型字段里。