以太坊的费用账本里，calldata（随交易附带的原始数据）长期是一类特殊存在：它消耗的运算很少，却实实在在撑大区块。EIP-7623在2025年随佩特拉升级生效，给这类数据型交易立了一条总费用地板——每个calldata字节至少要按64 Gas收费，防止有人用几乎免费的字节把区块塞满。地板落地还不久，两条后继提案已经排着队来抬价了：EIP-7976想把地板和单价一起对齐到64/64，状态处于同行评审；EIP-8311更进一步，提出把地板提到每字节96 Gas，2026年6月刚拿到编号。抬价的理由不是缺收入，而是一个几何问题：怎么让最坏情况的区块瘦下来。
先分清楚两笔费用
EIP-7623的结构是两层账。第一层是常规执行费用：calldata字节继续按原来的单价计价，每个非零字节16 Gas、零字节更便宜。第二层是地板：把交易所有执行费用加起来之后，再和calldata字节数乘以64取较大者作为实际收费。也就是说，普通交易不受影响，只有那种字节多、执行少的手续型交易会被地板兜住。这套结构解决的是最坏情况：在地板出现前，纯calldata的区块每单位Gas能塞进的字节远比普通区块多，传播和验证的隐性成本被压给了全体节点。
两条后继提案动的都是地板这一层。EIP-7976的做法最干脆：把执行侧的calldata单价从16直接抬到64，和地板数字合二为一，两本账并成一本，最坏区块尺寸随之缩小。EIP-8311则把64/64再往上推到96/96，它在依赖关系上明确挂在EIP-3860、EIP-7623和EIP-7976之后，是叠在前两者地基上的增量。
锚点：一笔最普通的转账
EIP-8311最值得说的不是数字，而是它推导数字的方法。提案把一笔最普通的ETH转账当作锚：执行费用固定21000 Gas，交易体积一百多字节，两者之比给出一个字节密度——每花掉一单位Gas，链上要搬运多少字节。锚的意义在于它是链上最常见、传播路径最成熟的交易形态，节点为它做的每一件事都是日常负荷的基准。
接下来的推导是一个不等式：纯calldata区块的最坏密度，必须不比全转账区块更密。64 Gas的地板只能做到部分收敛——把8007号提案之后已经被压到锚点上限的执行侧开销留给转账数，而数据字节按64计价时每单位Gas搬运的字节仍然高于转账锚。把地板抬到96，正是让纯数据交易和全转账交易在单位Gas字节数上拉平的取值。提案原文把它分成推导锚点密度、选择地板值两小节来论证，逻辑链条是尺寸问题，不是价格歧视。
顺带一提，执行侧的邻居提案也在同一条线上：7981号提案要给访问列表字节补上同类的地板价。数据占的便宜越少，区块的字节上限就越接近一个可预测的物理量，这也是十兆包裹上限这类提案能安心落地的前提。
快速问答
问：地板费提高会让我平时的转账变贵吗？ 答：普通转账和交互交易不受影响，受影响的是把calldata当主料的交易——大额数据发布、部分协议的署名写入、铭文类操作。常规调用里calldata占比很小，64抬到96在总费用里的增量通常难以察觉。
问：为什么EIP-8311是Draft而EIP-7976是Review？ 答：编号越早的提案往往走得越远。7976已进入同行评审但尚未定稿，8311还在草案阶段，两者都没有进入任何已排期的硬分叉。以协议当前的日程为准，别把提案当作已生效规则。
问：抬地板和直接限制区块字节数有什么区别？ 答：字节硬上限是行政式的，交易要么过要么不过；价格地板保留了市场选择——仍然允许提交大calldata交易，只是按更真实的尺寸成本付钱。两条路线在规格文档里经常互补出现。
一条判断线
看这类提案，盯两个问题就够：它压缩的是最坏情况还是平均情况；锚点选得是否代表了真实负载。EIP-8311两个答案都偏向温和——只削尖峰、锚是全网最普通的转账，这也是它能叠在7623地基上继续走的原因。
风险提示：本文内容为protocol机制科普，不构成任何投资建议；Gas相关参数随时尚提案讨论而变化，请以协议当前规格与官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。