From paradigm by Georgios Konstantopoulos Apr 24, 2024

Contents

We started building Reth in 2022 to provide resilience to Ethereum L1, and solve execution layer scaling on Layer 2.

Today we’re excited to share Reth’s path towards 1 gigagas per second in L2 in 2024, and our longer-term roadmap for going beyond that.

We invite the ecosystem to collaborate with us as we push the frontier of performance and rigorous benchmarking in crypto.

We started building Reth in 2022 to provide resilience to Ethereum L1, and solve execution layer scaling on Layer 2.

Today we’re excited to share Reth’s path towards 1 gigagas per second in L2 in 2024, and our longer-term roadmap for going beyond that.

We invite the ecosystem to collaborate with us as we push the frontier of performance and rigorous benchmarking in crypto.

Are we scaled yet?

There’s a very simple path for cryptocurrencies to reach global scale and escape speculation as the dominant use case: Transactions need to be cheap and fast.

How do you measure performance? What does gas per second mean?

Performance is typically measured by the metric "Transactions Per Second" (TPS). Particularly for Ethereum and other EVM blockchains, a more nuanced and perhaps accurate measure is "gas per second." This metric reflects the amount of computational work that the network can handle every second, where "gas" is a unit that measures the computational effort required to execute operations like transactions or smart contracts.

Standardizing around gas per second as a performance metric allows for a clearer understanding of a blockchain's capacity and efficiency. It also helps in assessing the cost implications on the system, safeguarding against potential Denial of Service (DOS) attacks that could exploit less nuanced measurements. This metric helps compare the performance across different Ethereum Virtual Machine (EVM) compatible chains.

We propose to the EVM community to adopt gas per second as a standard metric, alongside incorporating other dimensions of gas pricing to create a comprehensive performance standard.

Where are we today?

Gas per second is determined by dividing the target gas usage per block by the block time. Here, we showcase the current gas per second throughput and latency across various EVM chains L1s and L2s (not exhaustive):

We emphasize gas per second to thoroughly assess EVM network performance, capturing both compute and storage costs. Networks like Solana, Sui, or Aptos are not included due to their distinct cost models. We encourage efforts towards harmonizing cost models across all blockchain networks to enable comprehensive and fair comparisons.

We are working on a continuous benchmarking suite for Reth replicating real workload, if you want to collaborate on this, please reach out. We need a TPC Benchmark for nodes.

How will Reth get to 1 gigagas per second? Beyond that?

We were partially motivated to build Reth in 2022 by the pressing need to have a client purpose-built for web-scale rollups. We think we have a promising path forward.

Reth already achieves 100-200mgas/s during live sync (including senders recovery, executing transactions, and calculating the trie on every block); 10x from here gets us to the our short-term goal of 1 gigagas/s.

As we advance Reth's development, our scaling plan has to balance scalability with efficiency:

The optimizations we are exploring here do not involve solving state growth, which we are researching separately.

Here’s a summary of how we intend to get there:

Across the entire stack we are also optimizing for IO and CPU using the actor model, to allow each part of the stack to be deployed as a service with fine control over its utilization. Finally, we are actively evaluating alternative databases, but have not decided yet on a candidate.

Reth’s vertical scaling roadmap

Our goal here is to maximize the performance and efficiency of a single server or laptop running Reth.

Just-In-Time & Ahead-of-Time EVM

In blockchain environments like the Ethereum Virtual Machine (EVM), bytecode execution happens through an interpreter, which sequentially processes instructions. This method introduces overhead because it doesn't execute native assembly instructions directly, instead operating through the VM layer.

Just-In-Time (JIT) compilation addresses this by converting bytecode to native machine code just before execution, thereby improving performance by bypassing the VM's interpretative process. This technique, which compiles contracts into optimized machine code ahead of time, is well-established in other VMs like Java and WebAssembly.

However, JIT can be vulnerable to malicious code designed to exploit the JIT process, or may be too slow to run live during execution. Reth will Ahead-of-Time (AOT) compile the highest demand contracts and store them on disk, to avoid untrusted bytecode trying to abuse our native-code compilation step during live execution.

We have been working on a JIT/AOT compiler for Revm, currently being integrated with Reth. We will open source this in the coming weeks once our benchmarking is done. About 50% of execution time is spent in the EVM interpreter on average, so this should provide a ~2x EVM execution improvement, although in some more compute heavy cases it might be even more impactful. We will be sharing our benchmarks and integration of our own JIT EVM in Reth in the coming weeks.

Parallel EVM

The concept of a Parallel Ethereum Virtual Machine (Parallel EVM) enables simultaneous transaction processing, diverging from the traditional serial execution model of the EVM. We have 2 paths forward here:

Based on our historical analysis, ~80% of Ethereum storage slots are accessed independently, meaning parallelism could yield up to 5x improvement in EVM execution.

Improving the State Commitment

We recently wrote about the impact of state root in performance and the differences between the Reth database model from other clients, as well as why it is important.

In the Reth model, calculating the state root is a separate process from executing transactions (see our code), enabling the usage of standard KV stores that do not need to know anything about the trie. This currently takes >75% of the end to end time to seal a block, and is a very exciting area to optimize.

We identify the following 2 “easy wins” which can give us 2-3x in the state root performance, without any protocol changes:

Going beyond that, we see a few paths forward by diverging from Ethereum L1 state root behavior:

There are a few questions here:

Reth’s horizontal scaling roadmap

We will execute on multiple of the above points throughout 2024 and achieve our goal of 1gigagas/sec.

However, vertical scaling ultimately encounters physical and practical limits. No single machine can handle the world's computing needs. We think there are 2 paths forward here, which allow us to scale out by introducing more boxes as more load arrives:

Multi-Rollup Reth

Today’s L2 stacks require running multiple services to follow the chain: L1 CL, L1 EL, the L1 -> L2 derivation function (which may be bundled with the L2 EL), and the L2 EL. While great for modularity, this gets complicated when running multiple node stacks. Imagine having to run 100 rollups!

We want to allow launching rollups in the same process as Reth and drive the operating cost of running thousands of rollups to almost zero.

We are already underway with this with our Execution Extensions projects ([1], [2]), more in the coming weeks here.

Cloud-native Reth

High performance sequencers may have enough demand on a single chain that they need to scale out to beyond a single machine. This is not possible in today’s monolithic node implementations.

We want to allow running Cloud-native Reth nodes, deployed as a service stack that can autoscale with compute demand and use the seemingly infinite cloud object storage for persistence. This is a common architecture in serverless database projects such as NeonDB, CockroachDB or Amazon Aurora.

See early thoughts from our team on some ways we could go about this problem.

Outlook

We intend to roll out this roadmap incrementally to all Reth users. Our mission is to give everyone access to 1 gigagas/s and beyond. We will be testing our optimizations out on Reth AlphaNet, and we hope people will build modified high performance nodes using Reth as an SDK.

There are some questions we have not arrived at answers for yet.

We do not have answers to many of these questions, but we have enough initial promising leads to keep us busy for a while and hope to see these efforts bear fruit in the coming months.