一刀切涨价为什么不行
以太坊 L1 想继续扩容，最大的拦路虎是状态增长：节点硬盘上那份世界状态一直在变厚，硬件要求水涨船高，家庭节点最先扛不住。此前路线里有一种直接方案：把状态创建操作的 gas 价整体上抬，写状态变贵、增长自然放缓。问题也很直白——静态涨价要么平时太松、出事时太紧，价格永远踩不准需求曲线；而且状态操作和普通计算共享同一条 gas 限额，压状态的同时也压了普通运算，扩容被一条限额互相锁死。
EIP-8075（2025年10月起草，草案状态，依赖 EIP-1559、EIP-4844 与 EIP-8037）的思路是给状态增长装恒温器：像 blob 费用市场那样，跟踪每块造了多少新状态字节，自动微调状态单价，把日增长精确钉在目标线上，同时把状态从普通 gas 限额里豁免出来，给非状态运算腾出百分之五十到三百的空间。
excess_state_bytes 怎么调温
机制骨架照搬 EIP-4844。协议每块统计两个数：本块新建状态字节数与清除字节数，差额滚动累计进一个 excess_state_bytes 计数器——高于目标就涨，低于目标就降，下限为零。单价公式与 blob 底价同构：state_gas_per_byte 等于一个指数函数作用在 excess_state_bytes 除以 STATE_GAS_UPDATE_FRACTION 上。三个关键常量：TARGET_STATE_BYTES_PER_BLOCK 取 36400 字节，乘上每万年区块节奏即约每日 250MiB；MAX_STATE_BYTES_PER_BLOCK 是目标的两倍；STATE_GAS_UPDATE_FRACTION 取 36418000，这个数是拿最大偏差除以 ln(1.001) 再取整算出来的，含义是：哪怕一个块顶格烧满上限状态字节，单价最多只上调千分之一。
千分之一这个慢调节点是刻意照顾钱包体验。用户提交交易到落块之间隔若干块，若单价可能跳变，按旧价设的 gas 上限会突然不够、交易失败。变化足够慢，钱包只需像今天算 blob 底价那样读一次 excess_state_bytes、按 8037 的操作码字节常数预估状态字节数、乘一个小余量再报 gas 上限，交易格式完全不变。
一笔增长账
目标线 36400 字节每块约合每日 250MiB、每年 90GiB 量级。对照之下，状态膨胀担忧的典型语境是年增数百 GiB 甚至更多。恒温器的巧妙在于它不禁止任何操作——你可以尽管创建状态，只要全网日总量贴着 250MiB 走，单价就稳定；一旦某类写状态玩法突然爆量，指数曲线逐块爬坡，直到需求被压回目标。与硬性日限额的区别也在这里：没人被拒之门外，价格就是配额分配器。单价还有一条地板线 MIN_STATE_GAS_PER_BYTE，对应 8037 定价折算到六千万 gas 块规模的水位，防止增长冷清时状态写入近乎免费、下一个人趁便宜狂造状态。
和多维gas的分岔口
提案在备选比较里专门回应了多维 gas 计量路线：那种方案不设状态专属价格，基础费更新取各资源中消耗最大者。缺陷是资源互相定价——普通运算吃满时顺手抬高了状态价，状态吃满时又推高别的运算价格，两个市场互相踩踏，谁都控制不住自己。8075 坚持给状态单独装一个费用市场，代价是钱包要多算一项，收益是状态增长这条最敏感的曲线第一次有了确定性目标。
钱包要改哪一行代码
差别落在 gas 上限的算法上。今天钱包估 gas 上限，只关心常规 gas 消耗加一个安全余量；8075 之下，交易若会创建状态字节，钱包必须多读一个链上量 excess_state_bytes，套用与 blob 底价同款的指数公式算出当期 state_gas_per_byte，再按 8037 给的每操作码常数（例如新账户一百一十二字节）数出这笔交易造多少状态字节，两个数相乘、乘一个余量，并进最终 gas 上限。好消息是所有零件都是现成的：读字段像读 blob 底价、公式像算 blob 费用、常数表直接继承 8037，钱包工程只是把三段既有逻辑串起来，用户界面完全不用变。这也是提案反复强调保留现行交易格式的用意：扩容参数在协议里翻涌，用户按的按钮还是那一个。
快速问答
问：这是要取消状态写入费吗？恰恰相反，它把状态费从静态常数变成自动调速的动态价，并把状态字节从普通 gas 上限中单列。问：清除旧状态能抵账吗？能，统计按新建减清除的净额滚动。问：现在能用吗？草案阶段，依赖 8037 先把每操作码状态字节常数定好。
风险提示：本文仅解读协议草案，不构成投资建议；参数以官方 EIP 文本当期版本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。