扩展Base：第二季度达到50 Mgas/s

要点：为了构建一个全球链上经济，我们需要扩展以保持 gas 费用低于 1 美分。我们 2025 年的目标是达到 250 Mgas/s 的 gas 目标——比我们开始时提高 100 倍。在第一季度，我们实现了一个重要的里程碑：25 Mgas/s，比启动时提高了 10 倍。我们现在有望在第二季度末达到 50 Mgas/s。本季度回顾提供了关键扩展瓶颈的最新状态，以及我们消除这些瓶颈的进展。

Base 的使命是构建一个全球链上经济，以增加创新、创造力和自由。为了实现这一目标，Base 2025 年的五个战略支柱 之一是扩展 Base 并降低 gas 费用，以便各地每个人都可以上链。2024 年，我们将 Base 扩展到 20 Mgas/s——几乎是我们开始时的 10 倍。今年的目标是将 Base 的 gas 目标扩展到 250 Mgas/s——增加 Base 处理更多交易、更多构建者和更多链上用户的能力。

今年年初，我们发布了我们 2025 年扩展 Base 的方法。今天，我们将分享迄今为止的进展更新，以及我们继续提高 Base 吞吐量和消除关键瓶颈以加速进一步发展时最关心的问题。

瓶颈回顾

在之前的扩展博客中，我们概述了我们正在努力消除的扩展瓶颈，以加速实现 2025 年 250 Mgas/s 的目标。在这里，我们将提供进入第二季度的这些瓶颈的更新。

瓶颈 1 - L1 数据可用性

Blobspace 已经满负荷运行了好几个月。Pectra 硬分叉将于 5 月 7 日在 Ethereum Mainnet 上激活，它将使 blob 数量增加一倍，并为 L2 扩展提供更多空间。在 Pectra 中将 blobspace 增加一倍是 Base 团队过去一年的主要目标，我们很高兴看到它成为现实。

我们知道，并且已经知道一段时间了，这只是一个暂时的胜利——生态系统可能会在激活后不久就耗尽该 blobspace。因此，我们继续与 Ethereum 基金会、各种 EL 和 CL 客户端以及其他 L2 合作，大力投资于 PeerDAS，以实现 L1 数据可用性的大幅增加。

PeerDAS 将包含在 Pectra 之后的 Fusaka 硬分叉中，该硬分叉将于今年第三季度发布。这个时间表非常激进，但通过正确的关注和投资，我们可以实现这一目标，使其成为扩展 Ethereum 的一个重要突破。我们认为，Fusaka 的时间表延迟是 Ethereum 在未来一年成功支持大规模采用的最大风险。

如果 PeerDAS 按计划发布，我们预计更新后的瓶颈图如下所示。

Pectra 将于 5 月 7 日使 blobspace 增加一倍，从而为扩展提供更多空间。最大的胜利将是 PeerDAS 落地。

瓶颈 2 - 客户端执行速度

客户端执行速度可以分为两类：区块构建性能（排序器创建区块的时间）和验证器性能（验证器同步区块的时间）。鉴于执行客户端性能是这两者的基础，我们继续将它们视为一个瓶颈。

我们解决客户端执行速度的主要重点是完全停用 Geth Archive 节点。我们已经将几乎所有节点（包括排序器节点）从 Geth Archive 迁移出去，并鼓励其他人也这样做。只剩下与容错证明相关的最后一个对 Geth Archive 的依赖，这也将很快消失。

EL 性能限制的一个主要来源——我们之前已经确定并继续使用真实世界的数据进行验证——是本地磁盘上数据库访问导致的大量延迟。我们正在积极地进行原型设计，并将很快分享有关减少此延迟的解决方案的更多详细信息。

当我们从 Geth 迁移时，我们客户端性能瓶颈的更新视图。当我们迁移到 Reth 作为默认客户端时，Geth 瓶颈将会消失，并且我们预计 Reth 性能也会随着数据库访问延迟的优化而提高。

瓶颈 3 - 容错证明

到 4 月底，Base 将升级到新版本的 Cannon，Cannon 是 Base 今天容错证明系统底层的虚拟机。更新后的版本由 OP Labs 构建，将 Cannon 的内存架构从 32 位扩展到 64 位，并具有内置的多线程支持。这两项改进通过几乎完全消除当前容错证明系统的两个扩展瓶颈（内存使用和挑战者运行时）提供了一个很大的扩展优势。

我们的初步审查表明，我们称之为 MT64Cannon 的新 Cannon 完全消除了我们在 Cannon 中确定的内存限制，并显着减少了挑战者运行时。

为了确保 MT64Cannon 继续支持 Base 的扩展目标，我们正在跟踪诸如挑战者成功/失败、挑战者运行时、内存使用和 MIPS 指令计数等指标。

随着我们大力推动迁移到 Reth，我们已将容错证明确定为 Geth 的最终依赖项之一。因此，我们已大量投资于为 op-program 添加 Reth 兼容性，以消除此最终依赖项。这项工作已完成代码，应该很快就会落地。

虽然 MT64Cannon 可能会支持我们 2025 年的扩展目标，但它不会永远支持 Base 的扩展。我们目前正在评估性能更高的替代方案，包括完全基于 Reth 的容错证明系统。

当我们迁移容错证明系统时，容错证明瓶颈的更新视图。

瓶颈 4 - 状态和历史增长

在之前的扩展审查中，我们分享了我们的目标是保持节点磁盘使用量（作为历史增长的代理）低于 30 TB，这个限制是基于流行的云提供商今天提供的 NVMe SSD 驱动器。Geth Archive 已经超过了这个阈值，这也是我们完全从 Geth Archive 迁移出去的另一个原因。我们强烈建议仍在运行 Geth Archive 节点的任何人迁移到 Geth Full 或 Reth Archive 节点。

鉴于消除了 Geth Archive 依赖项，我们预计扩展到 250 Mgas/s 不会有任何瓶颈。

瓶颈摘要

结合所有瓶颈，我们得到以下图表。

与几个月前的图表相比，我们看到我们在消除瓶颈方面取得了重大进展。

但这仍然是第一天——还有很多工作要做，才能继续以我们计划的速度扩展 Base。

安全性和可靠性

我们团队的主要重点是安全地扩展。我们有非常雄心勃勃的扩展目标，但不会以牺牲链的安全性或可靠性为代价来推动这些目标。

在过去的六个月中，我们大力投资于优化内部 Base 基础设施，以确保它在扩展时可靠地运行。我们为每次提高 Base 的 gas 目标都建立了一个内部的 go/no-go 流程，以确保在增加之前我们的指标是健康的。

我们还在构建一个全面的基准测试工具，使我们能够根据我们正在扩展到的未来 gas 限制（而不仅仅是当前的 gas 限制）来验证系统性能。这将通过主动发现未知的未知数来为我们提供更大的扩展信心，尤其是在我们进行更大的 gas 目标增加时。

当我们加速扩展时，我们希望确保除了拥有健康的内部基础设施之外，生态系统的其余部分也保持健康。Base 已经达到这样的规模，即不运行正确的节点配置可能会导致节点落后。我们已经看到过这样的情况：我们的内部节点跟上了流量，但我们收到了外部节点落后的报告。我们建议所有节点运营商定期查看我们的文档 (docs.base.org) 并订阅我们的状态页面 (status.base.org)，以获取最新的硬件和客户端配置建议。可以假定我们在官方文档中提供的建议已经通过了我们的基准测试。

展望未来

如果没有整个生态系统中许多团队的支持，我们就无法将 Base 扩展到今天的规模——我们将继续合作以进一步扩展它。我们希望扩展 Base 的这些努力能够提供经验和基础设施，以使其他 L2 和 Ethereum 生态系统的其余部分能够扩展。

2025 年是我们共同扩展的一年。我们正在寻找合作伙​​伴来应对诸如发布 PeerDAS 和优化执行客户端和容错证明系统性能等挑战。如果你有兴趣致力于创造性和雄心勃勃的扩展解决方案，以使下一个 10 亿人能够上链，我们正在招聘——我们很乐意收到你的来信。

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

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