到2025年底， Base链 的 Gas Limit 翻倍

TL;DR: 我们正在继续扩展Base，使其成为全球经济的平台。到2025年底，我们的目标是将Base链的gas上限翻倍，提高客户端性能，并扩展L1数据可用性，以满足不断增长的需求，同时保持低于1美分的交易费用。

特别感谢 Trent Van Epps (Protocol Guild, Ethereum Foundation), Alex Stokes (Ethereum Foundation), Eli Haims (OP Labs) 审阅本博客草稿。

Base 的使命是构建全球经济。为了实现这一目标，我们致力于不断扩展 Base 链，使其能够成为数十亿人上链的平台。我们从2025年开始，规模是 Base 链一年前推出时的10倍，并且在释放更多容量以满足不断增长的需求方面取得了重大进展，同时保持了低于1美分的交易费用。

今年年初，我们确定了多个 scaling bottlenecks，我们一直在通过大型扩展项目积极解决这些瓶颈，这些项目现在即将完成，例如将我们的基础设施迁移到 Reth、使用 TrieDB 优化性能以及使用 PeerDAS 扩展 L1 数据可用性。

这些项目解锁了逐步的性能提升，现在使我们能够更快地扩展 Base 链。因此，在第四季度，我们的目标是将 Base 链的 gas 上限从 75 Mgas/s 翻倍到 150 Mgas/s。

我们迄今为止的进展

在 2025 年上半年，我们几乎每周都在 Base 链上进行扩展。因此，我们看到中位数费用从每笔交易约 30 美分降至几美分。在第二季度中期，我们暂停了这些增长，以确保链的稳定性，并专注于有望释放更大扩展收益的长期扩展工作。

在过去的几个月中，Base 继续增长：更多突破性应用程序涌现，为网络带来了 10 倍以上的链上活动。2025 年 6 月，Base 链成功处理了高达 ~1,500 笔/秒的交易，中位数费用低于 5 美分。

在此期间，我们 反思 了在自然流量之前主动增加 Base 链的 gas 目标可能会导致次优的费用市场。因此，我们现在通过增加其 gas 上限（即最大容量）而不是 gas 目标来继续扩展 Base 链，因为 gas 上限增加对费用市场的影响较小。我们保留 gas 目标增加，以备我们观察到高费用时使用。

在我们继续提高 Base 链的 gas 上限之际，我们将更新我们在解决扩展瓶颈方面取得的进展。

扩展瓶颈回顾

自 上次更新 以来，我们在消除扩展瓶颈方面取得了重大进展。提醒一下，我们跟踪 4 个主要的扩展瓶颈：

• L1 DA：我们可以发布到以太坊的数据量

• 客户端执行速度：构建和验证区块的速度

• 故障证明性能：故障证明游戏可以进行的速度

• 状态和历史增长：节点需要维护的磁盘使用量

瓶颈 1：L1 数据可用性

5 月 7 日，Pectra 硬分叉在以太坊主网上线，可用 blob 空间翻倍。在此之前的 6 个多月里，blob 的使用率已达到上限；硬分叉后，L2 能够利用更多空间，并相应地结算更多链上活动。

来源: https://dune.com/hildobby/blobs

PeerDAS 预计将于 12 月初作为 Fusaka 硬分叉的一部分上线，代表了 L1 DA 的下一个重大进步。它通过在各个节点之间对 blob 进行分片，解决了增加 blob 而不给 L1 共识节点带来负担的挑战。

PeerDAS 的实施是一项巨大的协作努力，许多生态系统团队倡导加速发布 (1, 2, 3)，有效地将时间缩短了几个月。Fusaka 为 PeerDAS 奠定了关键的技术基础，而没有增加 blob。一旦观察到该实现的稳定性，blob 将在 Blob Parameter Only (BPO) 分叉中增加，预计将在之后很快落地。

因此，我们有望在 2026 年初将 blob 作为生态系统增加 2 倍以上，我们希望这足以支持 Base 链和其他 L2 在不久的将来继续扩展的计划。

Pectra 和 Fusaka 都为解决此瓶颈提供了 significant benefits.

瓶颈 2：客户端执行速度

这是我们今天最大的瓶颈，也是我们几个活跃项目的重点。

为了安全地扩展，我们需要确保排序器和验证器节点都能够足够快地构建区块。随着我们的扩展，这些区块不断变大，理想情况下，我们可以在扩展 之前 建立对节点能够构建这些更大区块的信心。为了解决这个问题，我们构建了一个 benchmarking tool 来模拟我们指定的 gas 上限下不同流量模式的区块构建时间。我们将在未来几周内分享有关此工具的更多详细信息，但这项基础工作揭示了我们在扩展之前需要解决的特定性能约束。

工作 1：Reth Everywhere

我们正在积极地将 Base 链节点从原始的默认客户端 op-geth 迁移到我们新的基于 op-reth 的 Base 客户端，我们已经测量到该客户端的性能要高得多。通过将几乎所有内部节点基础设施（最近包括我们的排序器节点）迁移到 Reth，我们已经 made notable progress。

我们仍在 op-geth 上运行的唯一节点是故障证明系统的某些部分，但是，在即将到来的 Base 链升级 U18 之后，我们将迁移到 Kona，这是一个由 OP Labs 构建的基于 Reth 的故障证明程序，这将使其成为可能。

最后，为了充分实现 Reth 的性能改进，我们需要使 Reth 能够有效地获取历史状态，而它目前并非为此而设计的。我们设计了一个 ExEx 以提高效率，我们正在与 OP Labs 合作以完成实施和推广。

对于外部验证器，我们建议将 Reth 作为未来的默认客户端。

工作 2：TrieDB

一年多以前，当我们的团队对 Reth 进行基准测试时，我们注意到，虽然 Reth 的性能远高于 Geth，但存储读取和写入是执行速度的长尾。加快这些速度可以提供 8-10 倍的性能提升。

因此，我们投资了 TrieDB：一个重构数据库格式以使获取状态快得多的项目。我们已经积极开发这个项目几个月了，并且即将完成最终版本。我们已经 spoken about 和 open-sourced 了这个项目，并将很快分享更详细的技术说明和时间表。

工作 3：资源计量和操作码重新定价

虽然 TrieDB 主要侧重于提高存储读取和写入的速度，但与它们对网络造成的资源负载相比，今天还有其他操作码的定价也不合理。理想的解决方案是对所有这些操作码进行重新定价。这听起来很简单，但实际上是一项巨大的协调和执行工作，因此我们正在并行地进行这项工作，以寻找更直接的解决方案。

一种解决方案是管理资源使用，或“资源计量”，以确保 Base 链节点保持稳定，同时确保用户交易能够快速确认。我们今天已经使用它 to manage Base's blob usage，rollup 依靠它从 L1 继承安全保证的最关键资源。Optimism 正在通过 addingin-protocolmetering 在下一个 OP Stack 升级中正式化，这允许以太坊的 EIP-1559 的拥塞管理开始发挥作用，因此用户不太可能在交易包含方面遇到延迟。

另外，我们一直在开发一个新项目，以改进 Base 链上的 mempool，该项目为用户启用了捆绑支持和交易状态跟踪等功能。该项目的一个很大的扩展优势是，它使我们能够更轻松地将资源计量应用于 blob 使用以外的其他资源。围绕着这个设计有一些开放的问题和决定，我们将很快分享并征求反馈。

工作 4：访问列表

我们已经开始探索 Flashblock Access Lists (FAL)，这是 EIP-7928 的一种改编版本，适用于生成 Flashblocks 的 OP Stack 链，以及 OP Labs。FAL 通过启用并行磁盘读取、并行交易验证和无执行状态更新来提高验证器节点的执行性能。

总结关于执行的所有这些工作，Reth 排序器迁移已使其安全地将 gas 上限提高到至少 150 Mgas/s，并且我们相信，通过 TrieDB 和资源计量等工作的尽快落地，我们可以在 2026 年初解锁 400-500 Mgas/s 的 gas 上限。

我们最近将 Base 排序器迁移到 Reth 已经实现了逐步的性能提升，并且随着今年晚些时候更多项目的落地，我们将解锁更多扩展能力。

瓶颈 3：故障证明性能

在我们上次更新中，一个主要的瓶颈是故障证明性能。鉴于 Base 链仍然依赖于乐观证明系统，我们无法生成比我们的证明系统能够正确证明和验证的更多交易数据。我们受到故障证明游戏参与者提出成功挑战所需时间的限制。

但是，OP Labs 制作了一个改进的故障证明系统版本，该版本引入了多线程并利用了 64 位架构（超过 32 位）——MT+64 Cannon。这两个修改显著提高了性能，并且自推出后，故障证明不再是扩展方面的问题。

自从升级到 MT+64 Cannon 以来，故障证明不是一个直接的瓶颈。

此外，为了继续去中心化，我们正在探索 Base 链的基于 ZK 的证明系统，并且我们认为这些系统可能对扩展有积极的好处。

瓶颈 4：状态和历史增长

我们的“Reth everywhere”工作也在管理状态和历史增长方面取得了丰硕的成果。因此，我们目前并不担心历史增长会在近期成为扩展障碍，但是当我们开始显著提高 gas 上限时，这种情况可能会改变。我们预计我们将要进行的下一个长期项目之一将是围绕状态过期，并且该团队已开始探索这方面的潜在途径。

瓶颈总结

综合所有这些，我们得到以下总结图。值得注意的是，我们已经清除了在下个月扩展到 150 Mgas/s 的道路。

护栏

我们认为主动增加 Base 链的 gas 上限是支持 10 亿人在链上的核心，因此我们用来跟踪扩展进度的核心指标是每秒 gas 上限。

但是，扩展的预期影响是保持 Base 链上的亚美分交易，因此我们还必须跟踪费用以确保我们维持这一点。

由于交易的复杂性可能不同，因此成本也不同，因此我们跟踪的费用指标是标准 gas 使用量的成本。我们从 10 万 gas 开始——比平均交换使用量多一点。

每天报告 10 万 gas 的价格，按中位数、p75、p90 和 p95 成本细分。

除了费用之外，我们还跟踪交易包含时间和正常运行时间。这些与扩展是相关的，但是这些指标的下降可能表明我们需要扩展更多或专注于基础设施可靠性。本季度的一个积极目标是提高可靠性，以便在不到 2 秒的时间内构建 99.9% 的区块，我们希望通过实现与执行速度相关的项目来实现这一目标。

展望未来

由于我们已经观察到在活动增加期间 Base 链上的费用开始增加，因此我们致力于加速我们的扩展路线图，以降低这些费用并维持 Base 上的亚秒级、亚美分交易。

我们加速扩展的努力得益于整个生态系统中许多团队的支持。我们感谢协议团队和基础设施运营商如此接受和支持我们的扩展工作。

我们将继续合作扩展 Base 链，以支持 10 亿+ 用户。如果你有兴趣开发创造性和雄心勃勃的扩展解决方案，以使未来 10 亿人能够加入链上，we’re hiring，我们很乐意听到你的消息。

在社交媒体上关注我们，以了解最新信息：X ( Base team on X) | Farcaster | Discord

• 原文链接： blog.base.dev/scaling-ba...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～