We are excited to announce that after almost 2 years of development and a successful audit by Sigma Prime, we are finally releasing Reth 1.0, the first “prod-ready” release of our blazing-fast Ethereum execution client.

Reth 1.0 focuses on delivering a stable Ethereum mainnet node on top of continuing our mission towards breaking through the gigagas per second barrier and delivering an extensible and contributor-friendly node (over 300!).

With this release, we invite all industry players to run Reth in production and get in touch with our team about becoming an early partner so we can help you succeed with priority support and custom features. Specifically:

• Professional operators can run Reth in their Ethereum mainnet production infrastructure to reduce their costs and improve their services’ performance. Get started at the Reth book!
• Stakers can switch their stake over to Reth and support Ethereum’s client diversity by following the instructions at the Ethereum Foundation’s staking launchpad.

If the above sounds exciting, read on to learn more!

Reth is ready for production.

Reth 1.0’s performance characteristic and storage footprint is as good as the beta versions as of June 2024 – about 50 hours to sync to the tip from genesis, ~2.25TB archive node storage, and great RPC throughput & latency in transactions, logs and tracing benchmarks. All of these numbers are state of the art and will continue getting better.

As before, the dominant factor for performance across hardware is the hard drive, so we recommend making sure to run Ethereum nodes on a great SSD. If you’re running on AWS or other cloud storage options, ensure you have >16K IOPS. We use Latitude’s bare metal servers for our benchmarks because of their great NVMe SSDs.

We think the above is reason enough to try out Reth. But performance is not what we want to focus on today. What we're most excited for Reth 1.0 is its stability compared to earlier versions.

With the observed stability and steps taken to secure Reth 1.0, we’re comfortable recommending Reth for usage in production, including for Ethereum mainnet staking (see the Ethereum Foundation's launchpad and large RPC node operations.

How stable is Reth 1.0?

We put extra effort into providing an operator experience which would minimize manual troubleshooting and unpredictability, based on feedback from tons of individual users, professional node operators and companies. Here are the areas we focused on:

• Fast Block Sealing at the Tip: We've improved the block sealing flow in response to Engine API messages to ensure Reth is an attractive option for keeping up with the chain’s tip. This enhancement addresses past issues where blocks were sometimes sealed late, affecting stakers and RPC providers with missed blocks and reduced attestation performance.
• Zero Crashes: Since releasing reth 0.2.0-beta.6 in April 2024, there have been no crash reports, a requirement for any high uptime deployment of Reth. This is a significant improvement over previous versions that occasionally experienced crashes in reorg-related edge cases.
• Efficient Resource Usage: We've successfully addressed memory leaks in critical components such as the network and the mempool, and optimized Reth’s resource utilization across the board. This allows Reth to run with stable and predictable resources on some of the most consumer-friendly hardware, while still being able to utilize high-end hardware like Latitude’s bare metal devices.
• No performance regressions: With our tooling improving, we’re able to confidently ship releases which consistently improve performance from previous versions. Stability means that if we hit any regression in our pre-release testing, we’re able to quickly triage and fix it.

Note that while we expect Reth the node to be stable and provide you with “no surprises” infrastructure, we still reserve the right to make breaking changes and refactor internal node APIs. If you are using Reth as an SDK and want it to become more stable, we’d love to work with you.

How secure is Reth 1.0?

Our security process is described in the Alpha and Beta releases. The codebase is extensively tested, and we use multiple tools such as Kurtosis, Assertoor, Hive, Goevmlab, our own fuzzers and more to automatically catch edge cases.

Beyond that, we’re excited to announce the successful completion of a thorough security engagement with Sigma Prime, developers of the Lighthouse Consensus client, which spanned several months and involved multiple security engineers. All reported issues have since been confirmed as fixed. The security assessment report is available here.

We also co-funded the community audit of Revm with Guido Vranken. Revm is the EVM engine behind Reth, Foundry, and so much more critical Ethereum infrastructure, and we are keen to continue helping harden it for production usage. Learn more about this in Dragan’s announcement.

Finally, we are now part of the Ethereum Foundation’s bug bounty program, so if you find a bug, make sure to be a whitehat and report it! Also see our SECURITY.md for other information.

OK, I’m sold! How do I install Reth?

For node operators who are excited to download Reth, see our releases page and the Reth Book. We provide signed binaries which are made available over popular package managers and container registries, DappNode, as well as instructions on how to install from source:

# MacOS
brew install paradigmxyz/brew/reth
# Arch
pacman -S reth # or reth-git for installing from HEAD
# Docker
docker pull ghcr.io/paradigmxyz/reth:v1.0.0:latest
# `cargo-install`
RUSTFLAGS="-C target-cpu=native" cargo install https://github.com/paradigmxyz/reth --locked --profile maxperf --features=jemalloc,asm-keccak
# from source
git clone https://github.com/paradigmxyz/reth && cd reth && make maxperf

The above should be enough to get you started with running Reth via the reth node command! To get quickly started on Ethereum mainnet in few hours you can grab a database snapshot from Merkle’s archive, or sync from genesis yourself!

Here’s a simple 1-liner you can use alongside an Etherscan API key to get a locally synced Holesky network node without any consensus layer required, just Docker (note that in Docker you need the -v flag to persist the node’s database across container restarts):

docker run --env ETHERSCAN_API_KEY=$ETHERSCAN_API_KEY ghcr.io/paradigmxyz/reth:latest node --debug.etherscan --chain=holesky

The CLI is modeled to be compatible with go-ethereum’s CLI, so once the binary or container is available, you can use Reth as a drop-in replacement for your nodes whether you’re running in a script or in Kubernetes, no additional steps needed! For observability please check the --metrics flag and our documentation, where we already provide a great Prometheus & Grafana setup.

Collaborate with the Reth team!

We envision that in the next ten years, the most impactful crypto-infrastructure will be on Reth. We think the path to get there is clear, but we cannot do it on our own, despite our team’s quality and our large community of open source contributors.

We’d like to collaborate with the ecosystem on the following two areas, among others:

• Reth as a higher performance and lower-cost drop-in replacement for existing infrastructure:
  • RPC operations like Infura or Alchemy can run Reth to improve their RPC’s read throughput and latency, and improve their margins by operating cheaper nodes.
  • Staking operations like Coinbase or Figment can run Reth to improve their attestation rates and contribute to client diversity.
  • L2s like Optimism can run OP-Reth to improve their sequencers’ write throughput and latency, as well as contribute to L2 client diversity.
  • Managed Blockchain Services like AWS or GCP or Latitude can integrate Reth to offer all of the above with a 1-click deploy experience.
• Reth will enable a new wave of EVM-centric infrastructure. Developers will:
  • Add support for more chains: Reth currently supports Ethereum and OP Stack-based networks. Developers can introduce support for their chain powered by Reth (or “Reth Inside”) using the Node Builder, similar to how Binance has been doing for BSC and opBNB, to ensure a high performance low storage footprint node. This would apply for e.g. StarkWare, Polygon, Arbitrum, ZK Sync and any other EVM L1s/L2s that follow Ethereum’s account model database. We are particularly excited for developers to build new blockchains using Reth as an SDK, and innovate with novel architectures, modules, precompiles, and more.
  • Build Reth Execution Extensions: We'd like people to build rollups, shared security services, and other projects on Reth which require a low latency and high context subscription to Ethereum.
  • Improve Reth’s internal modules: There are so many things to improve, whether it is reliably JIT'ing everything, parallel execution, making the SDK easier and more general to use, benchmarking, testing, and more.

We want tight feedback loops with ecosystem players, and would even train engineers from key external teams on the Reth codebase, to enable them to help their internal teams succeed.

We’re looking to bootstrap the first wave of Reth early partners. If you’re an industry player aligned with the above vision, please fill in this form. We’d love to hear from you and help you succeed with Reth.

Where do we go from here?

In the last 2 years, we have:

1. Announced the Reth project.
2. Released Reth Alpha.
3. Released Reth Beta.
4. Announced Reth AlphaNet.
5. Released Reth Execution Extensions.
6. Announced our roadmap to 1 gigagas per second and beyond.
7. Released Revmc.
8. Released Reth 1.0 (this post).

The Reth SDK is slowly but surely becoming a reality, starting with Ethereum and then with Layer 2s. We hope that you are as excited as we are to run Reth 1.0 in production. Expect soon a follow-up Reth 1.1 release which will be focused on stable and performant support for the OP Stack via OP Reth, including detailed updated performance benchmarks.

Our next major internal priorities are shipping the next Ethereum hard fork (Pectra) and rolling out Reth AlphaNet, with the goal of stress testing the limits of blockchain scalability and accelerating the rollup decentralization roadmap.

Externally, we’d like to collaborate with ecosystem players building services on the Reth SDK either for supporting new EVM-based L1s/L2s or with Execution Extensions; make sure to fill in the form we linked above to collaborate with us.

We’ll be talking about all this and the rest of our open source stack at Frontiers, on August 16-17th in San Francisco. Go apply!

In the meantime, go run Reth, join our community, or reach out directly to georgios@paradigm.xyz if you want to work together. We’re also hiring cracked full-time Rust engineers, especially ones that can tech lead – let us know if that could be a fit for you.

See you on Github.