EIP-7778 深度解析无退款的区块 Gas 记账机制如何堵住区块 Gas 上限的绕过漏洞【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7778Block Gas Accounting without Refunds是 Ethereum 核心层的一项 Gas 记账机制改进提案目标是彻底消除「区块实际执行的计算工作量」与「区块 Gas 记账」之间的系统性偏差。本提案将交易级用户付费与区块级区块 Gas 上限执行的两层记账解耦用户依旧享受存储清零等操作带来的 gas 退款但区块级记账不再扣除退款。读完本文你将完整理解 gas 退款的由来与演变、区块 Gas 上限被绕过的攻击面、EIP-7778 的精确记账公式及其与 EIP-7623 calldata 下限的配合方式以及它在后续网络升级如 Glamsterdam与多维 Gas 记账提案EIP-8037中的定位。背景gas 退款机制与它的副作用退款机制的初衷Ethereum 的 gas 退款机制最早用于激励「状态卫生」state hygiene鼓励开发者清理不再需要的存储槽与合约。其核心是SSTORE操作当把存储槽从非零值写回零时会触发退款。该机制经由 EIP-2200 的净 Gas 计量规则定型再经 EIP-3529Reduction in refunds大幅收窄移除SELFDESTRUCT退款将SSTORE_CLEARS_SCHEDULE从 15,000 gas 降至SSTORE_RESET_GAS ACCESS_LIST_STORAGE_KEY_COST即当前约 4,800 gas见 eip-3529.md将单笔交易退款上限从gas_used // 2收紧为gas_used // MAX_REFUND_QUOTIENT其中MAX_REFUND_QUOTIENT 5即退款最多为已消耗 gas 的 1/5。EIP-3529 在其动机部分已经明确指出退款会放大区块大小方差——一笔区块中实际消耗的 gas 理论上限接近账面 Gas 上限的两倍退款为后续交易腾出了 gas 空间尽管退款被限制在单笔交易已用 gas 的 50%后被收紧至 20%。这正是 EIP-7778 要根治的根源性问题。两层记账的偏差从何而来在 EIP-7778 之前gas 退款同时作用于两个层面交易层用户付费SSTORE清零产生退款减少用户实际支付的 gas区块层区块 Gas 上限执行同一笔退款也从「区块已用 gas」中扣除导致区块实际执行的计算量超过账面 Gas 上限。由此产生一个结构性漏洞矿工/验证者可以在一个区块内打包比 Gas 上限允许的更多的计算工作。举例如下区块20878522的净使用量为 28.5 MGas但其中包含 4.01 MGas 的退款毛使用量达到 32.51 MGas——超出区块 Gas 上限 2.51 MGas。以 30M 的区块 Gas 上限计算这意味着该区块实际执行的计算量超限约 8.4%而账面上却显示「未超限」。EIP-7778 规范用户层与区块层记账解耦EIP-7778 的核心规范非常聚焦只改动区块级记账不动用户级记账1. 用户 Gas 记账保持不变用户仍可获得符合条件操作如将存储槽置零的 gas 退款交易 gas 计算式为gas_spent max(tx_gas_used - gas_refund, calldata_floor_gas_cost)其中calldata_floor_gas_cost来自 EIP-7623 引入的 calldata 下限成本见下文。2. 区块 Gas 记账修改在计算区块 Gas 上限执行时不再减去退款block.gas_used max(tx_gas_used, calldata_floor_gas_cost)注意该公式同时纳入了 EIP-7623 的 calldata 下限并且有一个重要保留项那些反映实际计算量减少的存储折扣仍然保留在区块级记账中例如热存储访问warm storage access见 EIP-2929 的访问清单机制将值恢复为原始值reverting to original values时获得的折扣。这类折扣之所以可以保留是因为它们对应的「计算工作量确实减少了」——例如槽位写回原值时客户端无需真正修改 Merkle 树。这与「清零退款」的本质不同清零操作本身仍需要客户端执行真实的写入工作。与 EIP-7623 calldata 下限的配合EIP-7623Increase calldata cost通过引入 calldata 下限成本来限制最大区块尺寸其关键参数为参数值STANDARD_TOKEN_COST4TOTAL_COST_FLOOR_PER_TOKEN10其中tokens_in_calldata zero_bytes_in_calldata nonzero_bytes_in_calldata * 4交易 gasUsed 计算式变为见 eip-7623.mdtx.gasUsed ( 21000 max( STANDARD_TOKEN_COST * tokens_in_calldata execution_gas_used isContractCreation * (32000 INITCODE_WORD_COST * words(calldata)), TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata ) )EIP-7778 在区块记账公式中直接沿用了这个calldata_floor_gas_cost下限从而保证无论退款如何变动区块级记账都不可能低于 calldata 下限所代表的最小数据成本。两个提案在「以记账反映真实资源消耗」这一目标上形成了互补——EIP-7623 约束的是数据字节EIP-7778 约束的是执行计算量。设计动机让 Gas 上限与计算工作重新对齐区块 Gas 上限的本来含义区块 Gas 上限的设计目的是约束每区块的计算负载computational load per block。而退款机制的引入初衷是激励状态清理并非允许突破计算上限。问题在于二者被耦合在了同一个记账通道里导致账面 gas 无法真实反映客户端需要执行的工作量。三层危害EIP-7778 的 Motivation 明确列出该漏洞可能导致的后果网络不稳定实际计算量超限会产生「超大区块」增大传播与处理延迟拒绝服务DoS向量攻击者可构造包含大量可退款操作的交易让区块承载超出预期的计算压力计算负载超出设计上限区块实际消耗的资源与协议设定的 Gas 上限脱节损害资源定价的公平性。从源码级事实看EIP-3529 已经验证了这种攻击的现实性退款上限收紧至 1/5 后退款机制仍可使区块所需的存储写操作数量最多增加 25%——即存储写型 DoS 攻击的空间依然存在EIP-7778 正是要在区块记账层面把这个口子彻底堵上。保留用户激励的设计哲学EIP-7778 的关键设计决策是只改记账不改经济学用户依然拿到退款因而「清理状态更便宜」的激励被完整保留只有区块级约束的计算口径发生变化。这种「两层记账」模式使协议约束与用户激励各归其位用户层退款照常激励有效区块层以毛 gas不扣退款为口径约束真实计算负载。向后兼容性与硬分叉要求EIP-7778 属于Standards Track / Core类别且明确声明不向后兼容需要硬分叉——因为它改变了区块有效性判定所依赖的 gas 记账口径对单笔交易的用户与开发者体验无任何影响——用户付费、gas 估算、RPC 行为均不变区块生产者矿工/验证者/构建者需要调整交易选择算法——由于每笔交易对区块 Gas 的占用不再是「净 gas」而是「毛 gas」打包时必须以新口径重新计算区块填充度。这一点对 PBSProposer-Builder Separation环境下的构建者尤为重要构建区块时必须确保max(tx_gas_used, calldata_floor_gas_cost)的累计值不超过区块 Gas 上限。测试用例如何验证新记账逻辑EIP-7778 给出了三个方向的测试要求可直接作为共识客户端如 Geth、Reth、Erigon 等的测试用例设计依据1. SSTORE 操作记账将存储槽置零用户获得退款但区块级记账使用全额成本验证包含大量存储清零操作的区块仍然遵守 Gas 上限。2. 区块 Gas 上限边界用例构造包含不同比例可退款操作的区块确保区块无法通过退款机制突破 Gas 上限。3. 交易 Gas 与区块 Gas 的一致性验证用户侧的交易成本保持不变确认区块级记账正确排除了退款。安全考量EIP-7778 带来的安全收益可以归纳为三点消除 DoS 向量封堵利用退款超额占用区块计算资源的攻击路径区块处理时间更可预测对计算工作施加更严格的上限降低区块处理时间的方差防止矿工/验证者集体超载任何一组交易集合其整体计算工作量都不可能再「借道」退款而超过协议预期。在生态中的定位与后续 EIP 的联动EIP-7778 并非孤立提案它在当前仓库的 EIP 生态中与多个提案存在明确的依赖与协同关系Glamsterdam 网络升级EIP-7773EIP-7773Hardfork Meta - Glamsterdam已将 EIP-7778 列为Scheduled for Inclusion的 EIP 之一与 EIP-8037State Creation Gas Cost Increase、EIP-7976Increase Calldata Floor Cost等一同进入该升级规划。区块延迟减半EIP-7782EIP-7782Reduce Block Latency在其requires字段中明确依赖7623, 7778——说明在缩短区块时间的同时协议需要 EIP-7778 保证每个区块的实际计算负载可控。多维 Gas 计量EIP-8037的集成方式EIP-8037 引入执行 gas 与状态 gas 两个维度的独立计量并专门设有「Integration with EIP-7778」一节见 eip-8037.md给出了与 EIP-7778 组合时的区块级记账公式tx_state_gas tx_output.evm_state_gas_used tx_execution_gas max(tx_gas_used_before_refund - tx_state_gas, calldata_floor_gas_cost) block_output.block_execution_gas_used tx_execution_gas block_output.block_state_gas_used tx_state_gas其中max项正是保留了 EIP-7778 的block.gas_used max(tx_gas_used, calldata_floor_gas_cost)规则并将其应用于执行 gas 维度。EIP-8037 还特别澄清了一个容易混淆的点状态 gas 的「refill」如某帧 revert 后撤销的状态创建费用不属于 EIP-7778 所指的退款——refill 撤销的是从未持久化创建的状态其计量资源从未被真正消耗因此始终净额计入evm_state_gas_used不受 EIP-7778 影响。移除退款上限的方向EIP-3298EIP-3298 在其分析中指出由于 EIP-7778 已将退款排除在区块级记账之外退款上限20% 上限用于「限制退款对区块大小影响」的历史使命已经完成从而为未来移除该上限、简化协议铺平了道路。这从侧面印证了 EIP-7778 承担的正是「让退款回归纯用户激励机制」的协议职责。总结EIP-7778 以最小的改动面仅修改区块级记账公式解决了 Ethereum 自引入退款机制以来长期存在的「账面 Gas 与实际计算负载脱节」问题。它通过两层记账解耦同时达成了三个目标用户激励不损、区块计算负载受控、超限漏洞封堵。结合 EIP-7623 的 calldata 下限EIP-7778 构成了「字节成本 计算成本」双重约束的一部分而它与 EIP-8037 的集成公式则展示了如何在未来的多维 Gas 计量框架中延续其记账原则。对于共识层开发者、区块构建者以及研究 gas 定价的读者而言EIP-7778 是理解 Ethereum 下一代 Gas 模型的关键一环。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考