Introduction

Last year, we set out to build Reth, a new Ethereum execution node written in Rust that is modular, contributor-friendly and blazing-fast.

Our goals behind Reth are to:

• Contribute to Ethereum’s stability and improve client diversity.
• Lower the barrier to entry for contributing to Ethereum’s ambitious roadmap.
• Build a performant and inclusive ecosystem of tools for EVM developers and users.

Reth is built by a Paradigm-funded core team of 8, along with over 90 other contributors. In building Reth, we focused on performance and testing, using the same principles and lessons from building Foundry. At the same time, one of the core tenets of our culture is making our codebases accessible and inclusive to new developers, so we paid a lot of attention to our abstractions and documentation.

Today, we’re excited to announce that Reth is entering its alpha with version 0.1.0 under the permissive Apache/MIT license. We are inviting node operators and users to run nodes and use Reth’s crates to build exciting EVM-centric infrastructure.

TL;DR – What is included in today’s alpha release?

• A new Ethereum Execution Layer, in Rust, using the Apache/MIT license.
  • Best in class performance:
    • Storage: <2TB database size at block 17.4M.
    • Syncing Speed: Bootstrapping the chain from genesis to block 17.4M in 50 hours.
    • Robustness: Reliably tracks the tip without falling behind under heavy RPC load.
    • Querying the chain: State of the art RPC throughput and latency.
  • Tested in-depth using standardized EF-maintained test suites, fuzz-testing/profiling best practices, and custom benchmarking infrastructure.
  • Feature-complete up to Shanghai, with Cancun up next.
  • Ethereum JSON-RPC support, including blazing-fast live & historical tracing, using Geth’s debug_* module (incl. JS Tracers) and Parity’s trace_* module.
• A new SDK for building EVM-centric infrastructure such as:
  • MEV Builders
  • P2P Sentries
  • Indexers
  • ERC4337 UserOp mempools
  • ..and other exciting applications.

If this sounds interesting, read on to learn more.

Performance

Reth achieves state of the art archive node performance on the most important areas when evaluating a node:

• Storage: <2TB database size at block 17.4M.
• Syncing Speed: Bootstrapping the chain from genesis to block 17.4M in 50 hours.
• Robustness: Reliably tracks the tip without falling behind under heavy RPC load.
• Querying the chain: State of the art RPC throughput and latency.

We provide a brief comparison between Reth and other popular node implementations below:

While these are still early days, Reth already shows promising performance characteristics, which we’re excited to further improve in the future. We would also like to make our benchmarking methodology more robust and reproducible by third parties. If you are curious about how we collected these benchmarks and our philosophy behind profiling and testing, see the FAQ, or reach out to contribute.

By running Reth, you can improve your nodes’ performance and reduce your cost while also contributing to client diversity. Read The Book for instructions on setting a node up.

What is included in this release?

Today’s release includes an archive node, which enables efficiently querying historical Ethereum data. This is a very important component for Ethereum ecosystem stakeholders such as searchers, block explorers, indexers, and RPC providers.

Our thesis is that Reth will create quantitative and qualitative improvements to crypto infrastructure’s robustness and performance, while also providing hardware and cloud cost savings.

Reth can sync any Ethereum-like network (Mainnet, Sepolia, Goerli etc.), up to Shanghai, and follows the Ethereum JSON-RPC spec. Importantly, we provide new performant implementations of the debug_* (including Geth-style Javascript tracers) and trace_* JSON-RPC namespaces (featuring “top of next block” simulations, instead of “end of current block”, using the pending block tag, a common feature requested by searchers during trace_call and trace_callMany). You can learn more about JSON-RPC support in the Reth Book.

Reth is also a new SDK for building EVM-centric infrastructure.

Reth is an ecosystem of high-quality abstractions for building EVM infrastructure. One can think of Reth as an SDK, with the node being just the first application.

We provide performant & documented modules and abstractions for complex operations like block building, simulating transactions, building mempools, indexing the chain, P2P networking, RPC interfaces, and more. All our packages are licensed under the Apache/MIT license, for free, permissive use by everyone.

You can import Reth’s various components as a library by adding the following to your Cargo.toml (replace reth-db with your favorite package, see here for a complete list):

We intend to provide versioned releases for the libraries in the future; for now, we ask developers to import Reth in their Cargo projects via git-based paths.

Start building by importing Reth as a library and browsing the docs!

The future of Reth

Reth today is a performant Ethereum archive node implementation and toolkit for building EVM-centric infrastructure. We are excited to continue shipping blazing-fast, well-tested and contributor-friendly code, and contribute to the Ethereum ecosystem’s long-term success.

The core Reth team is going to be focusing on:

1. Shipping the Ethereum roadmap, with Cancun & EIP-4844 as our top priority, and contributing to the Core Development process.
2. Improving stability of the existing feature set.
3. Shipping key node quality of life features like non-archive sync and snapshots.

We will continue expanding documentation and testing of the codebase, to improve robustness and make integrations easier. We invite developers and node operators to try out Reth and let us know what they think. Like with Foundry, our culture remains developer-first, devoted to tight feedback loops with a high bar. We cannot wait to see what you will build with Reth.

If all of this is exciting, please join the Telegram group in the repository’s README, or reach out to [email protected].

See you on Github.

Author’s note: None of this would have been possible without the beyond excellent team working on Reth with me, since we started this project late 2022. Working with Aleksey Shekhirin, Dan Cline, Dragan Rakita, joshieDo, Matthias Seitz, Oliver Nordbjerg and Roman Krasiuk has been one of the greatest privileges of my software engineering career and I feel lucky to have such people around me, hopefully for a long time in the future.

Reth FAQ

Is Reth production-ready?

Reth is currently unaudited software, early in its testing lifecycle, and it’s provided as-is without warranty. We intend to transition it to beta and then “1.0” as more testing happens and parts of the codebase get audited. We are excited for the first wave of testers to share their feedback around Reth’s production-readiness. Run a node, and let us know what is needed for Reth to meet the production-readiness bar for you!

Are people running nodes?

There already some synced Reth nodes in public! You can try out ours by querying https://45.250.253.77:8545 directly, or via Foundry: cast block-number --rpc-url https://45.250.253.77:8545 . The node is not behind any rate limiter or firewall at the moment, so we are only temporarily opening up access to JSON-RPC and intend to gradually close off the publicly exposed port 8545 in the coming weeks.

What projects are “Built with Reth” already?

Here are some ecosystem projects from early adopters, using Reth as a library:

• Vid201/aa-bundler: An ERC4337 bundler, using Reth’s Database bindings.
• SorellaLabs/ethers-reth: A ether-rs middleware for reth that bypasses JSON-RPC allowing for 2-3x faster forking tests over local HTTP/IPC, using Reth’s Database bindings.
• ethereum/trin: A Portal Network client, using Reth’s IPC bindings.
• mouseless-eth/rusty-sando: An MEV bot, using Reth’s Access List inspectors.
• Will-Smith11/reconnaissance and jonasbostoen/reth-p2p-showcase: P2P sentry nodes 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 fault proof program using Reth’s primitive types.
• Private Block Builders by MEV traders using Reth’s PayloadBuilder abstraction.

What chains does Reth support?

Reth currently supports Ethereum-based chains such as Ethereum mainnet, Goerli, Sepolia, the Ethereum Foundation’s testnets etc. Reth does not support other chains like BSC, Polygon or Fantom, but we are interested in learning more about it. We intend to explore supporting OP Stack in the near future, see here for some preliminary work. If you are interested in building that out, please reach out.

What sync modes are provided?

Reth currently only provides archive sync. We intend to provide more granular storage and syncing options in the near future (like full node & snapshots), which you can track on Github. Our ultimate goal is to allow running a node with the minimal storage requirements needed for your needs. Please reach out if you have feedback or ideas you think we should incorporate here.

What are the hardware requirements for a Reth archive node?

For best performance, our hardware recommendations are:

• At least 2TB NVMe SSD drive. We expect the 2TB threshold for archive sync to be crossed soon, so we recommend getting extra disk space.
• At least 8GB of RAM: While Reth is memory efficient, we did not benchmark with smaller memory boxes.
• Higher clockspeed CPUs (over higher threads) as most of the time is spent on serial execution operations.
• 24MBit network connection

What about non-NVMe disks?

Syncing an Ethereum node is bottlenecked on disk reads and writes. As a result, it’s usually recommended to run a node using an NVMe drive. These are not always available, so we explored the time to sync on cheaper, consumer hardware.

On non-NVMe drives provided by GCP (“Persistent SSD”) Reth took approximately 9 days to sync in our most recent benchmark. Third-party node operators have reported ~4 days to sync on a dual-SATA RAID-0 disk setup.

We are excited for Reth to lower the barrier to entry Ethereum nodes on consumer hardware. If you are a node operator who can help us test Reth on a variety of hardware & software configurations (e.g. consumer disks, ARM devices, niche OSes) please reach out.

What methodology did you use for your syncing benchmarks?

We used bare metal hardware on Latitude.sh. Specifically, we synced an Erigon and Reth node on a a c3.large.x86 machine (Debian, 2TB NVMe SSD, 256GB RAM, 10Gbit bandwidth, AMD 2.85GHz 24 cores), and measured the time they took from genesis to following the chain’s tip. In both cases, the default node configuration was used.

What methodology did you use for your RPC benchmarks?

Large infrastructure players seek high RPC performance across a variety of calls, under heavy load. This can get resource intensive on cloud hardware, especially as customer needs grow.

Measuring RPC performance is nuanced as it requires understanding throughput & latency of each RPC method under increasing loads, while also making sure the requests being sent to the node resemble real load.

To address that, we developed Flood, a benchmarking tool for RPC nodes which produces detailed reports about the error rate, throughput and latency of various RPC calls. Equipped with that information, we improved Reth’s performance characteristic for each RPC method.

We caveat that while our results are encouraging, Flood is a synthetic benchmark and might be prone to measurement mistakes. We are excited to produce more benchmarks, especially around tracing, so please reach out if you have tracing loads you would be interested in benchmarking Reth with.

How is this so fast and compact?

There is not one “trick” which we implemented that made the node fast and small. Some of the key factors are:

• Erigon-style staged sync to maximize batch processing during historical sync and optimizing around the bottlenecks of each process.
• Flat database format for efficient DB queries.
• Optimized database footprint using a bespoke encoding for Ethereum datatypes and zstd compression trained on historical data.
• Heavy usage of custom-written futures/streams/background jobs for saturating resources at all times.
• Revm, a blazing-fast EVM which separates DB calls from the interpreter, also used in Foundry and other performant infrastructure.
• Rust, for careful resource management and performant code in the resulting binary.

We also profile node internals using Prometheus/Grafana & structured log tracing, while utilizing popular systems tools like perf, flamegraphs and heaptrack. Finally, we built Flood, a differential testing & benchmarking tool to ensure RPC responses across node implementations match & improve performance.

How did you test the node and identify bugs?

We took a multi-layered approach to testing & profiling Reth. Here are some of the processes we follow:

• We frequently re-sync Reth from genesis on Etheruem mainnet & testnets, which acts as the ultimate end-to-end test. In parallel, we are working on an automated framework for running nodes from genesis to quickly detect correctness or performance regressions.
• We run the Hive testing suite nightly on Github Actions; Hive is the table-stakes testing suite for any Ethereum node implementation.
• We document the whole codebase extensively, disallowing publicly exposed code that is undocumented. In some critical cases like the Engine API, we go as far as document parts of the Execution Layer specs in the codebase.
• Bluealloy runs the EVM state tests on every Revm PR to ensure their implementation remains sound.
• We run the forking tests of popular Foundry repositories, to ensure the ecosystem around Reth works as expected.
• We fuzz-test sensitive parts of the code, to ensure edge cases are covered.
• We extensively unit test the entire codebase, to ensure correctness and avoid regressions.