回执里的累计 Gas 是个历史包袱：EIP-8116 想把两本流水账拆开

一笔账为什么要记两遍

点开任意一笔以太坊交易的回执，gasUsed 旁边总有一个 cumulativeGasUsed：它不是这笔交易自己用了多少，而是从区块第一笔交易累加到本笔的总消耗。想知道单笔用量，标准做法是拿本笔累计减前一笔累计。这个设计可以追溯到创世：回执字段随执行逐步累加，实现上只要维护一个运行计数器，写入最便宜。区块收据根里存的就是这些累计值，轻客户端要验证单笔 Gas 就得按序验到该交易为止的全部前缀。回执字段逐项讲清楚可以看 交易回执（receipt）里有什么？，本文只谈这条累计制本身在 2025 年底被正式提案拆掉的事。

EIP-8116 想改什么

EIP-8116 由 Etan Kissling 与 Gajinder Singh 提交，创建于 2025 年 12 月 30 日，状态 Draft。它动两处。第一处，激活后所有新回执不再记 cumulativeGasUsed，改记该交易自身的 gasUsed——链上数据从区块级流水改为逐笔账单。第二处，logs 数组里 logIndex 的语义从该日志在整块中的位置改为本回执内的位置。动机章节列了两条账：验证低效——RPC 客户端想独立验证单笔 gasUsed，必须对相邻多份累计值做差分运算，而其中任何一份的验证又牵出更早的；并行度受限——回执内容是有状态的，即使两笔交易访问的状态毫不相干，后一笔的字段值也依赖前一笔。第二点其实是在为帧交易一类新执行结构铺路，那套先交哈希再亮内容的设计见 先把哈希交上去再亮内容：EIP-8209 帧交易的防抢跑排法，它们共享同一个作者谱系。

对账逻辑会怎么变

今天链下索引器合成单笔 Gas 的公式——本笔累计减上一笔累计——在 8116 生效后要整个删掉，改读直接字段；这是好事。麻烦在日志侧：依赖区块级 logIndex 的应用要改排序假设。提案给出一个保底公式，用交易序号乘 4 加回执内序号来模拟旧排序，承诺相对顺序与旧语义一致，但绝对数值可能比历史值大。对做数据的产品，这是一次典型的字段换代：新旧链上数据共存，解析器必须按区块高度分段兼容，就像 1559 前后费用字段各读一套那样。

为什么要等到 2025 年才有人提

累计字段不是没人觉得别扭，而是改它一直不值。回执字段被收据根承诺着，动语义等于动共识数据结构，得配合一次硬分叉，还得有足量的下游收益来抵消费害。此前单笔 gasUsed 已经能从 RPC 层拿到（客户端替你做了减法），链上改写的边际价值不够高。转折点来自执行结构本身的变化：当回执可能来自多帧嵌套执行、区块内并行度提高，累计计数器作为实现上的顺手包袱就从省成本变成挡成本。8116 与其说是一个字段审美提案，不如说是执行层重构的配套水电改造——这类提案的存在感低，但往往比话题性提案更早进入实际工程讨论。

用户现在该做什么

答案是：什么都不用做，但可以把对账肌肉练起来。判断一笔交易到底花掉多少，永远以回执与所在区块的费用字段为准做乘法：gasUsed 乘有效 Gas 价，有效价等于区块基础费加实际成交的优先费。累计字段只是区块内记账方式，它怎么排队、怎么进位，都不改变你这笔的实付。等 8116 一类提案真进入升级清单，变化的也只是索引器的代码行。

一条考古心法

判断一个链上字段会不会改，看三件事：它被哪个默克尔根承诺、下游有多少独立实现依赖它、有没有更强的结构变化在逼它。三问通过才轮到提案编号出场。cumulativeGasUsed 恰好同时满足被承诺、广依赖、正被新执行结构挤压三条，所以 2025 年它终于有了自己的拆解提案。风险提示：本文为协议数据历史分析，不构成投资建议。