Anika Raghuvanshi

概要： 为了构建全球链上经济，我们需要扩展。为了达到 1 Ggas/s 的最终目标，我们正在规划一条在 2025 年实现 250 Mgas/s 的路径。我们的主要关注点是：增加 L1 数据可用性以支持 Rollup，提高客户端执行速度，确保故障证明（Fault Proofs）继续按预期运行，以及保持节点健康的磁盘使用量。

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

我们的 2025 年目标要求我们以指数级的速度进一步扩展，使吞吐量比现在高出 10 倍以上，是 Base 最初推出时的 100 倍。这是让 10 亿人参与链上经济的关键：扩展使 Base 能够支持更大的负载，同时保持较低的用户成本。低费用反过来又能让世界上更多的人参与到链上经济中来。自 Base 成立之初，我们就强调扩展吞吐量以保持用户低费用的重要性。Base 工程团队与以太坊生态系统密切合作，通过 EIP-4844 扩展以太坊数据可用性，从而使 Blob 能够降低 L2 的 L1 费用，最近我们还参与了增加 L1 Blob 容量的工作。

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

扩展 Base

我们吞吐量的最终目标是 1 Ggas/s（读作“每秒十亿 Gas”），约为今天的 40 倍。Base 需要至少扩展这么多，才能支持 10 亿用户在链上进行交易，同时确保交易费用保持在亚美分级别。

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

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

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

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

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

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

瓶颈 1 – L1 数据可用性 (DA)

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

自从 2024 年 11 月以来，Blob 一直处于目标水平。来源：https://dune.com/hildobby/blobs

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

来源：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 贡献者构建的另一项改进 span batches 允许各种 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/s 的吞吐量下，Base 将消耗大约 50% 的 Blob。在 Pectra 中，这一比例将翻倍。当 PeerDAS 在 Fusaka 中落地时，DA 可能会使我们能够实现 250 Mgas/s 的目标。

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

我们计划支持更频繁和简化的 Blob 增加时间表（参见 OP Labs 的提案），该时间表与 PeerDAS 上线后的硬分叉时间表分开。我们认为，鉴于我们没有它可能会遇到的网络带宽限制，因此只有在 PeerDAS 之后才能追求这一点。我们还认为，鉴于这将是长期的最大胜利，因此社区的重点应该仍然是尽快发布 PeerDAS。

与此同时，我们将继续努力优化 Base 端的 DA 使用率。未来的工作可能包括进一步压缩、调查并提出减少批量发送到 L1 的数据量以及状态差异的方法。即使进行了这些优化，我们仍然假设 DA 使用率将与网络使用率一起线性增长。一种可以避免这种情况的方法是减少每个 Gas 单位的 L1 数据量。这可能看起来像重新定价操作码或多维费用机制。将一些流量引导到 L3 或将计算卸载到证明者网络也有帮助，特别是对于具有高吞吐量要求的应用程序。

瓶颈 2 – 客户端执行速度

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

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

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

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

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

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

来源：base.org/stats。排序器节点（左）和内存池节点（右）区块构建性能。

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

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

客户端性能瓶颈包括 Geth 执行性能的 ~40 Mgas/s 的软限制和 Reth 的 ~100 Mgas/s 的软限制。

作为我们执行客户端性能分析的一部分，我们发现，无论执行客户端如何，状态访问都占用了大量的延迟。包含大量存储访问的区块的执行时间几乎是没有存储访问的区块的 30 倍。此外，对于状态访问量最小的工作负载，客户端可能会执行高达 ~500 Mgas/s 的操作。由于这一发现，我们正在积极研究可以减少状态访问延迟的数据库架构，特别是随着状态大小的持续增长。对于客户端执行性能的未来工作，有几个有希望的方向可以探索。由于 EVM 是单线程的，因此并行执行可以使运行现代多线程基础设施的节点更好地利用计算资源。将 EVM 字节码即时或提前编译为本机代码可以通过消除解释器的开销来优化执行。一种可以逐步改进的方向是延迟状态根：流水线交易执行将为节点提供两个完整的插槽时间而不是一个来执行交易、存储状态更改和计算状态根，从而大致使节点构建区块的时间加倍。此外，如果排序器提供“访问提示”以指示将访问哪些存储插槽，则节点将节省预加载相关状态的时间，而不是实时执行此操作。

瓶颈 3 – 故障证明

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

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

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

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

现有的 FPS 支持 ~60 Mgas/s 的限制（30 Mgas/s 的目标）。新系统可能会支持 ~100 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 是限制，我们预计将在 6 月下旬达到 Geth 的限制，而对于 Reth，基于当前约 8.5 GB/天的平均增长率，达到这个限制将需要超过 10 年的时间。

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

然而，增加的吞吐量肯定会增加历史状态增长更快的可能性，尤其是在更多用户上线的情况下，因此我们会继续密切关注这些指标。

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

即使完全迁移到 Reth 并拥有更多的磁盘空间，状态仍然会继续增长，并且即使是最优化的客户端最终也会遇到仅来自活动状态的上限。 因此，我们必须考虑更长期的解决方案，例如更智能地存档历史记录状态或使不活动状态过期，以防止不受控制的增长。

未来愿景

综合以上所述，下图展示了我们预计的扩展瓶颈的整体情况。为了实现我们 2025 年达到 250 Mgas/s

的目标，我们将不得不解决许多具有挑战性的问题，以及一些此处未描述的、可能出现的未知问题。

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

共同扩展

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

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