状态根为什么贵
以太坊每个状态都要挂在一棵密码学承诺树上当凭证。区块执行完之后，节点要重算状态根，而状态根的更新代价，和这轮里被改动的账户、存储槽的数量与位置直接相关。EIP-7973 的动机文本把这句话说得很直接：更新状态根是出块过程中最昂贵的环节之一。正因为贵，计费模型早年在存储那条线上做了精细化——一笔交易里反复写同一个存储槽，不必每次付全价，这叫净额计费，规则由 EIP-2200 定型。道理很简单：状态树只需要为这个槽最终变动一次埋单，中间过程在密码学上没有产生新的树节点成本。
不对称出在哪
问题在于，同样是写状态，账户的字段没有这份待遇。每个账户有四样东西：nonce、余额、代码哈希和存储根。一笔复杂交易里，同一个账户可能因为多条内部转账、多次调用，nonce 被连续更新好几遍，余额被反复加减好几遍。现行规则下，账户字段每写一次都按全价收费，哪怕写的是同一个账户的同一个字段。存储有净额计费、账户没有，这个不对称在早期没什么人抱怨，因为那时账户操作在总账单里占比小；随着批量支付、多层内部转账类应用变多，一笔交易里对同一账户的连续操作让全价重复收费显得格外刺眼——同一棵树明明只需要更新一次，用户却付了多次的钱。
提案的改法
EIP-7973 的做法是把存储那边验证过的思路平移过来，提案文本称之为热账户写入：一笔交易内，某账户的 nonce、余额或代码哈希字段第一次修改按现行价格收费，同一交易内对该字段的后续修改收取更低的费用，因为状态根更新只发生一次。它沿用 EIP-2200 建立的净额计费哲学，作用域严格限定在单笔交易内部，交易与交易之间、区块与区块之间的写不享受折扣。这样界定的好处是安全边界清楚：折扣依据只有本交易内的执行轨迹，任何节点重放执行都能得到完全一致的结果，不需要引入跨交易的缓存状态，也就不会把客户端的缓存实现细节泄漏进共识规则。
它现在走到哪一步
按官方仓库，这份 EIP 标注为 Draft，依赖 EIP-2200 的既有净额计费框架，作者包括 Charles Cooper 等人，没有进入已排期升级。对用户的现实影响也值得说清：这份提案即使落地，改变的是交易内部的重复写入定价，不会让所有转账变便宜；想省 gas 的可验证办法仍然围绕减少无谓的状态写入来设计合约与调用路径，而不是等待某项计价折扣。
风险提示：本文为Gas定价机制的技术介绍，不构成投资建议，不构成对交易费用水平的预测。链上操作请自行核实当前网络的实际计费规则。
哪些交易最先受益
把镜头对准具体场景最容易理解这笔折扣。批量分发场景里，付款合约在一条交易内向几十上百个地址分别转钱，每完成一笔转账，合约自身的余额字段就少一次——同一个账户的同一字段在交易内被连续更新几十次，状态树却只为一次变动埋单，用户却按几十次付过钱，这类交易是热账户写入最典型的受益者。代码部署类交易也有同样的形状：一次部署里账户的代码哈希与 nonce 都发生变动，若后续逻辑再触发账户字段变化，重复全价的部分就是提案瞄准的溢价。反过来，对几乎不重复动同一账户字段的普通转账，这项改动几乎不产生任何账单变化。理解边界比记住结论更重要：这份提案是对重复写入的内部修正，不会改变状态存储的基础成本，也替代不了少写状态这一条老话。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。