今天的以太坊执行客户端处理一笔 EIP-1559 交易时，会在交易执行完成后立刻把优先费从付款方余额扣出、加给出块者账户。步骤看似天经地义，却在并行执行时代暴露出一个别扭的依赖：同一区块里任意两笔交易，不管业务上是否相关，都要在费用这一笔账上排队。EIP-8115 提出把这笔账推迟——所有优先费先记账，区块处理末尾一次性批量转账。
逐笔小费的隐藏成本
现行规则下，小费结算是每笔交易状态变更的一部分：扣款方余额、加收款方余额，两次余额写操作混在交易自己的读写集里。并行的含义是让互不相干的交易同时跑，而每笔交易都必然触碰两方余额——出款账户是天然各异的，但收款方永远是同一个出块者账户。于是一个账户成了全区块交易的公共写点：并行引擎要么给它上全局锁，要么在冲突检测里把大量交易判为冲突。费用越高、交易越多，这条串行尾巴越明显。
批量结算改了什么
提案的结构是把结算拆成两阶段。执行阶段：交易照常扣基础费与优先费，但优先费不进任何账户，只写进区块内的费用账目——一个累加器或待结算清单。收尾阶段：区块所有交易跑完、状态根计算之前，协议把累计小费一次性记到出块者收益。效果有三层：其一，出块者账户从交易的读写集中消失，两笔毫无关系的交易可以真正并行；其二，小费转账的次数从每笔两次余额写降到区块级常数；其三，费用逻辑从热路径挪到冷路径，执行客户端的费用簿记可以独立优化而不碰共识语义。
需要注意的边界
第一，收益金额不变：区块收了谁的小费、总共多少，结算结果与逐笔模式一致，改的是何时入账，不是入多少。第二，边界条件必须精确：自销毁的出块者、区块内交易因验证者操作（如提款请求）产生的余额变化、以及费用账目与状态根计算的先后次序，都需要在规范里逐条钉死——提案声明依赖 EIP-1559 与 EIP-4895 正是为了对齐这些交互面。第三，对 MEV 与费用市场的影响属于研究议题而非既定事实：把归集延后不改变拍卖结构，也不改变出块者收小费的激励。
当前状态
截至本文写作时，EIP-8115 处于草稿状态（Draft），创建于 2025 年 12 月 30 日，定位是并行执行性能工作栈里的一块配套砖，未关联已激活升级。它与执行层并行化改动的组合方式以各实现当期文档为准。
一个尺度感
数字感受一下改动的量级：一个百万 Gas 的区块里几千笔交易，现行规则下每笔都要在出块者账户上盖一次章——几千次串行写；批量结算后变成一次总账。单看绝对值不大，但并行执行的收益恰恰取决于这类公共点的消减：并行引擎最怕的不是重算，而是任何交易都可能排队的全局锁。协议史上类似的手法并不少见——把热路径上人人必经的小动作挪到冷路径集中处理，通常都能给后续优化留出空间。
快速问答
问：矿工/出块者拿到的钱会变少吗？ 答：不会。批量只是搬运时点变化，区块内小费总额与归属不变。 问：对用户手续费体验有影响吗？ 答：没有可感知差异：小费仍在发送时承诺、仍从发送方扣除。 问：为什么以前不做成批量？ 答：早期串行执行下逐笔转账没有性能代价，规范自然选择最直白的写法；并行执行普及后，公共写点才暴露成瓶颈。
风险提示：本文为协议机制科普，不构成投资建议；Gas 与费用规则以官方规范当期文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。