使用 Reth 扩展 Base

解锁 Base 的未来

介绍

Base 的核心原则之一是以开放的方式进行构建，包括与 Base 社区讨论我们的工作。今天，我们启动 Base 工程博客，以更多地做到这一点。我们的第一篇博客文章将探讨我们在扩展执行层客户端方面的技术努力。

为了继续扩展 Base，我们计划将 Reth 用于我们所有的存档节点，并将持续投入资金，以确保 Reth 与 OP Stack 无缝集成，并对 Base 运营商保持用户友好。我们鼓励其他人也这样做。

使用 Reth

一个 Base 节点由两部分软件组成：一个共识客户端（例如 op-node）和一个执行客户端，它负责处理用户交易、构建区块和提供 RPC 调用。作为我们继续扩展 Base 的努力的一部分，Base 核心团队一直在严格评估各种执行客户端的性能。

目前，OP Stack 链主要使用 Geth，因为它是规范的 OP Stack 执行客户端。但是，还有其他客户端，如 Reth 和 Nethermind，它们支持 OP Stack 链 —— 每个都有自己的设计和权衡。我们的长期愿景是 Base 成为一个多执行客户端链，其中有多个客户端用于排序和验证链。这对于任何高可用性链至关重要。通过同时运行 Reth 和 Geth，我们已经避免了 Base 上的多次中断 [ 1]

扩展执行客户端性能受到各种硬件限制的约束（请参阅 Paradigm 的这个博客系列）。虽然 Geth 一直是 Base 一个非常稳定和高性能的执行客户端，但由于网络使用量的增加，我们开始遇到挑战：

• 磁盘使用量要求 - 运行 Base Geth 存档节点所需的磁盘空间正在以每周约 500Gb 的速度增长。

• 配置新节点 - 考虑到大型数据库大小，在配置新的 Geth 存档节点时，需要约 15 小时才能下载快照并同步到最新状态。

• 长时间运行的数据库压缩 - 随着写入流量的增加，我们遇到了长时间运行的 数据库压缩，导致 Geth 节点落后。

我们最关心的是运行 Base 存档节点的存储要求，这会影响前两个要点。这尤其重要，因为我们建议使用 NVMe 存储来运行节点，对于许多节点运营商来说，NVMe 存储的软限制为 30TB，最大限制为 60TB。 [2]

为什么使用 Reth？

Reth 有几个吸引人的品质。在确定要探索哪些执行客户端时，有几个最初引起了我们的注意：

• OP Stack 支持 - Reth 有 内置的 OP Stack 支持。

• 不断增长的生态系统 - 正在创建大量基于 Reth 的 OP Stack 工具（例如 Kona, op-succinct）。

此外，Reth 在一些方面有所改进，我们决定自己进行基准测试：

• 减少磁盘使用量 - Reth 具有不同的 数据库结构，与 Geth 相比，它需要的存储空间要少得多。这种设计在存储历史状态方面尤其有效。

• EVM 性能 - Revm 承诺提高性能，使我们能够进一步扩展 Base。

从我们最新的基准测试中，你可以看到这些品质的影响。我们看到 Reth 在磁盘使用量和区块构建性能方面都比 Geth 有了很大的改进。

(加粗方法 如下 )

磁盘使用量增长速度慢了一个数量级 意味着 Reth 存档客户端可以在当前增长率下保持在 30TB NVMe 限制以下，直到 2030 年代中期，而对于 Geth，我们预计在 2025 年 5 月左右达到该限制。

加粗每个客户端的状态大小

最后，我们在将 Base 基础设施的部分迁移到 Reth 的初始工作中发现，Reth 还有一些其他好处：

• 对贡献者友好 - 我们已经能够轻松地添加对一些 OP Stack 硬分叉的支持（Fjord, Holocene）。

• 更快的历史同步 - 我们发现 Reth 的分阶段同步允许新节点更快地同步到链的最新状态。

我们观察和基准测试的所有 Reth 的好处使我们将 Reth 视为 Base 的核心执行客户端。

为未来做准备

在短期内，我们将 Reth 用于我们所有的存档节点，同时继续为排序器运行 Geth 全节点。我们将继续投资，以确保 Reth 完全支持 OP Stack，并且可以轻松运行 Base Reth 节点。在 2025 年，我们的目标是将 Reth 也用于排序 —— 这使我们离 gigagas 更近了一步。

节点运营商

2025 年初

从 2025 年初开始，我们希望鼓励节点运营商开始评估 Reth 用于其存档节点。为了帮助实现这一目标，我们每天都有 Reth 快照 和 Base 特定的 Reth 映像。

2025 年 5 月

我们预计 Geth 的存储需求将约为 30TB。我们建议运行 Reth 存档节点和 Geth 全节点。

在 Geth 和 Reth 之间发生分叉的极不可能的情况下，Geth 链仍将被视为规范链。

核心网络

现在

对于排序和故障证明，Base 将继续使用 Geth 全节点和 op-program（规范的故障证明实现），因为 Geth 是 op-stack 的参考客户端，并且 op-program 故障证明程序使用 Geth EVM。

对于我们运营的其他节点，我们正在运行重复的 Reth 和 Geth 集群。如果你最近在 Base 上发送了一笔交易，它很可能是通过 Reth 节点发送的！

2025 年底

一旦有可用于生产的 Kona 和 Asteric 版本，我们计划使 Reth 成为 Base 的规范客户端。这意味着，如果执行客户端出现分歧，Reth 将被视为真理的来源。我们相信这将有助于解锁 Base 可扩展性的下一个篇章。

2026

我们的长期目标是为所有核心网络节点至少拥有三个执行客户端。

拥有多个客户端、证明器和一个强大的多重证明系统将使我们能够从单个参考客户端过渡到排序和证明的 ⅔ 共识方法。

结论

当我们继续扩展 Base 时，优化执行客户端对于性能和效率至关重要。使用 Reth 将帮助我们解锁 Base 扩展到 1 Gigagas/秒的下一个篇章。

我们要感谢我们在过去一年中与之交谈和合作的所有执行客户端团队，特别感谢 Reth 团队（尤其是 Georgios 和 Matthias）。

请继续关注更多更新，因为我们将朝着让 10 亿人加入链上的目标前进。

常见问题解答

同时运行 Reth 和 Geth 阻止了哪些事件？

1. LevelDB Geth 存档节点上长时间运行的数据库压缩

   1. 在此期间，我们有几个核心网络 Geth 节点发生了 30 多分钟的压缩，在此期间节点不可用。Reth 节点继续传播区块并处理来自用户的新交易。

2. Geth 的错误配置

   1. 我们错误地配置了 Geth 内存池节点上的 gas 限制，这导致它们分叉到自己的链上。
   2. 由于 Reth 节点是单独配置的，因此它们继续正常运行。

为什么存在此限制？

云提供商对具有 NVMe 存储的服务器的配置有限制。例如，在 AWS 上，最快的 NVMe 机器类型是 i4i，其限制为 30TB。它们还提供了一种速度较慢的 NVMe 机器类型 i3en，它提供的 NVMe 驱动器高达 60TB。

如何运行基准测试？

• 测试在 i3en.12xlarge 上运行

• NVMes 以 RAID0 形式组合在一起并格式化为 EXT4

• 然后通过 replayor 提取区块，并记录结果。

• Reth 和 Geth 都配置为存档节点

• Geth 配置为使用 LevelDB 和 hashdb。

• 在 Base 主网上有 5,000 个区块范围（从 13087231 到 13092230），请注意，选择此范围是因为它具有大量昂贵的区块。

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