注：原文来自Paradigm CTO Georgios Konstantopoulos 发布文章，MarsBit整理编译。
介绍
去年，我们开始构建Reth，这是一个用Rust编写的新以太坊执行节点，具有模块化、对贡献者友好、速度极快的特点。
构建Reth的目标:
为以太坊的稳定性做出贡献，提高客户端多样性。
降低进入门槛，为以太坊实现路线图做出贡献。
为EVM开发者和用户构建一个高性能和包容性的工具生态系统。
Reth由Paradigm资助的8人核心团队以及其他90多名贡献者共同构建。在构建Reth时，我们使用与构建Foundry相同的原则和经验教训，专注于性能和测试。与此同时，我们文化的核心原则之一是使我们的代码库对新开发者具有可访问性和包容性，因此我们非常关注我们的抽象（编程）和文档。
今天，我们很高兴地宣布Reth正式进入 alpha 阶段，版本为 0.1.0，采用 Apache/MIT 许可证。我们邀请节点运营商和用户来运行节点，并使用Reth的crate来构建令人兴奋的以EVM为中心的基础设施。
TL；DR – 目前的alpha版本包含了什么?
•一个新的以太坊执行层，采用Rust编写，使用Apache/MIT许可证。
•最佳性能表现：
•存储：在区块17.4M时，数据库大小小于2TB。
•同步速度：从创世区块到最新区块的数据同步时间在50小时之内。
•鲁棒性：可靠地跟踪提示，而不会在重RPC负载下掉队。
•链上查询：高RPC吞吐量，低延迟。
•使用标准化的EF 维护的测试套件、模糊测试/概要分析最佳实践和 自定义基准基础设施进行深入测试。
•功能完善至上海升级，下一个是坎昆。
•以太坊JSON-RPC支持，包括快速的实时和历史跟踪，使用Geth的debug_*模块(包括JS Tracers)和Parity的trace_*模块。
•用于构建以EVM 为中心的基础设施的新SDK，例如:
•MEV构建者
•P2P Sentries
•索引器
•ERC4337 用户操作内存池
•以及其他令人兴奋的应用。
如果这听起来很有趣，请继续阅读，以了解更多信息。
性能表现
在评估节点时，Reth 在最重要的领域实现了最先进的归档节点性能：
存储：在区块17.4M时，数据库大小小于2TB。
同步速度：从创世区块到最新区块的数据同步时间在50小时之内。
鲁棒性：可靠地跟踪提示，而不会在重RPC负载下掉队。
链上查询：每秒数千请求RPC吞吐量，低延迟。
我们在下面提供了Reth和其他流行节点实现之间的简要比较：
虽然仍处于早期阶段，但Reth已经显示出颇具潜力的性能特征，我们很高兴在未来进一步改进。我们还希望使我们的基准测试方法更加稳健，并可由第三方复制。如果你对我们如何收集这些基准测试以及我们在分析和测试背后的理念感到好奇，请参阅FAQ，或者联系我们做出贡献。
通过运行Reth，你可以提高节点的性能并降低成本，同时还有助于提高客户端多样性。关于设置节点的说明，请点击此处。
Reth也是一个用于构建以EVM为中心的基础设施的新SDK。
Reth是构建EVM基础设施的高质量抽象生态系统。可以将Reth视为一个SDK，节点只是第一个应用程序。
我们为复杂的操作提供高性能和文档化的模块和抽象，如区块构建、模拟交易、构建内存池、索引链、P2P网络、RPC接口等。我们所有的软件包都是在Apache/MIT许可下授权的，每个人都可以免费使用。
你可以通过将以下内容添加到你的Cargo.toml文件中将Reth的各个组件作为库进行导入（将reth-db替换为你喜欢的软件包，点击这里查看完整列表）。
我们计划未来为这些库提供版本发布；目前，我们要求开发者通过基于git的路径在他们的Cargo项目中导入Reth。
开始构建，通过将Reth作为一个库导入，并浏览文档。
Reth的未来
目前的Reth是一个高性能的以太坊归档节点实现和工具包，用于构建以EVM为中心的基础设施。我们很高兴能够继续发布快速、经过良好测试和对贡献者友好的代码，并为以太坊生态系统的长期成功做出贡献。
Reth核心团队将专注于：
发布以太坊路线图，将坎昆和EIP-4844作为我们的首要任务，并为核心开发过程做出贡献。
提高现有功能集的稳定性。
提供关键节点的质量特性，如非存档同步和快照。
我们将继续扩展代码库的文档和测试，以提高稳健性并使集成更容易。我们邀请开发者和节点运营商试用Reth，并让我们知道他们的想法。与Foundry一样，我们仍坚持开发者优先，致力于高标准的紧密反馈循环。我们迫不及待地想要了解，你将使用Reth 构建什么。
Github上见。
作者注：项目是于2022年底开始构建，如果没有优秀的团队与我一起研究 Reth，这一切都不可能实现。与Aleksey Shekhirin、Dan Cline、Dragan Rakita、joshieDo、Matthias Seitz、Oliver Nordbjerg和Roman Krasiuk一起工作是我软件开发生涯中莫大的荣幸，有这样一群优秀的人在我身边，我感到很幸运，希望未来大家能继续一起合作。
常见问题解答
Reth可以投入使用了吗?
Reth目前是未经审核的软件，处于测试期的早期阶段，没有任何保证。我们计划将其过渡到beta版，随后进行更多测试和审核部分代码库，再过渡到“1.0”版。我们很高兴看到第一批测试者分享他们对Reth的反馈。运行一个节点，让我们知道在满足你的构建准备条件方面，Reth还需要什么。
有人在运行节点吗?
已经有一些同步的 Reth 节点公开了。你可以通过直接查询http://45.250.253.77:8545或通过Foundry: cast block-number—rpc-url http://45.250.253.77:8545来尝试我们的方法。该节点目前没有任何速率限制器或防火墙，因此我们只是暂时开放对JSON-RPC的访问，并打算在未来几周内逐步关闭公开的端口8545。
哪些项目已经“使用 Reth 构建”？
以下是一些早期采用者使用Reth作为库的生态系统项目:
Vid201/aa-bundler：一个ERC4337捆绑器，使用Reth的数据库绑定。
sorelllabs /ether -reth：用于Reth的ether-rs中间件，它绕过JSON-RPC，允许使用Reth的数据库绑定在本地HTTP/IPC上进行2-3倍的分叉测试。
以太坊/trin：一个门户网络客户端，使用Reth的IPC绑定。
mouselless -eth/rust -sando：一个MEV机器人，使用Reth的访问列表检查器。
will – smith /reconnaissance和jonasbostoen/ Reth – P2P -showcase：使用Reth的P2P实现的P2P哨兵节点。
kkrt-labs/kakarot-rpc：一个使用Reth的JSON-RPC API的Cairo ZK EVM JSON RPC代理。
trianglesphere/rnode：一个使用 Reth 原始类型的实验性 Optimism 故障证明程序。
MEV交易员使用Reth的PayloadBuilder抽象的私有区块构建器。
Reth支持哪些链?
Reth目前支持基于以太坊的链，如以太坊主网、Goerli、Sepolia、以太坊基金会的测试网等。Reth不支持其他链，如BSC, Polygon或Fantom，但我们有兴趣了解更多。我们计划在不久的将来探索支持OP Stack，请参阅此处了解一些初步工作。如果你有兴趣构建，请联系我们。
提供了哪些同步模式?
Reth目前只提供归档同步。我们计划在不久的将来提供更细粒度的存储和同步选项(如全节点和快照)，你可以在Github上跟踪。我们的最终目标是，允许满足需求所需的最小存储需求运行节点。如果你有反馈或想法，请联系我们。
Reth归档节点的硬件要求是什么?
为了获得最佳性能，我们的硬件建议是:
至少2TB NVMe SSD硬盘。我们预计很快就会超过归档同步的 2TB 阈值，因此我们建议获取额外的磁盘空间。
至少8GB内存：虽然Reth的内存效率很高，但我们没有使用更小的内存盒进行基准测试。
更高的时钟速度的CPU（而不是更高的线程数），因为大部分时间都花在串行执行操作上。
24MBit网络连接。
非NVMe磁盘
同步以太坊节点在磁盘读写方面存在瓶颈。因此，通常建议使用NVMe驱动器运行节点。这些并不总是可用的，因此我们研究了在更便宜的消费级硬件上同步所需的时间。
在我们最近的基准测试中，在GCP(“Persistent SSD”)提供的非NVMe驱动器上，Reth花了大约9天的时间来同步。第三方节点运营商报告称，在双sata RAID-0磁盘设置上同步大约需要4天。
我们很高兴Reth能够降低以太坊节点在消费级硬件上的准入门槛。如果你是一个节点操作员，可以帮助我们在各种硬件和软件配置(例如消费磁盘，ARM设备，利基操作系统)上测试Reth，请联系我们。
使用什么方法进行同步基准测试？
我们在Latitude.sh上使用裸机硬件。具体来说，我们在一个c3.large上同步了一个Erigon和Reth节点。x86机器(Debian, 2TB NVMe SSD, 256GB RAM, 10Gbit带宽，AMD 2.85GHz 24核)，并计算了从创世区块到最新区块的数据的时间。在这两种情况下，都使用了默认节点配置。
在RPC基准测试中使用什么方法?
大型基础设施参与者在高负载下寻求跨各种调用的高RPC性能。这可能会导致云硬件上的资源密集，尤其是在客户需求增长的情况下。
测量RPC性能是微妙的，因为它需要了解每个RPC方法在增加负载下的吞吐量和延迟，同时还要确保发送到节点的请求与实际负载相似。
为解决这一问题，我们开发了Flood，这是一个RPC节点的基准测试工具，它可以生成关于各种RPC调用的错误率、吞吐量和延迟的详细报告。有了这些信息，我们改进了Reth针对每个RPC方法的性能特征。
注意，虽然我们的结果令人鼓舞，但Flood是一个合成基准，可能容易出现测量错误。我们很高兴能够产生更多的基准测试，特别是在跟踪方面，所以如果你有跟踪负载，并且有兴趣对Reth进行基准测试，请联系我们。
为什么节奏这么快?
我们没有实施任何一种“技巧”来使节点又快又小。一些关键因素是：
在历史同步期间最大限度地进行批处理，并围绕每个进程的瓶颈进行优化。
用于高效数据库查询的
使用针对以太坊数据类型的定制编码和基于历史数据的zstd压缩来优化数据库占用空间。
大量使用自定义编写的期货/流/后台作业，使资源一直处于饱和状态。
Revm，一个极快的EVM，它将数据库调用与解释器分离，也用于Foundry和其他高性能基础设施。
Rust，用于在生成的二进制文件中进行谨慎的资源管理和高性能代码。
我们还使用Prometheus/Grafana和结构化日志跟踪来分析节点内部，同时利用perf、flamgraphs和heaptrack等流行的系统工具。最后，我们构建了Flood，一个差分测试和基准测试工具，以确保跨节点实现的RPC响应匹配并提高性能。
如何测试节点并识Bug?
我们采用了多层方法来测试和分析Reth。以下是我们遵循的一些流程：
我们经常在以太坊主网和测试网上重新同步创世区块中的Reth，这是最终的端到端测试。与此同时，我们正在开发一个自动化框架，用于从genesis运行节点，以快速检测正确性或性能回归。
我们每晚在Github Actions上运行Hive测试套件；Hive 是以太坊节点实现的基本测试套件。
我们广泛地记录整个代码库，不允许公开暴露未记录的代码。在一些关键的情况下，比如引擎API，我们会在代码库中记录部分执行层规范。
Bluealloy在每个Revm PR上运行EVM状态测试，以确保其实现保持良好。
我们运行流行的Foundry存储库的分叉测试，以确保Reth周围的生态系统按预期工作。
我们对代码的敏感部分进行模糊测试，以确保覆盖边缘情况。
我们对整个代码库进行了广泛的单元测试，以确保正确性并避免回归。
（注：边缘情况指的是输入或条件接近或超出程序预期的边界值，例如最小值、最大值、空值、边界条件等。）
微信扫一扫 
