以太坊对部署合约收一笔“代码存入费”：按部署成功的字节码长度逐字节计费（现行标准是每字节 200 Gas，另有一份提高状态写入成本的提案把它抬到每字节 1900）。收这笔费的直觉是新区块码要占所有节点的状态数据库。但数据库里的事实并非如此：同一段字节码哪怕部署一万次，节点也只存一份，后一万个账户全部指向同一个代码哈希。于是同一工厂模板批量部署、同版本合约多链多地址部署这些场景，都在为“根本没有发生的新存储”付高价。EIP-8058 想把这层重复收费削掉。
为什么不能简单查库
最自然的实现是“部署前查一下这段代码是否已在库里，在就打折”。提案指出这会直接破坏共识：不同节点数据库内容并不一致——全同步节点保留历史上所有执行过的代码（包括已回滚、重组交易留下的），快照同步节点的库只覆盖 Pivot 状态附近的集合。同一句 CodeExists 查询在两家节点上可以给出不同答案，费用随之不同，分叉立刻发生。更巧的是提案附带的数据支撑：对 Cancun 时点的全同步库统计显示，约有两万七千多段字节码在库里却没有任何活跃账户引用它们。
用访问列表换成确定性的账
方案的聪明处在于借用 EIP-2930 的访问列表。规则：交易执行前，把访问列表里所有“在状态中存在且带代码”的地址的代码哈希收进一个集合；部署成功时，如果新代码的 keccak256 哈希落在这个集合里，免付按字节的代码存入费，只留账户创建成本。关键在于这个集合完全由交易自身和交易开始前的世界状态决定——每个节点从同一份状态根出发，算出的集合逐位一致，与各自数据库残留无关。用户想触发折扣，就把一个已部署同版本代码的地址放进访问列表；而库里那些无主孤码帮不上忙：没有账户引用它们，就进不了这个由状态推导的集合，也就无法被套利，共识因此安全。
状态与算账
提案 2025 年 10 月 22 日创建，Draft 状态，依赖 EIP-2930。它特意与那套提高代码存入费的方案互相咬合：不抬价则折扣价值有限，抬价后一份 24576 字节的顶格合约光存入费就要约 4600 万 Gas，去重命中直接归零这一项。对普通用户，这项折扣不改变任何已有合约与交易；它是工厂类应用与批量部署者的成本注脚。
一次部署的算术直觉
把数字摆出来：一份 24576 字节的顶格合约，按每字节 200 Gas 的现行存入价约 491 万 Gas；若按那份提高状态成本的提案抬到每字节 1900，同一份代码要 4600 万级以上。工厂类应用把同一个实现部署成百上千个代理或克隆时，模板代码这一项会被乘以部署次数；命中去重后，这笔按字节的费用整体归零，只剩账户本身的创建成本。反过来，对只部署一次的用户，这项折扣几乎不可见——提案的公平性论证也建立在此：省钱的人正是消耗了相同代码资源的人，没有凭空补贴。
快速问答
问：访问列表要额外花钱吗？ 答：按现行规则列表项本身有固定 Gas 成本，与省的存入费相比通常仍划算，但需自己算。
问：CREATE2 也能享受吗？ 答：提案同时覆盖部署交易与合约创建指令的成功返回码。
问：折扣会不会被巨鲸包场？ 答：任何人生成相同字节码都能命中同一哈希，去重是公开属性，不排他。
风险提示：本文仅解释 Gas 机制提案，不构成投资建议；部署成本相关决策请以实时 Gas 数据与你所用客户端的实际规则为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。