2025 年 Base 扩容：亚美分交易费用助力全球链上化

TLDR：为了构建一个全球性的链上经济，我们需要扩展。为了达到我们每秒 1 Ggas 的北极星目标，我们正在规划一条在 2025 年实现每秒 2.5 亿 Mgas 的路径。我们的主要关注点是：增加 rollup 的 L1 数据可用性，提高客户端执行速度，确保故障证明继续按预期运行，并保持节点健康的磁盘使用率。

Base 的使命是构建一个全球性的链上经济，以增加创新、创造力和自由。为了实现这一目标，Base 的 2025 年五大战略支柱 之一是扩展 Base 并降低 gas 费用，以便让世界各地的每个人都可以来到链上。到目前为止，我们已将 Base 的吞吐量扩展到每秒 24 Mgas（发音为“每秒百万 gas”）——几乎是去年同期的 10 倍。但这仍然是第一天。

我们 2025 年的目标要求我们在扩展吞吐量方面取得指数级的进步，超过我们今天的 10 倍，并且达到 Base 最初推出时的 100 倍。这是让 10 亿人上链的关键：扩展使 Base 能够支持更多负载，同时保持用户成本低廉。低费用反过来使世界上更多的人可以来到链上。

自 Base 成立之初，我们就强调扩展吞吐量以保持用户低费用的重要性。Base 工程团队与以太坊生态系统密切合作，通过 EIP-4844 扩展以太坊数据可用性，从而使 blob 能够降低 L2 上的 L1 费用，最近我们一直参与 增加 L1 blob 容量 的工作。

在这篇技术深度文章中，我们将详细介绍我们在扩展 Base 方面取得的进展——以及我们计划如何在 2025 年达到每秒 2.5 亿 Mgas。

扩展 Base

我们吞吐量的北极星目标是每秒 1 Ggas（发音为“每秒十亿 gas”），约为我们今天的 40 倍。Base 至少需要扩展这么多才能支持 10 亿用户在链上进行交易，同时确保交易费用保持在 1 美分以下。

我们通过识别扩展 Base 和更广泛的以太坊生态系统的瓶颈（包括短期和长期）并主动解决这些瓶颈来实现这一目标。与整个行业保持一致是我们战略的核心部分，以确保我们为整个以太坊生态系统构建最佳的未来。

我们对健康生态系统的定义是确保 Base 适用于所有人。为了实现这一目标，我们需要：

• 亚秒级交易 – 使 Base 能够用于大多数现实世界的应用程序

• 亚美分交易 – 即使在流量高峰期，也能保持 Base 的经济性

• 去中心化的开放平台 – 这是我们构建真正全球经济的唯一途径

• 与以太坊生态系统的共生关系 – 与以太坊主网的协同成功，与其他 L2 和 L3 的可组合性和协作性

瓶颈 1 – L1 数据可用性（DA）

L1 DA，也称为“blobspace”，定义了 L2 可以发布到 L1 的数据量。当 blobspace 受到限制或竞争时，会导致零和局面，即 L2 必须争夺可用空间。这是我们想要避免的情况，因为它会导致用户的费用很高并限制了生态系统的整体扩展。但是，随着新的 L2 的出现以及 Base 和其他 L2 的不断扩展，我们已经面临着这一挑战。为了让更多的人来到链上，我们需要更多的 rollup 数据可用性。

自从 11 月以来，blob 一直处于目标状态。来源： https://dune.com/hildobby/blobs

自 2024 年 11 月初以来，我们一直处于 DA 容量状态。这意味着流量高峰会在 L2 上产生高昂的 L1 费用，并增加 L2 交易的总体成本。因此，该领域对于维护健康的生态系统非常重要，无论是在_维护与 L1 和其他 L2 的共生关系方面，还是在保持交易低于 1 美分_方面。

来源： https://dune.com/hildobby/blobs ，截至 2025 年 2 月 7 日

Base 目前消耗大约 35% 的 blobspace，并且是最大的 blob 提交者。随着我们继续扩展，Base 将消耗越来越多的 blobspace。我们已经预料到 L1 DA 是一个扩展瓶颈，并且一直在积极地 (1) 优化 DA 使用，以及 (2) 增加可用的 blobspace 总量。

为了优化 OP Stack 链的 DA 使用，Base 团队帮助在 OP Stack 的批处理过程中实现了 Brotli 压缩。此更改包含在 Fjord OP Stack 硬分叉 中，并使 DA 使用量减少了 35%。OP Stack 贡献者构建的另一项改进（跨度批处理）使各种 OP Stack 链能够通过以更好的格式编码连续的区块来最大程度地减少 DA 使用量。

在 Fjord 中引入 Brotli 压缩后，输入与输出字节的比率从 0.4 变为 0.25（减少约 35%）

在增加总体 DA 方面，我们的团队一直在积极努力地推动和加速 PeerDAS，以通过数据可用性采样解锁更多的 DA。雄心勃勃的目标是 PeerDAS 在启动时包含 50 个 blob 的目标，并最终支持 256 个或更多 blob。这将对于让 10 亿人上链至关重要。要实现这一目标，需要解决许多设计挑战和棘手的技术问题（例如，优化 p2p 层的网络拓扑和带宽问题），我们很高兴与生态系统合作解决这些问题。

我们正在 L1 和 L2 社区中积极合作进行 PeerDAS 研究、实施和测试。我们 强烈主张将其纳入 Pectra 硬分叉中——但最终并未纳入。我们的团队继续优先支持 PeerDAS，在下一个硬分叉 Fusaka 中大幅增加 blob。

不过，我们在 Pectra 中确实取得了一场小的胜利——我们 倡导 并 提供了关于增加 blob 目标的安全性研究。因此，Pectra 将包括将 blob 目标翻倍——目标/限制将从 3/6 变为 6/9。

下图显示了 Base 扩展计划如何受到 blob 限制的影响。此图以及本博客中的所有其他外推图都是估计值，可能会受到多个变量的影响。垂直线显示基于时间的限制：Pectra 是 4 月初的实线（相对设定的时间表），Fusaka 是 12 月的虚线（不断变化的时间表）。水平线传达了与 Base 吞吐量相关的限制：虚线表示当 Base 的规模对应于消耗总体 blobspace 一半时的时间预测，实线表示当 Base 消耗所有 blobspace 时的时间预测。这些估计基于 blob 使用量与吞吐量相对线性的假设。

在 Pectra 之前，我们预计在每秒 30 Mgas 的吞吐量下，Base 将消耗大约 50% 的 blob。这将在 Pectra 上翻倍。当 PeerDAS 在 Fusaka 中落地时，DA 可能会实现我们每秒 2.5 亿 Mgas 的目标。

我们看到，在 Fusaka 落地之前，除非我们在 DA 利用率方面取得重大突破，否则 blobspace 将再次成为扩展以太坊 rollup 吞吐量的障碍。

我们计划支持更频繁和简化的 blob 增加计划（请参阅 OP Labs 的提案），在 PeerDAS 启动后与硬分叉计划分开。我们认为，考虑到如果没有 PeerDAS，我们可能会遇到网络带宽限制，因此只有在 PeerDAS 之后才能进行此操作。我们也认为，社区的重点应仍然放在将 PeerDAS 作为首要任务交付，因为这将是长期内的最大胜利。

同时，我们将继续努力优化 Base 端 DA 的使用。未来的工作可能包括进一步压缩，研究和提出减少批处理到 L1 的数据的方法以及状态差异。即使有了这些优化，我们仍然假设 DA 使用量将随着网络使用量线性增长。一种可以避免这种情况的方法是减少每个 gas 单位的 L1 数据量。这可能看起来像是重新定价操作码或多维费用机制。将某些流量定向到 L3 或将计算卸载到证明者网络也有助于，尤其是在吞吐量要求高的应用程序中。

瓶颈 2 – 客户端执行速度

客户端执行性能是维护健康节点生态系统的关键组成部分，这对于维护_去中心化平台至关重要。反过来，这使 Base 能够处理更多交易，同时保持在亚秒级和亚美分级_。在高负载下，节点可能会落后于网络，最坏的情况是无法赶上。我们必须确保区块构建速度和同步时间在我们继续扩展 Base 时保持可靠。

凭借 Base 当前的 2 秒区块时间，我们为执行速度定义了以下链健康指标：

• 平均 (P50) 区块执行/同步时间：<500 毫秒

• P90 区块执行/同步时间：<1 秒

• P999 区块执行/同步时间：<2 秒

我们对我们的 sequencer 实施了更严格的范围，但是这些 SLO 确保了大多数节点与链的实时状态保持同步。我们将继续评估和重新定义这些 SLO，因为我们监视整个 Base 生态系统的健康状况。

来源： base.org/stats 。Sequencer 节点（左）和 mempool 节点（右）区块构建性能。

自成立以来，Base 一直在运行 op-geth，并且为了维护可靠的基础架构，我们对 Geth 节点进行了多次优化，包括将数据库架构从 LevelDB 迁移到 PebbleDB，以及从基于哈希的存储布局迁移到基于路径的存储布局，这两者都在区块构建速度方面产生了细微的改进。

尽管进行了这些改进，但我们预计将在 Geth 的区块构建速度方面遇到瓶颈，可能在每秒 40–50 Mgas 左右。鉴于此，我们开始对替代的高性能执行客户端进行基准测试。由 Paradigm 团队构建的 Reth 被证明很有希望，p999 区块构建速度提高了约 70%。我们最近发布了一篇 博客文章，其中包含详细的发现。我们正在积极迁移到运行 Reth 的所有节点软件，并鼓励生态系统中的其他人也这样做。我们预计这将使我们现有的限制大致增加 2–3 倍。

客户端性能瓶颈包括 Geth 执行性能的约每秒 40 Mgas 的软限制和 Reth 的约每秒 100 Mgas 的软限制。

作为我们执行客户端性能分析的一部分，我们发现，无论执行客户端如何，状态访问都占用了很大一部分延迟。包含大量存储访问的区块的执行时间几乎是没有存储访问的区块的 30 倍。此外，对于状态访问量最小的工作负载，客户端可能会执行高达约每秒 5 亿 Mgas。由于这一发现，我们正在积极研究可以减少状态访问延迟的数据库架构，尤其是在状态大小继续增长的情况下。

对于未来在客户端执行性能方面的工作，有几个有希望的方向可以探索。由于 EVM 是单线程的，因此并行执行可以使运行现代多线程基础架构的节点更好地利用计算资源。EVM 字节码到本机代码的即时或预先编译可以通过消除解释器的开销来优化执行。可以逐步改进的一个方向是延迟状态根：流水线交易执行将为节点提供两个完整的Slot时间而不是一个来执行交易、存储状态更改和计算状态根，从而使节点用于区块构建的时间大致加倍。此外，如果 sequencer 提供“访问提示”以指示将访问哪些存储Slot，则节点将节省预加载相关状态的时间，而不是实时执行此操作。

瓶颈 3 – 故障证明

故障证明对于 使 Base 成为_开放和去中心化的平台_至关重要。为了确保 Base 保持去中心化，我们必须确保故障证明系统 (FPS) 正常运行，并且扩展不会引入不兼容性。

为了使 FPS 按预期工作，至少需要一个诚实的参与者（运行挑战者软件的节点）参与以正确地捍卫对系统的挑战。正如在 以前的博客 中共享的那样，我们创建了一个基准测试系统，以验证对 FPS 的任何挑战都可以在允许的时间范围（“挑战窗口”）内成功解决。博客中共享的初始结果表明，Base 上现有的 FPS 可以舒适地将 Base 区块扩展到 1.2 亿 gas（30 Mgas/s）的限制，主要约束来自内存使用。最近的基准测试显示了更有希望的结果 - 可能支持高达 80–90 Mgas/s 的 gas 限制。

这远远低于我们 2025 年底每秒 2.5 亿 Mgas 的目标。还值得注意的是，要实现 2.5 亿 Mgas 作为该年度的 gas 目标，我们实际上需要故障证明来支持 5 亿 Mgas/s 的 gas 限制。请注意，该协议将 gas 目标与限制的比率限制为 1:2，但是 2:3 的比率通常为流量高峰提供足够的缓冲。要修改此设置，我们需要 OP Stack 协议更改或 在 sequencer 端设置限制。

我们正在将精力集中在几个领域来实现这些目标。OP Labs 对 OP Stack 中现有的 FPS 进行了重大改进，以解决内存使用瓶颈。这些更改包括启用 go 运行时的垃圾回收以防止失控的内存使用增长，以及从 32 位 MIPS 架构迁移到 64 位 MIPS 架构以允许更大的堆大小。这应完全消除内存问题，这意味着速度成为唯一的约束。我们目前正在审查和基准测试这个更新的 FPS，称为多线程 + 64 位 Cannon，但它可能会支持高达约每秒 50 Mgas 的 gas 目标。它计划在第二季度初上线。

现有的 FPS 支持约 60 Mgas/s 的限制（30 Mgas/s 的目标）。新系统可能会支持约 1 亿 Mgas/s 的限制（约 50 Mgas/s 的目标）。

此外，Base 工程团队支持了最近的 Holocene OP Stack 硬分叉 中 部分跨度批处理验证 的开发，以减少故障证明程序需要一次执行的区块数量，从而减少资源约束。

但是，即使有了这些新的改进，现有的故障证明系统仍使用 Geth 作为默认客户端。随着我们不断迁移到 Reth，我们对基于 Reth 的 FPS 越来越感兴趣。OP Labs 已经创建了一个名为 Kona 的实现，我们也开始对其进行审查。我们认为这可以为扩展解锁逐步改进。

展望未来，基于 ZK 的故障证明系统可以提供另一个主要的解锁。

瓶颈 4 – 状态和历史增长

保持健康的状态大小和增长率对于_节点运营商的健康和分布式生态系统_至关重要。如果节点运营商看到节点上的磁盘空间不足以存储活动状态或历史状态，他们通常可以扩展其基础架构以使用更大的实例。但是，云基础设施提供商提供的最大实例大小存在限制——历史上为 30TB 的低延迟存储。最近，更大的实例变得可用（AWS 现在提供高达 120TB 的选项），这推高了这个硬限制。值得注意的是，这些是我们无法自行撤消的硬限制。如果我们扩展 Base 并且节点上的磁盘空间不足，则缩减规模不会解决此问题。

在 base.org/stats 上，我们有 Geth 和 Reth 存档节点的磁盘使用情况的可视化效果。存档节点存储整个历史状态，因此它们的磁盘使用量会随着时间的推移而继续增长。这些图显示了现有使用情况和未来 1 个月和 6 个月的预计增长情况。这些图说明了我们 迁移到 Reth 的另一个原因——Reth 在整体历史状态以及增长率方面都显示出非常有希望的改进。如果我们认为 30TB 是上限，那么我们预计使用 Geth 将在 6 月底达到此限制，而使用 Reth，基于当前平均每天约 8.5 GB 的增长率，将需要超过 10 年的时间。

来源： base.org/stats 。磁盘使用情况作为 Geth 和 Reth 存档节点上历史增长的代理。

请注意，上述数字未考虑 Base 的扩展计划。根据我们的初步分析，磁盘使用量增长与 gas 增加_并非_超级相关，即更高的吞吐量并未导致增长率增加。这是因为历史增长更多地取决于使用模式而不是总体吞吐量，这可能表明即使 gas 增加，促成历史增长的因素也相对稳定。

Geth 和 Reth 存档节点在 Base 达到某个 gas 目标（吞吐量）时，每天的平均磁盘使用量增长，作为历史增长的代理。出乎意料的是，随着 Base 扩展，没有明显的上升趋势。请注意，Geth 缺少一些数据。

但是，吞吐量的增加肯定会增加历史状态更快增长的可能性，尤其是在越来越多的用户来到链上的情况下，因此这些指标是我们继续关注的内容。

为了解决历史增长问题，我们已经将大部分节点迁移到 Reth，并且正在努力消除对 Geth 存档节点的剩余依赖性。将来，我们可能会考虑使用替代解决方案来存储和检索历史状态，例如 Portal Network 或传统的分片数据库。

即使进行了完整的 Reth 迁移并拥有更多的磁盘空间，状态仍将继续增长，并且最优化客户端最终将仅从活动状态达到上限。因此，我们必须考虑更长期的解决方案，例如更智能地存档历史状态或使非活动状态过期，以防止不受控制的增长。

一个基于未来的未来

结合到目前为止描述的所有内容，下图显示了我们预期的扩展瓶颈的完整图景。我们将不得不解决许多具有挑战性的问题，以及可能未在此处描述的其他一些未知问题，才能实现我们 2025 年每秒 2.5 亿 Mgas 的目标。

Base 的扩展轨迹与今天估计的最佳所有扩展瓶颈叠加在一起。

我们还认识到，某些应用程序可能对速度和吞吐量有更高的要求，但对以太坊 L2 的安全保证的要求较低，例如游戏，这可能会超过 Base 的扩展能力。L3 Appchains 可能为托管这些应用程序提供了一个不错的选择。

一起扩展

如果没有生态系统中许多团队的支持，我们将无法自推出以来将 Base 扩展近 10 倍——我们将继续合作以进一步扩展它。我们希望这些扩展 Base 的努力能够提供经验和基础设施，以使其他 L2 和以太坊生态系统的其余部分也能够扩展。

2025 年是我们一起扩展的一年。我们正在寻找合作伙​​伴来应对诸如交付 PeerDAS、状态差异、重新构建存储/数据库层、ZK 故障证明和状态过期等挑战。如果你有兴趣研究创意和雄心勃勃的扩展解决方案，以使接下来的 10 亿人能够来到链上，我们正在招聘——我们很乐意收到你的来信。

在社交媒体上关注我们，以获取最新信息：X (X 上的 Base 团队) | Farcaster | Discord

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