状态膨胀按谁收费
以太坊每个全节点都要完整保存世界状态：所有账户余额、合约代码和每一格存储。状态越大，同步越慢、硬件门槛越高、节点越集中。现有 gas 体系对写入的收费基本只看这一次写操作本身——冷槽写入付高价、热槽改写付小钱——却从不看被写的合约已经占了多少存储。一个刚初始化的合约和一个早已装着几百万格数据的巨型合约，写同一格空槽的账单几乎一样。批评者认为这等于让全体节点运营者为个别大户的囤积行为长期免费打工。
EIP-8032（2025年9月起草，草案状态）把这个隐性成本摆到台面上：让 SSTORE 的价格随合约自身存储规模上升，写得越满再写就越贵，以此把状态增长与它造成的长期负担对齐。
storage_count 从哪来
方案的支点是一个新字段。账户的 RLP 编码增加一个可选的 storage_count，记录该账户当前拥有的存储槽数量。共识层里第一次出现按账户统计存储规模的先例，因为账户结构从此要携带这个数。字段是可选的：迁移完成前没有它的账户按零处理，读写路径保持兼容。
麻烦在迁移。历史上没有任何地方存过每个合约的槽数，要得到这张表，协议必须遍历状态树、数出每个非空存储根账户的全部槽位。EIP-8032 规定激活后分块推进这个统计过程：每块处理有限数量的账户与槽（由待定常量控制），进度登记在一个专门的系统合约 TRANSITION_REGISTRY_ADDRESS 里。这个设计让人想起无状态化路线里的账户遍历，但目的完全不同——这里不是为了修剪状态，而是为了给未来收费补一张账本。
收费曲线长什么样
定价思路是分段函数：存储规模低于激活门槛（提案文本提到大约对应 8GB 数据量级）时，SSTORE 成本与现状一致，绝大多数正常合约感觉不到变化；越过门槛后，惩罚项随 storage_count 指数增长。线性加价挡不住铁了心的囤积者——每槽摊薄后仍是常数成本；指数曲线则让规模每上一个台阶，边际写入都按数量级变贵，囤到超大体积的合约会先被自己的账单劝退。具体线性因子、门槛换算系数等参数在草案里仍标为待定，落地数值以最终规范为准。
一笔规模账
按槽位粗算：一个账户若存了十万个非零槽，折算约三点二兆字节；一千万槽约三百二十兆。8GB 量级的门槛大致落在拥有两百五十万槽上下的合约。也就是说，常见金库、交易所合约、NFT 市场离门槛尚远，指数惩罚主要指向的是把链上当免费数据库、用合约矩阵囤积存储空间的极端用例。这不是精确折算，实际字节还含键与元数据开销，门槛最终取值也在待定清单里，但这把尺子能帮你判断：普通开发者几乎不受害，囤积者才面对陡增的边际成本。
与近邻方案的区别
同一大问题下还有几条路线：EIP-8037 给每一个新造的状态字节定统一 gas 单价，把写状态整体变成贵动作；EIP-8075 则用类似 blob 费用市场的机制动态调状态字节单价、给日增长封顶。EIP-8032 的角度不一样：它不追求全网统一价，而是区分大户与散户——按账户已占规模个性化加价，小账户维持现状。三者动机同源、机制互斥度也不同，理论上可以叠加也可以替代，路线之争还很长。
快速问答
问：会不会误伤需要大存储的正当协议？门槛以上才开始加罚，且起步段只是温和线性区，设计意图是把重灾区留作陡峭段。问：storage_count 谁来维护？写存储的账户在交易执行中同步增减该字段，历史数据靠迁移遍历补齐。问：现在有价格数字可算吗？没有，核心常量仍为待定，本文只描述机制骨架，报价要等规范定稿。
风险提示：本文仅讨论协议机制草案，不构成任何投资建议；参数与状态以官方 EIP 文本当期版本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。