Releasing Reth 2.0!

Reth 1.0 established that a node-as-a-library approach could meet the stability and feature completeness requirements for Ethereum, as well as support the extensibility required for Layer 2 networks. With Reth 2.0, we shifted our focus to the next frontier of performance and storage efficiency.

Reth 2.0 achieves 1.7 Gigagas/s performance1 while maintaining a significantly reduced disk footprint of approximately 240 GB (or a ~170 GB snapshot download).

These metrics are being validated in real-time on our production nodes - Ethereum mainnet and Tempo mainnet which is our high-performance chain designed to reach the physical limits of network throughput.

Download a snapshot and see for yourself, or check the ethPandaOps Lab Dashboard for a third-party comparison against other Ethereum clients. Below is Reth’s historical “winrate” graph from the ethPandaOps lab dashboard, measuring what proportion of blocks Reth validated the fastest compared to other clients:

A New Architecture: Pipelined Execution and Tiered Storage

To reach these speeds, we have overhauled how Reth processes block data and interacts with the disk.

Optimising Parallel State Calculation

The "state root" is a single hash representing the entire state of the network. Historically, calculating this was a sequential bottleneck because the node had to wait for transaction execution to finish in order to calculate the resulting state root. Reth already parallelised this with Sparse Trie by updating the state root in the background while executing transactions.

Reth 2.0 introduces Sparse Trie Cache, an in-memory representation of the state trie that survives across blocks. Previously, the state root task had to rebuild its working view of the trie for every block. By keeping this structure in memory, Reth 2.0 reduces the time spent calculating the final state root at the end of each mainnet block to just 1–2ms.

Reducing Data Redundancy

When a transaction updates an account, Reth must have that account and a Merkle proof for it loaded into the sparse trie cache. Previously, this involved fetching large, redundant sets of data from the disk for every update.

Reth 2.0 introduces Partial Proofs. Instead of fetching a full path (aka a proof) for every change, Reth now only retrieves the unique portions of the trie that haven't been cached. This eliminates redundant disk lookups and cuts the number of proof requests per block in half, significantly lowering I/O.

Here's what that looks like in practice, measured with reth-bench2 on Ethereum Mainnet:

Tiered Storage (Hot/Cold Database Split)

Database size is one of the most difficult challenges in scaling. Reth 2.0 addresses this in a few ways:

1. We now only store hashed state on MDBX, dropping the plain state tables.
2. We have moved over historical account and storage changesets to Static Files, our specialized append-only datastore, and our indices for fast access to RocksDB.

This has two implications:

1. Smaller database size, which also translates to lower read latency.
2. Faster persistence time, which lets us process more transactions with less memory.

Saving a standard block now only takes an average of 40ms, and even a massive "Gigagas-sized" block now persists in just 400ms. On Reth storage v1, a block of this size would take 8.4s to persist, giving us a roughly 20x speedup on persistence for storage v2.

This also has a great side-effect: You can now seamlessly go from full node to archive node and back, just mount the corresponding static files!

Minimal Mode

This architecture enables Minimal mode, a configuration for Reth that omits a significant amount of history and index data from the node. Reth stores only the hashed state tables and trie data required for validation. A Reth mainnet node can sync with <300GB disk now!

Need more than the minimum? You can opt in to any combination of extra data through your pruning configuration — headers, transactions, receipts, changesets (and their corresponding RocksDB indices). You choose exactly the data your use case requires, nothing more.

Snapshots: Get Running in 10 Minutes

What’s Next for Reth?

In the coming months we will be accelerating Reth with even more performance optimizations, including AOT/JIT execution via revmc, which we recently started working on again, since the state root computation is no longer a bottleneck for us. We will also implement full parallel execution, enabled by BALs in the upcoming Glamsterdam hardfork.

Go run Reth, join our community, or reach out directly to georgios@paradigm.xyz if you want to work together; we're hiring cracked full-time Rust engineers.

See you on GitHub.

Written by The Reth Team