EIP-7903想撤掉initcode的49152字节帽子

在以太坊部署合约时，会接触到一个容易混淆的数字对：24576与49152。前者是EIP-170规定的已部署合约代码上限，约二十四KB，2017年为限制状态膨胀引入；后者是EIP-3860在2021年伦敦升级中给initcode——合约创建时执行的初始化代码——设定的上限：四万九千一百五十二字节，约四十八KB。两道关卡管的不是同一段字节：initcode只在部署时跑一遍，负责布置初始状态，跑完即弃；部署产物才是长期驻留状态的运行码。EIP-7903（2025年3月5日创建，提案文本状态为Stagnant）提议把后者拆掉：删去49152字节的initcode上限，同时保留它的全部计费规则。

49152是怎么来的、挡了谁

EIP-3860做两件事：给initcode每字节收二Gas的窗口分析费（沿用并推广既有JUMPDEST分析定价），并设一个硬上限。上限的动机与当时的DoS研究有关——过大的initcode会拉长区块验证窗口。但这个数字在实践中卡住的更多是正当场景。工厂类合约常用CREATE2在一条交易里批量部署多个实例，一个交易一笔calldata里携带多段initcode；也有的合约把依赖库打包进初始化代码一并部署。这些写法容易撞上限：要么拆成多笔交易增加用户成本，要么用代理模式绕，而代理层本身又是新增的复杂度与审计面。EIP-7903的论证是：真正防DoS的本来就该是计费——只要每字节都按价付Gas，大小本身就由付费者承担，再加一刀切的体积帽属于重复设防。

拆掉之后留下什么

提案文本的规格部分就三条：移除initcode的49152字节上限；保留每字节二Gas的分析计费（部署一百万字节的initcode就是二百万Gas，从Gas上限自然推出体积天花板）；EIP-170的部署上限原样不动。换句话说，删除上限之后initcode的可行规模完全由区块Gas上限决定：以三千万Gas量级的区块计，纯initcode在理想情况下可以远大于原先的帽子，但那意味着这笔交易用光整个区块的Gas并支付对应费用——价格机制把体积限制翻译成了市场语言。反对意见集中在校验尖峰：JUMPDEST分析与初始化合成的验证成本并非严格线性，超大initcode可能造成验证时间的非线性抖动；支持者则指出Gas上限本身就是那道硬闸，线性定价加全局上限在其余场景都够用，为部署这种低频操作保留特例，收益有限。

与运行码上限的分界

值得把两道关卡的哲学差异说透。EIP-170限制运行码，因为它永久占用状态存储，是长尾成本；initcode跑完就丢，占用是瞬时的，用瞬时付费去约束瞬时资源，逻辑上与运行码的永久租赁不同。EIP-7903只拆瞬时那道闸，不碰永久那道闸，恰好是这条哲学的落实。顺带一提，EOF路线（EIP-3540一族）给代码格式与部署流程设计了整套新结构，initcode处理也在重排范围内，这使得7903这类单点修改的命运与EOF节奏绑定——这也是它停在Stagnant的现实原因之一。

快速问答

问：现在的合约部署到底受哪个大小限制？ 答：部署时受initcode上限49152与运行码上限24576双重约束，外加Gas付费；提案通过后前者消失，后两者不变。

问：普通用户感受得到这个提案吗？ 答：感受得到的是工厂类批量部署：一条交易部署更多实例、或同一批实例用更少交易完成，部署Gas与地址数的算术都会变化。

问：拆上限会不会让巨块验证变慢？ 答：验证成本由Gas总量控制的大方向不变，分歧在于验证时间对initcode字节数的曲线是否严格线性，这是评审焦点而非事实问题。

快速对照

两个数字各管一段生命周期：24576管部署完还赖在状态里的那份代码，防的是永久膨胀；49152管只用一次就丢的初始化脚本，防的是瞬时尖峰。EIP-7903的取舍是把后者的防法从硬上限换成纯计费，前者继续保留。看懂这对关卡，顺带就能看懂以太坊限制类规则的一般套路：永久资源靠租赁与上限，瞬时资源靠计价，两套逻辑很少混用，混用之处往往就是提案要动刀的地方。

风险提示：本文仅解释协议提案机制，不构成任何投资建议。EIP状态以官方仓库为准，提案不等于主网激活。