Source

by Georgios Konstantopoulos

Contents

We’re excited to announce Reth, a free, open-source Ethereum execution layer client built by Paradigm. In this post, we’ll discuss why we are making Reth and what to expect from us in the future.

What is Reth?

Reth (short for Rust Ethereum, pronunciation) is a new Ethereum full-node implementation focused on being user-friendly, modular, fast, and efficient. Reth is an execution client compatible with all Ethereum consensus client implementations that support the Engine API. As a full Ethereum node, Reth will allow users to sync the complete Ethereum blockchain from genesis and interact with it (and its historical state, if in archive mode) once synced.

We are building Reth to accommodate a broad user base, including stakers, hobbyists, RPC node operators, bridges, MEV searchers, and even L2s (e.g., Optimism/Arbitrum) or other Ethereum-adjacent projects (e.g., Polygon, BSC, Avalanche, Fantom etc.). These users often have diverse requirements (e.g., hobbyists and stakers want nodes that work on cheap hardware, while RPC node operators have access to expensive disks and cloud snapshots). Reth does not attempt to solve all requirements at once. Instead, we are committed to creating a configurable node that allows users to explore the tradeoff space based on their needs.

Reth is still a work in progress and subject to frequent changes. The code has yet to be audited and should not be used in production. Nevertheless, we are open-sourcing and sharing our vision today in the interest of transparency and values alignment with Ethereum.

The code is available for free on Github under the permissive Apache/MIT license for anyone to use without any strings attached. We encourage the community to fork it, contribute with docs, issues, pull requests, questions, or even try to break it. We cannot wait to see what you come up with!

With that said, let’s dive in.

Why is Paradigm building a new Rust Ethereum client?

At Paradigm, we’re always looking to push the frontier. With ethers-rs, Foundry and revm, we built a mature stack of tools to manipulate the EVM. So we thought, “What’s next?”. The answer was Reth.

With Reth, we want to:

Build a performant node for power users

We are power users of the Ethereum stack and work with power users all the time. So we wanted a node built for performance but also expert tinkering.

Reth aims to provide best-in-class performance across every vertical (CPU/Memory/Bandwidth/Disk space) or provide configurable profiles allowing users to explore the tradeoffs between each mode (disk space vs. latency/throughput).

We are building Reth so each component can be used as a library in people’s tech stacks. For example, an indexing company could use blazing-fast database bindings to provide better performance for their table re-indexing. Or an ERC4337-bundler could use the EVM and database bindings to provide simulation services to a wallet’s users.

With Reth, we hope that every component of the node stack will be unbundled and re-bundled many times over, allowing power users to explore the efficient frontier of the features they need to do what they’re best at. We also hope that the design and code or FFI bindings to it (please reach out if you want to build bindings from any language to Rust) from the best components will be upstreamed to other implementations.

Contribute to Ethereum’s stability by improving client diversity

The Ethereum protocol benefits from client diversity when no client has >66% dominance. This contributes to cross-client testing of the correctness of implementations and decentralized development of the Ethereum protocol. It also avoids scenarios such as finalizing a block in the existence of a software bug.

With Reth, we hope to grow the pie of clients in the ecosystem to contribute to the network’s health while keeping our consensus-critical adoption in check.

Give back to Ethereum by contributing to the roadmap

The Ethereum protocol and the Ethereum node codebases have evolved significantly over the years and are still developing. Changes like EIP1559, The Merge, and EIP4844 have highlighted that innovation on the node level must happen iteratively, with testing, benchmarking, and documentation expected at the highest bar.

In addition, the community expects Core Developers to maintain the network and keep it healthy. They also expect Core Developers to ship innovations that come from research directions, in tight timelines, with sometimes unclear scope or edge cases. We want the Ethereum protocol to keep innovating, and we want Ethereum nodes to remain robust, and we acknowledge that can become a tension.

With Reth, we are going to be in the trenches building alongside everyone, and hope we’ll be able to alleviate some of that pressure on Core Developers. We also hope to push the frontier with new research, code, and architectures, and contribute to the upcoming essential milestones of the Ethereum roadmap.

Why is Reth a new codebase and not contributing to existing ones?

As open-source developers, we looked at every client implementation in the market and considered holistically whether to contribute to or fork an existing one. Unfortunately, we could not find something that satisfied all our requirements out of the box or that could be made to fulfill them within reasonable timeframes.

So we decided to build Reth from scratch with the following criteria:

• Performance: We want Reth to provide the best-in-class performance. To achieve this, we decided to use Rust as our programming language and the Staged Sync node Architecture pioneered by the Erigon team.
• Modularity: We want to build Reth with small, well-abstracted, well-tested, and benchmarked packages. This allows contributors to use Reth packages as libraries and makes it easy to contribute. That way, devs do not need to worry about the entire node and can contribute to small easy-to-onboard packages in hours or days, not weeks or months.
• Battle-Tested Tech Stack: We want Reth to use our battle-tested & optimized tech stack from Foundry, including ethers-rs and revm.
• Stability: We want Reth to be built on robust foundations, and that starts from the language & compiler. We only use stable Rust with stable features and well-maintained crates. We also design our abstractions so that if any crate is suddenly unmaintained and we wouldn’t want to maintain it ourselves, we could switch to a new one without rearchitecting the entire node.
• Archive Node & Tracing Support: In addition to supporting Ethereum’s post-merge checkpoint syncs, we recognize the industry’s reliance on high-assurance archive nodes and performant tracing for infrastructure peripheral to core node operations. We want Reth to provide best-in-class support for historical node access and high throughput / low latency call (trace_call/trace_callMany etc.) and opcode tracing (debug_traceTransaction) at the chain’s tip and historically.
• Licensing: We want Reth to have a permissive license so third parties can use its performant and modularized components without being bound by our project’s license. The Apache/MIT license was an essential requirement for that.

If a new architecture or technological stack outperforms the state-of-the-art in the future, we are open-minded to making changes. We’d like to encourage the community to come to us with ideas they’d like to see in Reth. After all, we’re tinkerers, and this is software built for tinkering.

Is this ready to use?

Reth is still a work in progress, which started on September 20th, 2022.

In three months, we have built the following:

1. Generic headers & block downloaders
2. Generic database and codec abstractions
3. A generic mempool
4. A new p2p stack
5. A blazing-fast EVM executor
6. The “core” syncing stages (headers/bodies/senders/execution)
7. The foundations for fuzzing and benchmarking every package

We have not yet implemented fully or tested the following:

1. PoW and PoS consensus verification
2. Other Erigon-style stages (intermediate hashes and other db indexes)
3. Certain verification checks during execution (or statetests)
4. Full JSON-RPC support (we have already implemented most RPCs in Anvil including trace_* so should not be a big lift)
5. Wiring up each component in the stages loop in a CLI to perform a full sync
6. Ensuring the P2P network works properly during syncing at the tip or while gossiping mempool transactions.
7. Full Ethereum test suite compliance (incl. Hive support, using/improving retesteth-like software & upstreaming of our specification finds into execution-specs)

We expect to have full sync from genesis implemented sometime in early Q1 2023. In the meantime, we’re working on ensuring every repository crate is well-documented, abstracted, and tested — see here for the project layout.

What is the roadmap after you get to full sync?

In developing the node, we learned a lot about how the Ethereum protocol works and how nodes should be built. To facilitate knowledge transfer and to make it easier for other people to learn about nodes, we will ship the Reth Book, an educational resource on onboarding as an Ethereum node developer.

We are also excited to experiment, starting with investigating the Disk I/O problem under random reads and writes. Disk I/O is effectively the least common denominator in every conversation about performance, and solving it would unlock both performance improvements and cost savings for the entire spectrum of node operators.

We are still early in our exploration there, but here are some questions we want to answer for people interested in the research:

1. Can we pre-fetch data so that when we query the memmapped database, we can cache other values “for free” instead of making a new DB query?
2. Can we statically analyze a block to predict all the touched storage slots without execution? E.g., pre-warm all Uniswap-related storage slots? Should we run a historical analysis to understand what the workload looks like?
3. Can we pipeline and batch EVM operations? For example, can we detect SLOAD/SSTORE calls across multiple transactions in a “batch write” and “batch read” process and save them on DB queries? Can we make an expensive opcode execute in the background until their result is needed?
4. Can we further optimize the EVM by detecting N-sequences of opcodes and performing “block” opcode execution instead of one by one (EVMone already has made strides there)?

If these are problems you can help us with, reach out.

Acknowledgments

In developing the node, we investigated other nodes’ design decisions to understand what is done well, what is not, and where we can improve the status quo.

A big shoutout to the teams below:

• Geth: We would like to express our heartfelt gratitude to the go-ethereum team for their outstanding contributions to Ethereum over the years. Their tireless efforts and dedication have helped to shape the Ethereum ecosystem and make it the vibrant and innovative community it is today. Thank you for your hard work and commitment to the project.
• Erigon (fka Turbo-Geth): Erigon pioneered the “Staged Sync” architecture that Reth is using, as well as introduced MDBX as the database of choice. We thank Erigon for pushing state-of-the-art research on the performance limits of Ethereum nodes.
• Akula: Reth uses forks of the Apache versions of Akula’s MDBX Bindings, FastRLP and ECIES. Given that these packages were already released under the Apache License and they implement standardized protocols without much room for improvement, we decided not to re-implement them. We thank the Akula team for their contributions to the Rust Ethereum ecosystem and for publishing these packages.

We also thank the Nethermind and Besu teams for contributing to client diversity, and we hope to find ways to collaborate in the future.

Conclusion

Paradigm is building Reth, a Rust Ethereum Execution Layer. Reth is a brand-new full-node implementation of the Ethereum protocol, with an Apache/MIT license, focused on contributor friendliness, modularity, and performance.

We are also excited about our codebases as an incubator for new Rust developers. Rust is a breakthrough tool for systems, databases, and network engineering. We think of Ethereum as a high-assurance operating system that needs to be resilient against the biggest adversaries. There is no better toolkit than Rust to achieve that.

If you’re an existing or aspiring Rustacean, staker, hobbyist, professional node infrastructure operator, MEV Searcher, Ethereum L1/L2 developer, data analyst, or are simply excited about contribution, please reach out to georgios [at] paradigm [dot] xyz over email or join the chatroom found in the Reth repo’s README.

We can’t wait to hear about what you’re excited to contribute and build on top of Reth’s infrastructure and libraries.

Thanks to the people who have already contributed to Reth’s design, documentation and code: Matt Seitz, Oliver Nordbjerg, Dan Cline, Dragan Rakita, Roman Krasiuk, joshieDo, Andrew Kirillov, Loren Siebert, 0xKitsune, team LambdaClass, and Brock Elmore. None of this would have been possible without their tireless contributions to the Rust Ethereum ecosystem of ethers-rs, revm, Foundry, and now Reth. Thanks to Achal Srinivasan for designing Reth’s visuals.

Finally, the biggest thank you goes to all Ethereum Core Developers for making Ethereum great; we are excited to join you on this long journey.