这些努力使得以太坊主网从不敢轻易提高 Gas 上限，到如今能够安全地将上限一路提升至 60M Gas，甚至更高。

撰文：ZHIXIONG PAN

过去一年中，以太坊区块的 Gas 上限（Gas Limit） 从约 3000 万迅速提升到了 6000 万。这一飞跃背后有多重因素共同驱动，包括协议层对区块最坏情况大小的控制、执行客户端性能的大幅优化，以及针对更高 Gas 上限所进行的系统性测试验证 。

简单来说，开发者通过改进以太坊协议规则减少了提高 Gas 上限的风险，显著提升了各客户端处理大区块的速度，并证明网络在更高负载下仍能按时出块和传播区块。

这些努力使得以太坊主网从不敢轻易提高 Gas 上限，到如今能够安全地将上限一路提升至 60M Gas。下面我们将详细解释 Gas Limit 的概念及历史，然后深入探讨 Gas Limit 提升的核心原因，并展望未来进一步扩容所需的条件。

Gas Limit 与 Blob：定义及区别

Gas 上限（Gas Limit） 是以太坊中衡量每个区块内最大计算工作量的参数，即每个区块可包含交易执行的总 Gas 数量上限 。Gas 上限越高，单个区块能容纳的交易越多，链上吞吐量就越大。但副作用是更高的 Gas 上限会增加网络参与者的负担：出块验证者需要在固定的出块时间内打包并广播更大的区块，全网所有节点也必须下载并执行更大的区块，导致网络带宽和节点硬件压力上升 。

Blob 则是另一种不同性质的区块内容，是为扩展以太坊数据可用性而引入的新元素。Blob 来源于 EIP-4844 提案，允许在区块中临时容纳大量供 Layer 2 使用的二进制数据，其成本计量独立于普通交易的 Gas 消耗。简单来说，Blob 提供的是专门给 L2 Rollup 数据的额外空间，而 Gas Limit 衡量的是常规 EVM 计算的规模上限。两者并不直接可比：提升 Blob 数量主要影响区块中可附加的 L2 数据容量，而提升 Gas Limit 则直接增加 L1 执行交易的计算容量。

本文聚焦讨论 Gas Limit 这一话题，而 Blob 容量的变化则不作展开。

历史背景：为何过去不敢提高 Gas Limit？

以太坊早期对提高区块 Gas 上限一直持谨慎态度。在 EIP-1559 于 2021 年实施后，以太坊将区块 Gas 目标定在约 1500 万（单区块最大约 3000 万），此后多年未再提升 。其原因在于，当时几项关键瓶颈尚未解决，贸然提高 Gas 上限可能危及网络安全和去中心化 ：

• 执行性能：客户端软件能否足够快地执行更多交易？如果区块过大导致节点无法在区块间隔内完成执行和验证，可能错过及时出块或出現链分叉 。
• 网络传播：更大的区块需要在 12 秒 的出块周期内广播到全网，尤其是在 4 秒 内必须被多数验证者接收才能及时提交权益证明 。过大的区块可能传播延迟，导致共识问题。
• 状态增长：更高的吞吐量将加速以太坊全局状态（账本数据）的膨胀，节点同步和存储负担随之增加，长期可能削弱网络的去中心化 。
• 硬件要求：以上因素叠加意味着运行节点所需的硬件配置提高。若普通用户用家用电脑难以跟上，更高的 Gas 上限可能使网络向少数高性能节点集中，不利于去中心化。

由于上述顾虑，过去很长一段时间以太坊主网的 Gas 上限基本保持稳定，没有轻易突破 3000 万的水平 。尤其是 Rollup 兴起后，大量交易将压缩数据通过低成本 calldata 发布到 L1，导致以太坊区块平均大小逐渐逼近极限，极端情况下单块数据甚至可达数兆字节之巨 。

在没有其它改进时，提高 Gas 上限只会进一步放大区块尺寸和性能问题。因此，以太坊社区当时选择主要依赖 Layer 2 扩容，而未贸然在 L1 提高 Gas 上限。

如今 Gas Limit 快速提升的核心原因

那么，为什么进入 2025 年后，以太坊能够在保持安全的前提下快速将 Gas 上限提升一倍有余？根本原因在于以下几方面的技术改进同时到位，为扩容扫清了障碍。

协议升级限制最坏情况区块大小

以太坊引入了新的协议规则来缩小「最坏情况」区块尺寸的上限。其中关键一项是 EIP-7623 提案，它通过提高交易中 calldata 数据的 Gas 成本，显著减少了单个区块在极端情况下可以包含的廉价数据量 。

在 EIP-7623 实施前，攻击者可以利用超低的 calldata Gas 单价塞满一个区块高达数 MB 的数据；而提价后，同样大小的数据将耗费更多 Gas，实质上降低了区块大小上限，缓解了区块大小「均值与极值差异过大」的问题 。

这一改动使得即使提升整体 Gas Limit，区块整体字节大小不会无节制膨胀，从而为提高 Gas 上限腾出了安全余量 。换言之，协议层主动收紧了数据层面的开销，确保 「计算量翻倍，区块大小不翻倍」，为后来将 Gas 上限从 3000 万提高到 6000 万奠定了基础 。

同时，主网在 EIP-4844 中开始引入专用的 Blob 数据交易供 Rollup 使用，也进一步减少了 Rollup 对廉价 calldata 的依赖 。Rollup 数据逐步从普通 Gas 空间转移到 Blob 空间后，常规区块 Gas 更集中用于真正的合约计算，平均区块更「轻」，这也间接为 Gas 上限的提升创造了更有利的条件。

客户端性能大幅优化

各个以太坊执行客户端团队对软件进行了深入的性能基准测试和优化，大幅提升了处理大区块的速度。由 Nethermind 等团队主导的 Gas 基准测试框架填充全区块执行单一类型的指令或预编译合约，以压力测试客户端的极限处理能力（用「百万 Gas 每秒」衡量性能） 。

通过这一统一基准，开发者发现并修复了一些过去隐藏的执行瓶颈。例如，在测试中发现「模重复乘方」（ModExp）预编译的某些极端情况耗时远超其 Gas 定价，成为所有主流客户端的共同瓶颈 。

针对这些发现，社区迅速提出 EIP-7883 对 ModExp 预编译进行 Gas 重定价，并协调客户端优化算法 。同时，其他耗时较大的密码学操作（如 BLS12-381 椭圆曲线计算 BN256、哈希等）也分别由客户端团队进行了优化或重价 。

据统计，经过 2025 年中期一次跨客户端的「Berlin Interop」性能冲刺，各执行客户端在最坏情况下的区块处理速度显著提升，大多数操作已达到每秒处理约 2000 万 Gas 的水平 。

换算下来，如果客户端每秒能执行 2000 万 Gas，那么在 PoS 出块间隔 4 秒内理论上可处理多达 80M Gas 的区块 。这意味着将区块上限提升到 60M Gas 仍在安全余度之内。

这些性能改进消除了此前「执行速度跟不上 Gas 上限」的顾虑，保证即使区块包含双倍于以往的交易量，客户端也能在规定时间内验证完成，不会因为执行过慢而错过共识时限 。

全面测试验证网络传播极限

在实施任何主网 Gas 上限提升前，开发者在多个专门的网络中进行了充分测试，确保更大区块依然可以及时传播并被绝大多数节点接受。

例如，2025 年以太坊开发者在测试网 Sepolia 和新开发网 Hoodi 上将区块 Gas 上限提升至 60M，并持续观察网络性能指标 。结果显示，即使使用最大 60M Gas 的区块，这些网络中的区块提议仍能按时打包完成并通过 P2P 网络快速传播：90% 节点在块产生后约 0.7~1.0 秒内收到区块，几乎所有节点都在 4 秒内完成验证并接受区块成为新链头 。

换言之，即使区块 Gas 用量翻倍，区块仍然可以在以太坊规定的 4 秒证明者提交截止时间前传遍网络 。在这些压力测试中，开发者监测了提议节点出块是否按时、全网节点接受新区块所需时间分布等关键数据，未发现明显异常 。

由于测试网的状态规模和节点拓扑与主网有所差异，开发者对此保持审慎乐观，但测试结果证明了在理论和工程上 60M Gas 区块是可行的。同时，为保障共识层安全，开发者也考虑了信标链层面的限制（例如信标链网络层目前有 ~10MB 的单区块 Gossip 传播上限） 。通过前述 EIP-7623 等手段降低单块字节数，以及避免同时出现过多惩罚交易等最坏情况，60M Gas 的执行负载并未触及这些上限 。

综合来看，各项测试和调整让核心团队对主网从 3000 万提升到 6000 万 Gas Limit 的风险有了充分把握，增添了信心 。在多数验证者表达支持信号后（约 15 万 + 验证节点投票同意提额） ，以太坊终于在 2025 年着手提升主网 Gas 上限，并计划在后续升级中正式将默认值调整到 60M。

未来展望：再往上提升还需什么？

以太坊社区并不打算止步于 60M Gas。在 Fusaka 等后续升级计划中，开发者描绘了将区块 Gas 上限继续推升至 100M 乃至更高的路径 。要实现这一目标，仍有若干技术难题需要解决或持续关注：

• 进一步优化重度计算操作：正如前文提到的 ModExp 算法，目前通过 EIP-7883 重价和客户端优化已基本消除瓶颈。但要支撑 100M 级别的区块，可能还需要针对其他高 Gas 消耗的加密运算（如 椭圆曲线签名验证、零知识证明验证等）进行优化或加入专用加速 。幸而客户端团队已经在这些方向上展开协作，在 2025 年的测试中就调整了 BN256 椭圆曲线相关预编译的实现，使其性能不再拖后腿 。可以预见，随着以太坊引入更多高性能加密原语（甚至考虑原生支持 STARK 等），执行瓶颈将继续被突破，为提高 Gas 上限扫清障碍。
• 控制状态规模和节点成本：更高的 Gas 上限意味着链上状态可能更快增长。如果不加以应对，几年后全节点存储和同步新节点的难度都会显著上升。以太坊开发者已经在研究状态增长问题，比如提议状态租金或定期修剪历史状态，以避免无止境膨胀。不过这些更长期的机制尚在讨论阶段。短期来看，随着 Gas 上限提高，节点运营者可能需要更频繁地升级硬件（如更快的 SSD 和更大的内存）来跟上增长的状态和数据量。社区在提高 Gas 上限的同时也强调不会牺牲去中心化，因此在状态管理方案成熟前，会谨慎评估每一步扩容对普通节点的影响。
• 共识层改进与网络协议优化：如果未来要支持 100M Gas 或更大的区块，一些共识和网络参数可能需要调整。例如，目前信标链区块包含执行负载、Blob 数据和证明数据在内有整体大小限制 。开发者或需提升 P2P 层的消息大小上限，或通过压缩、分片传播等技术减少大型区块的延迟。此外，以太坊正引入 PeerDAS（点对点数据取样网络）来处理 Blob 数据的高效传播，这会在一定程度上减轻执行层区块传播的压力。在确保执行层 60M+ Gas 安全运行后，数据层和网络层的改进将成为下一阶段扩容的重点。

展望未来，只要上述环节的改进同步推进，以太坊主网进一步提高 Gas 上限并非遥不可及的目标。开发者已经在测试网验证了从 36M 提升到 45M、60M 的可行性，下一步朝着 100M 前进也在规划中 。需要强调的是，以太坊社区在扩容上保持一贯谨慎的态度：每一次提升都会「先测试，后主网」，在确认不会危及网络安全和去中心化的前提下才实施 。

总体而言，过去一年 Gas Limit 的大幅提升是多个领域协同创新的结果：协议层降低风险、客户端提升性能、测试数据提供信心。 在这些努力的支撑下，以太坊成功迈出了 L1 扩容的重要一步，并为未来继续提高容量、承载更多应用奠定了基础。

参考文献

https://ethpandaops.io/posts/60m-gas-sepolia-hoodi/

https://ethpandaops.io/posts/gaslimit-scaling/

https://www.nethermind.io/blog/measuring-ethereums-execution-limits-the-gas-benchmarking-framework