目录

• 1. 什么是 Reth？
• 2. 为什么 Paradigm 要构建一个新的 Rust Ethereum 客户端？
  • 1. 为实力用户构建一个高性能节点
  • 2. 通过改善客户端多样性，为以太坊的稳定性做出贡献
  • 3. 通过对路线图的贡献，回馈以太坊
• 3. 为什么 Reth 是一个新的代码库而不是对现有代码库的贡献？
• 4. 这个准备好使用了吗？
• 5. 在你完成全同步后，路线图是什么？
• 6. 向所有贡献者致敬

我们很高兴地宣布 Reth，这是由 Paradigm 构建的一个免费的开源以太坊执行层客户端。 在这篇文章中，我们将讨论为什么我们会创建 Reth，以及未来对我们的期望。

什么是 Reth？

Reth（Rust Ethereum 的缩写， 发音）是一个新的以太坊全节点实现，专注于用户友好、模块化、快速和高效。Reth 是一个与所有支持 Engine API 的以太坊共识客户端实现兼容的执行客户端。作为一个完整的以太坊节点，Reth 将允许用户从创世时代同步完整的以太坊区块链，并在同步后与其互动（如果处于归档模式，也包括其历史状态）。

我们构建 Reth 是为了适应广泛的用户群体，包括权益证明用户、爱好者、RPC 节点操作员、跨链桥、MEV 搜索者，甚至是 L2（例如 Optimism/Arbitrum）或其他以太坊相关项目（例如 Polygon、BSC、Avalanche、Fantom 等）。这些用户的需求往往非常多样（例如，爱好者和权益证明用户更希望节点能够在廉价硬件上运行，而 RPC 节点操作员则可能拥有昂贵的磁盘和云快照）。Reth 并不试图一次性满足所有需求。相反，我们致力于创建一个可配置节点，从而让用户根据自己的需求探索权衡空间。

Reth 仍在不断发展中，可能会经常更新。代码尚未经过审计，不应在生产环境中使用。然而，为了透明和与以太坊的价值观一致，我们今天开放源代码并分享我们的愿景。

代码可在 GitHub 上以 Apache/MIT 许可证免费使用，任何人都可以在没有任何附加条件的情况下使用。我们鼓励社区进行分叉，贡献文档、问题、拉取请求、提问或甚至尝试破坏它。我们迫不及待地想看看你们的想法！

话虽如此，让我们深入探讨。

为什么 Paradigm 要构建一个新的 Rust Ethereum 客户端？

在 Paradigm，我们一直在寻找推动前沿的方法。通过 ethers-rs、Foundry 和 revm，我们构建了一套成熟的工具来操作 EVM。于是我们想：“接下来是什么？” 答案就是 Reth。

通过 Reth，我们希望：

为实力用户构建一个高性能节点

我们是以太坊生态系统的实力用户，并且一直与实力用户合作。所以我们希望构建一个既有性能又能进行专家级调试的节点。

Reth 的目标是在各个维度（CPU/内存/带宽/磁盘空间）提供一流的性能，或提供可配置的配置文件，让用户能够探索每种模式之间的权衡（磁盘空间与 延迟/吞吐量）。

我们正在构建 Reth，使每个组件均可作为库在用户的技术栈中使用。例如，一个索引公司可以使用超快速的数据库绑定来提高其表的重新索引性能。或者一个 ERC4337 包装器可以利用 EVM 和数据库绑定为钱包用户提供模拟服务。

通过 Reth，我们希望节点栈的每个组件能够多次解耦和再捆绑，让实力用户探索所需功能的高效边界。我们也希望在设计和代码或 FFI 绑定方面（如果你想从任何语言构建与 Rust 的绑定，请联系我们）采用最优成分，并将其上游到其他实现中。

通过改善客户端多样性，为以太坊的稳定性做出贡献

当没有任何客户端的市场份额超过 66% 时，以太坊协议从客户端多样性中获益。这有助于跨客户端测试实现的正确性和以太坊协议的去中心化开发。它还避免了在存在软件错误时最终确定区块等情形。

通过 Reth，我们希望增加生态系统中客户端的数量，以促进网络的健康，同时保持对共识关键采用的审慎。

通过对路线图的贡献，回馈以太坊

多年来，以太坊协议和以太坊节点代码库经历了显著演变，仍在不断发展。EIP1559、合并和 EIP4844 等变更凸显了节点层的创新必须以迭代方式发生，所有测试、基准测试和文档都应该达到最高标准。

此外，社区期望核心开发者维护网络并保持其健康。他们还期待核心开发者在紧迫的时间框架内推出来自研究方向的创新，尽管有时范围或边缘案例不明确。我们希望以太坊协议能够持续创新，并希望以太坊节点保持稳健，同时我们也意识到这可能会产生一定的紧张关系。

通过 Reth，我们将和大家一起深入建设，并希望能够减轻核心开发者的一些压力。我们也希望通过新的研究、代码和架构推动前沿，并为以太坊路线图上即将到来的重要里程碑作出贡献。

为什么 Reth 是一个新的代码库而不是对现有代码库的贡献？

作为开源开发者，我们审视了市场上每个客户端的实现，并全面考虑是对现有客户端进行贡献还是分叉。不幸的是，我们无法找到能够满足所有需求的现成解决方案，也无法合理地使其满足我们。

因此，我们决定从零开始构建 Reth，遵循以下标准：

• 性能： 我们希望 Reth 提供业界领先的性能。为此，我们决定使用 Rust 作为我们的编程语言，并采用 Erigon 团队首创的 分阶段同步节点架构。
• 模块化： 我们希望用小型、良好抽象、经过良好测试和基准的包来构建 Reth。这使得贡献者可以将 Reth 部件用作库，降低了贡献的难度。这样，开发者无需担心整个节点，可以在数小时或数天内对小型、易于入门的包进行贡献，而不是数周或数月。
• 经过实战测试的技术栈： 我们希望 Reth 使用我们经过实战测试和优化的技术栈，包括来自 Foundry、ethers-rs 和 revm 的技术。
• 稳定性： 我们希望 Reth 建立在稳固的基础上，这首先源于语言和编译器。我们仅使用稳定的 Rust 及其稳定特性，并确保所用的 crates 维护良好。我们也设计了我们的抽象，以防任何 crate 突然失去维护而我们又不愿意自己维护的情况下，我们可以在不重新设计整个节点的情况下更换新 crate。
• 归档节点和追踪支持： 除了支持以太坊的合并后检查点同步外，我们还认识到行业对高保障归档节点和高性能追踪的依赖，后者对于核心节点操作外围基础设施至关重要。我们希望 Reth 提供最高性能的历史节点访问和高吞吐量/低延迟的调用（trace_call / trace_callMany 等）以及在链顶和历史上的操作码追踪（ debug_traceTransaction）。
• 许可证： 我们希望 Reth 具有宽松的许可证，以便第三方可以在不受我们项目许可证限制的情况下使用其高性能和模块化的组件。Apache/MIT 许可证是这一点的关键要求。

如果未来出现新的架构或技术栈性能优于当前的最佳实践，我们持开放态度进行修改。我们希望鼓励社区向我们提出他们希望在 Reth 中看到的想法。毕竟，我们是热衷于试验者，这是一种为探索而构建的软件。

这个准备好使用了吗？

Reth 仍在发展中，始于 2022 年 9 月 20 日。

在短短三个月内，我们已经构建了以下内容：

1. 通用的区块头和区块下载器
2. 通用数据库和编解码抽象
3. 一个通用的 mempool
4. 一个新的 p2p 栈
5. 一个快速的 EVM 执行器
6. “核心”同步阶段（区块头/区块体/发送者/执行）
7. 对每个包进行模糊测试和基准测试的基础

我们尚未完全实现或测试以下内容：

1. PoW（工作量证明）和 PoS（股权证明）的共识验证
2. 其他 Erigon 风格的阶段（中间哈希和其他数据库索引）
3. 执行期间的某些验证检查（或状态测试）
4. 完整的 JSON-RPC 支持（我们已经在 Anvil 中实现了大部分 RPC，包括 trace_*，因此不应是个大工程）
5. 在 CLI 中将每个组件连接到阶段循环以执行完整同步
6. 确保在同步顶端或传播 mempool 交易时 P2P 网络正常工作
7. 完整的以太坊测试套件合规性（包括 Hive 支持，使用/改善 retesteth-类似软件，并将我们的规范发现上游到 execution-specs）

我们预计将在 2023 年第一季度初实现从创世的完整同步。与此同时，我们正在努力确保每个代码库 crate 的良好文档、良好的抽象和测试 - 请参见此处获取项目布局。

在你完成全同步后，路线图是什么？

在开发节点的过程中，我们对以太坊协议的工作方式和节点的构建有了很多了解。为了促进知识转移，并使其他人更容易了解节点，我们将发布 Reth Book，这是一份关于如何成为以太坊节点开发者的教育资源。

我们也很高兴开始实验，首先将研究在随机读写下的磁盘 I/O 问题。磁盘 I/O 实际上是有关性能的每次讨论中的最低共同分母，解决这个问题将为整个节点操作的性能提升和成本节约解锁潜力。

我们仍在探索中，但我们希望回答对研究感兴趣的人提出的一些问题：

1. 我们能否预先获取数据，以便在查询内存映射数据库时，可以“免费”缓存其他值，而不是进行新的数据库查询？
2. 我们能否静态分析一个区块，从而在不执行的情况下预测所有已触及的存储槽？例如，预热所有与 Uniswap 相关的存储槽？我们是否应该进行历史分析以了解工作负载的样子？
3. 我们能否对 EVM 操作进行流水线处理和批量处理? 例如，我们能否在“批量写入”和“批量读取”过程中检测到多个交易中的 SLOAD/SSTORE 调用，并在数据库查询上保存它们？我们能否让一个代价高昂的操作码在需要结果之前在后台执行？
4. 我们能否通过检测指令序列的 N 次执行进一步优化 EVM，而不是逐一执行（EVMone 已在这方面取得了一些进展）？

如果这些问题是你能帮助我们的部分，请联系我们。

向所有贡献者致敬

在开发节点的过程中，我们考察了其他节点的设计决策，以了解哪些做得好，哪些不足，以及我们可以如何改进现状。

特别感谢以下团队：

• Geth: 我们衷心感谢 go-ethereum 团队多年来对以太坊的杰出贡献。他们不懈的努力和奉献精神帮助塑造了以太坊生态系统，并使其成为今天充满活力和创新的社区。感谢你们为项目所付出的艰辛。
• Erigon（前称 Turbo-Geth）：Erigon 首创了 Reth 使用的 "分阶段同步" 架构， 并 引入了 MDBX 作为首选数据库。我们感谢 Erigon 推动在以太坊节点性能极限上的最前沿研究。
• Akula: Reth 使用了 Apache 版本的 Akula 的 MDBX 绑定、FastRLP 和 ECIES 的分支。鉴于这些包已经在 Apache 许可证下发布，并实施了标准化协议而没有太多改进的空间，我们决定不重新实现它们。感谢 Akula 团队对 Rust Ethereum 生态系统的贡献，以及发布这些包。

我们还感谢 Nethermind 和 Besu 团队对客户端多样性的贡献，并希望未来找到合作的机会。

总结

Paradigm 正在构建 Reth，一个 Rust Ethereum 执行层。Reth 是以太坊协议的全新全节点实现，具有 Apache/MIT 许可证，专注于对贡献者友好、模块化和性能。

我们还对我们的代码库感到兴奋，它可以作为新 Rust 开发者的孵化器。Rust 是一个在系统、数据库和网络工程领域的破冰工具。我们将以太坊视为一个高保障的操作系统，需要抵御最大的对手。没有比 Rust 更好的工具包来实现这一点。

如果你是现有或有抱负的 Rust 使用者、权益证明用户、爱好者、专业节点基础设施操作员、MEV 搜索者、以太坊 L1/L2 开发者、数据分析师，或仅仅对贡献感兴趣，请通过电子邮件联系 georgios [at] paradigm [dot] xyz 或加入位于 Reth repo 的 README 中的聊天室。

我们迫不及待地想听听你希望在 Reth 的基础设施和库上贡献和构建的事情。

感谢那些已经为 Reth 的设计、文档和代码作出贡献的人：Matt Seitz、Oliver Nordbjerg、Dan Cline、Dragan Rakita、Roman Krasiuk、joshieDo、Andrew Kirillov、Loren Siebert、0xKitsune、team LambdaClass 和 Brock Elmore。若没有他们对 Rust Ethereum 生态系统（包括 ethers-rs、revm、Foundry，以及现在的 Reth）的不懈贡献，这一切都不可能实现。感谢 Achal Srinivasan 设计 Reth 的视觉效果。

最后，最衷心的感谢所有以太坊核心开发者，让以太坊变得如此伟大；我们很兴奋能够在这条漫长的旅程中与你一起前行。

在 Github 上见。

向 东科、丹尼·瑞安、贾斯廷·德雷克、列夫·利夫涅夫、利亚姆·霍恩、保罗·哈乌纳、罗伯特·米勒、snoopy_mev 和蒂姆·贝伊科表示感谢，他们为本文早期草稿提供了反馈。

免责声明：文中提及的任何投资组合公司仅为示例目的提及，并不代表 Paradigm 所做的所有投资。

• 原文链接： paradigm.xyz/2022/12/ret...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～