Ress: Scaling Ethereum with Stateless Reth Nodes

Intro

We are excited to announce Ress (shorthand for: Reth Stateless), a fully validating stateless Ethereum Execution Layer with 14GB disk requirements. Stateless nodes matter not only for improving Ethereum’s decentralization, but also to scale the L1 gas limit, scaling optimistic L2s, and for implementing Native Rollups to improve the L2 ecosystem’s security & interoperability.

Ress illustrates that we can run Ethereum nodes with 70x lower disk requirements today, without any hard forks needed. For our proof of concept, we successfully ran Ress-backed Ethereum stakers on the Holesky testnet and correctly attested to block validity. We are excited for further protocol improvements which can make this work even more performant.

Ress is built on Reth in <4K lines of code including tests, further demonstrating Reth’s flexibility as an SDK for bleeding-edge EVM-core infrastructure.

What is stateless Ethereum?

Dankrad Feist wrote the canonical explainer on this topic in 2021, which we recommend reading as a companion to this post.

“Stateless” means a node does not need to hold the entire state (i.e. account balances, and smart contract storage) to process a block. Instead of having to check its local database, a node receives the state accessed from other nodes, verifies that it matches the last block’s state commitment using merkle proofs (or other similar methods), and proceeds to execute all transactions in that block.

This skips a lot of the internal details, but captures the essence of it. Statelessness is useful because it enables running nodes at lower cost, which should theoretically improve a network’s decentralization/censorship resistance. This process comes at a cost, trading off storage for bandwidth, because transmitting storage values & merkle proofs for each block can be expensive.

However, in 2024 we observed that state growth is unlikely to be a bottleneck for decentralization in the near-term, which made many node developers less excited about statelessness in the short-term. Maybe there is a fresh way to see things?

Stateless nodes can help scale Ethereum.

Traditionally, statelessness is described as a “defensive” feature, but we think there is also ways to utilize it for “offense”, in particular:

1. Scaling the L1 Gas Limit: The largest bottleneck in Ethereum node performance is the overhead that comes from calculating the state root per block, a process which requires random Disk I/O that gets more expensive the larger the state. Stateless nodes can do this process completely in-memory.
2. Scaling Optimistic L2s: Optimistic L2s require a network of verifiers to re-execute transactions at ~the same speed as the sequencer, to ensure that they can post a fault proof if the sequencer misbehaves. Stateless L2 nodes can help by only verifying a subset of the sequencer’s actions, effectively “sharding” an L2’s validation, enabling that L2 to go even faster, lowering its withdrawal period, without compromising the fault proof’s security.
3. Implementing Native Rollups: The fastest path to implementing Native Rollups (more secure/interoperable rollups that tightly integrate with Ethereum) involves re-execution of each rollup block on the L1 node. This can be prohibitively expensive both storage space wise and IO/memory-wise. Stateless re-execution fixes this.

How does Ress work?

Ress is Stateless Reth. It works today without any protocol changes. We demonstrated Ress being able to follow the tip of the chain & attest to its validity in Holesky, with P99 validation time of <1 second per block.

Stateless nodes have been thought to be previously impractical in the past because of the worst case size of the “witness” (the merkle proofs required to verify the validity of accessed contract storage/accounts against the last block’s header). We reduced the size of the witness to practical values by excluding contract bytecodes from the witness and assuming that the stateless node can store the contracts in its local database, which is about 10GB today for Ethereum mainnet, a value we think is acceptable.

Ress is built using Reth SDK in <4K lines of code, by reusing Reth’s P2P networking stack & via a “witnessed” EVM executor (similar to how zkEVMs work). We have implemented a RLPx subprotocol dedicated to Ress, an optional extension for Reth stateful nodes to provide necessary state data (witness, block, bytecodes) to stateless Ethereum peers.

Ress downloads and fully verifies all blocks since the last finalized block. Block verification is done in 3 steps: Fetch state witness, fetch and persist any missing bytecodes, verify the payload & calculate the new state root in memory. Live sync works like any other stateful EL node - it is advanced via CL requests through the Engine API.

We have tested Ress with Hive, and it passes most tests in the ethereum/engine test suite. The testing has been done using the ress hive adapter which sets up a stateful reth and a stateless ress node and proxies Engine API requests to both. Only the stateful reth node is used for the block building.

Native Support In Reth

Reth now supports ress RLPx subprotocol natively as of v1.3.1. You can enable it by passing --ress.enable argument. We've hosted several public nodes that you can peer with if you don't have an ability to run a Reth node yourself by adding them as peers manually. Find more in the README.

What is the future of Ress?

We release the Ress Proof of Concept today to share our research progress on reducing L1 node requirements and scaling L1s & L2s. We look forward to collaborating with the community to push the boundaries of what’s possible for execution clients. Make sure to star the Ress repository on Github!

If you’re interested in stateless nodes, working on Reth, or any of our other Rust open source tooling, reach out to georgios@paradigm.xyz.

See you in the issue tracker!

Acknowledgments

Huge thanks to piapark for getting the project off the ground, joshie for implementing hive adapter and storm for gathering the bytecode data.