introduce
Reth is a modular, contributor-friendly, extremely fastEthereum client built using the Rust language , a new SDK for building EVM-centric infrastructure under the Apache/MIT license. The Reth core team will continue to focus on: releasing the Ethereum roadmap, with Cancun and EIP-4844 being top priorities, and contributing to the core development process; improving the stability of the existing feature set; delivering key node features such as non-archiving Sync and Snapshot, the new Ethereum execution node written in Rust, is modular, contributor-friendly, and blazingly fast.
Goals for building Reth:
Contribute to the stability of Ethereum and increase client diversity.
Lower the barrier to entry and contribute to the Ethereum implementation roadmap.
Build a high-performance and inclusive tool ecosystem for EVM developers and users.
Reth is built by a core team of 8 people funded by Paradigm, as well as over 90 other contributors. When building Reth, we used the same principles and lessons learned as we built Foundry, focusing on performance and testing. At the same time, one of the core tenets of our culture is to make our codebase accessible and inclusive to new developers, so we pay a lot of attention to our abstractions (programming) and documentation.
Today, we are pleased to announce that Reth has officially entered alpha stage, version 0.1.0, under the Apache/MIT license. We invite node operators and users to run nodes and use Reth’s crates to build exciting EVM-centric infrastructure.
TL;DR - What does the current alpha version contain?
•A new Ethereum execution layer, written in Rust and licensed under the Apache/MIT license.
•Best Performance:
•Storage: At block 17.4M, the database size is less than 2TB.
•Synchronization speed: The data synchronization time from the genesis block to the latest block is within 50 hours.
• Robustness: Track prompts reliably without falling behind under heavy RPC loads.
•On-chain query: high RPC throughput, low latency.
•In-depth testing using standardized EF-maintained test suites, fuzzing/profiling best practices, and custom benchmark infrastructure.
•The function has been improved to Shanghai, and Cancun is next.
• Ethereum JSON-RPC support, including fast real-time and historical tracing, using Geth’s debug_* modules (including JS Tracers) and Parity’s trace_* modules.
•New SDK for building EVM-centric infrastructure, for example:
•MEV Builder
•P2P Sentries
•Indexer
•ERC4337 user-operated memory pool
•And other exciting applications.
If this sounds interesting, read on to learn more.
Performance
When evaluating nodes, Reth achieved state-of-the-art archive node performance in the areas that matter most:
Storage: At 17.4M blocks, the database size is less than 2TB.
Synchronization speed: The data synchronization time from the genesis block to the latest block is within 50 hours.
Robustness: Track prompts reliably without falling behind under heavy RPC loads.
On-chain queries: Thousands of requests per second RPC throughput, low latency.
We provide a brief comparison between Reth and other popular node implementations below:
Although still in its early stages, Reth is already showing promising performance characteristics and we are excited to further improve it in the future. We also hope to make our benchmarking methodology more robust and replicable by third parties. If you're curious about how we collect these benchmarks and our philosophy behind analysis and testing, please see the FAQ, or contact us to contribute.
By running Reth, you can improve node performance and reduce costs, while also helping to increase client diversity. Instructions for setting up a node canclick here.
Reth is also a new SDK for building EVM-centric infrastructure.
Reth is an ecosystem of high-quality abstractions for building EVM infrastructure. Think of Reth as an SDK, node is just the first application.
We provide high-performance and documented modules and abstractions for complex operations, such as block building, simulated transactions, building memory pools, index chains, P2P networks, RPC interfaces, etc. All our packages are licensed under the Apache/MIT license and are free for everyone to use.
You can import the various components of Reth as libraries by adding the following to your Cargo.toml file (replace reth-db with your preferred package,Click here to see the full list).
We plan to provide version releases for these libraries in the future; currently, we require developers to import Reth in their Cargo projects via a git-based path.
Start building by importing Reth as a library and browsing the documentation.
The future of Reth
The current Reth is a high-performance Ethereum archive node implementation and toolkit for building EVM-centric infrastructure. We are excited to continue releasing fast, well-tested, and contributor-friendly code and contribute to the long-term success of the Ethereum ecosystem.
The Reth core team will focus on:
Publish the Ethereum roadmap with Cancun and EIP-4844 as our top priorities and contribute to the core development process.
Improve the stability of existing feature sets.
Provides critical node quality features such as non-archive synchronization and snapshots.
We will continue to expand the documentation and testing of the codebase to improve robustness and make integration easier. We invite developers and node operators to try out Reth and let us know what they think. Like Foundry, we still put developers first and are committed to high standards and a tight feedback loop. We can’t wait to hear what you’ll build with Reth.
See you on Github.
Author's Note: The project is starting to be built at the end of 2022, and none of this would be possible without the excellent team working with me on Reth. Working with Aleksey Shekhirin, Dan Cline, Dragan Rakita, joshieDo, Matthias Seitz, Oliver Nordbjerg and Roman Krasiuk has been a great honor in my software development career. I feel very lucky to have such a great group of people around me and I wish you all the best in the future. can continue to work together.
Frequently Asked Questions
Is Reth ready for use?
Reth is currently unreviewed software, in the early stages of a beta period, and comes with no guarantees. We plan to transition it to a beta version, followed by more testing and review of parts of the codebase, before transitioning to "1.0" version. We’re excited to see the first testers share their feedback on Reth. Run a node and let us know what else Reth needs in terms of your build readiness requirements.
Is anyone running a node?
There are already some synchronized Reth nodes exposed. You can try our method by directly querying http://45.250.253.77:8545 or through Foundry: cast block-number—rpc-url http://45.250.253.77:8545. The node does not currently have any rate limiters or firewalls, so we are only temporarily opening access to JSON-RPC and intend to gradually close the exposed port 8545 in the coming weeks.
Which projects are already "built with Reth"?
Here are some ecosystem projects with early adopters using Reth as a library:
Vid201/aa-bundler: An ERC4337 bundler using Reth's database binding.
sorelllabs/ether-reth: An ether-rs middleware for Reth that bypasses JSON-RPC and allows 2-3x forked testing over local HTTP/IPC using Reth's database bindings.
ethereum/trin: A portal network client using Reth's IPC bindings.
mousellless -eth/rust -sando: A MEV robot using Reth's access list checker.
will-smith/reconnaissance and jonasbostoen/ Reth-P2P-showcase: P2P sentinel node using Reth's P2P implementation.
kkrt-labs/kakarot-rpc: A Cairo ZK EVM JSON RPC proxy using Reth's JSON-RPC API.
trianglesphere/rnode: An experimental Optimism bug-proof program using Reth primitive types.
MEV traders use Reth’s PayloadBuilder abstraction for a private block builder.
What chains does Reth support?
Reth currently supports Ethereum-based chains, such as the Ethereum mainnet, Goerli, Sepolia, Ethereum Foundation’s testnet, etc. Reth does not support other chains such as BSC, Polygon or Fantom, but we are interested in learning more. We plan to explore supporting OP Stack in the near future, Please see here for some preliminary work. If you are interested in building, please contact us.
What synchronization modes are provided?
Reth currently only provides archive synchronization. We plan to provide more fine-grained storage and synchronization options (such as full nodes and snapshots) in the near future, which you can track on Github. Our ultimate goal is to allow nodes to run with the minimum storage requirements necessary to meet demand. If you have feedback or ideas, please contact us.
What are the hardware requirements for Reth archive nodes?
For optimal performance, our hardware recommendations are:
At least 2TB NVMe SSD hard drive. We expect to exceed the 2TB threshold for archive synchronization soon, so we recommend acquiring additional disk space.
At least 8GB of RAM: While the Reth is very memory efficient, we didn't benchmark it with a smaller memory box.
A higher clock speed CPU (rather than a higher thread count) since most of the time is spent executing operations serially.
24MBit network connection.
Non-NVMe disk
Synchronizing Ethereum nodes has a bottleneck in disk reads and writes. Therefore, it is generally recommended to use NVMe drives to run nodes. These are not always available, so we looked at the time it would take to sync on cheaper consumer-grade hardware.
In our most recent benchmark, Reth took about 9 days to sync on a non-NVMe drive provided by GCP ("Persistent SSD"). Third-party node operators report that synchronization takes approximately 4 days on a dual SATA RAID-0 disk setup.
We are excited for Reth to lower the barrier to entry for Ethereum nodes on consumer-grade hardware. If you are a node operator who can help us test Reth on various hardware and software configurations (e.g. consumer disks, ARM devices, niche operating systems), please contact us.
What method is used for synchronous benchmarking?
We use bare metal hardware on Latitude.sh. Specifically, we synchronized an Erigon and Reth node on a c3.large. x86 machine (Debian, 2TB NVMe SSD, 256GB RAM, 10Gbit bandwidth, AMD 2.85GHz 24 cores), and calculated the time from the genesis block to the latest block of data. In both cases, the default node configuration is used.
What methods are used in RPC benchmarks?
Large infrastructure players are looking for high RPC performance across various calls under high load. This can lead to resource intensity on cloud hardware, especially as customer demand grows.
Measuring RPC performance is delicate as it requires understanding the throughput and latency of each RPC method under increased load, while also ensuring that requests sent to the node are similar to the actual load.
To address this issue, we developed Flood, an RPC node benchmarking tool that generates detailed reports on the error rate, throughput, and latency of various RPC calls. Armed with this information, we improved Reth's performance characteristics for each RPC method.
Note that while our results are encouraging, Flood is a synthetic benchmark and may be prone to measurement errors. We're excited to produce more benchmarks, especially on the tracing side, so if you have a tracing workload and are interested in benchmarking Reth, please get in touch.
Why is the pace so fast?
We didn't implement any kind of "trick" to make nodes fast and small. Some key factors are:
Maximize batching during history synchronization and optimize around per-process bottlenecks.
for efficient database queries
Optimize database footprint using custom encoding for Ethereum data types and zstd compression based on historical data.
Extensive use of custom-written futures/streams/background jobs that keep resources saturated.
Revm, an extremely fast EVM that decouples database calls from the interpreter, is also used in Foundry and other high-performance infrastructure.
Rust, for careful resource management and high-performance code in generated binaries.
We also use Prometheus/Grafana and structured log tracing to analyze node internals, while leveraging popular system tools such as perf, flamgraphs, and heaptrack. Finally, we built Flood, a differential testing and benchmarking tool to ensure that RPC responses across node implementations match and improve performance.
How to test nodes and identify bugs?
We took a multi-layered approach to testing and analyzing Reth. Here are some of the processes we follow:
We frequently resync Reth in the genesis block on Ethereum mainnet and testnet, which is the ultimate end-to-end test. In parallel, we are developing an automated framework for running nodes from genesis to quickly detect correctness or performance regressions.
We run the Hive test suite nightly on Github Actions; Hive is the basic test suite implemented by Ethereum nodes.
We document the entire codebase extensively and do not allow public exposure of undocumented code. In some key cases, such as the engine API, we will record part of the execution layer specification in the code base.
Bluealloy runs EVM status tests on every Revm PR to ensure that its implementation remains healthy.
We run fork tests of the popular Foundry repository to ensure the ecosystem around Reth works as expected.
We fuzz test sensitive parts of the code to ensure edge cases are covered.
We perform extensive unit testing across the entire codebase to ensure correctness and avoid regressions.