Jun 20, 2023 | Georgios Konstantopoulos
Our goals behind Reth are to:
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?
debug_*module (incl. JS Tracers) and Parity’s
If this sounds interesting, read on to learn more.
Reth achieves state of the art archive node performance on the most important areas when evaluating a node:
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.
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
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_callMany). You can learn more about JSON-RPC support in the Reth Book.
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
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!
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:
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.
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 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!
There already some synced Reth nodes in public! You can try out ours by querying http://126.96.36.199:8545 directly, or via Foundry:
cast block-number --rpc-url http://188.8.131.52: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.
Here are some ecosystem projects from early adopters, using Reth as a library:
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.
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.
For best performance, our hardware recommendations are:
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.
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.
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.
There is not one “trick” which we implemented that made the node fast and small. Some of the key factors are:
zstdcompression trained on historical data.
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.
We took a multi-layered approach to testing & profiling Reth. Here are some of the processes we follow:
Acknowledgments: Thanks to Matt Huang, Dan Robinson, Dave White, Storm Slivkoff, Tim Beiko, Danny Ryan, and Mike Neuder for reviews on earlier drafts of this post. Thanks to the many early node testers who have given us invaluable feedback towards improving Reth so far. Thanks to Achal Srinivasan for the graphics.
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.