Dec 07, 2022 | Georgios Konstantopoulos
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.
With Reth, we want to:
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.
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.
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.
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:
trace_callManyetc.) and opcode tracing (
debug_traceTransaction) at the chain’s tip and historically.
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.
Reth is still a work in progress, which started on September 20th, 2022.
In three months, we have built the following:
We have not yet implemented fully or tested the following:
trace_*so should not be a big lift)
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.
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:
If these are problems you can help us with, reach out.
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:
We also thank the Nethermind and Besu teams for contributing to client diversity, and we hope to find ways to collaborate in the future.
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.
See you on Github.
Acknowledgments: Thanks to Alex Stokes, Danny Ryan, Justin Drake, Lev Livnev, Liam Horne, Paul Hauner, Robert Miller, snoopy_mev, and Tim Beiko for feedback on earlier drafts of this post.
Disclaimer: Any portfolio companies referred to herein are mentioned for illustrative purposes only and are not representative of all investments made by Paradigm.
Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors and is not made on behalf of Paradigm or its affiliates and does not necessarily reflect the opinions of Paradigm, its affiliates or individuals associated with Paradigm. The opinions reflected herein are subject to change without being updated.