03.14.2025|Roman KrasiukGeorgios Konstantopoulos
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.
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?
Traditionally, statelessness is described as a “defensive” feature, but we think there is also ways to utilize it for “offense”, in particular:
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 is powered by a custom RLPx P2P subprotocol enabling nodes to fetch all the information needed to statelessly validate a block.
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.
Ress queries stateful Reth peers for state witnesses and executes blocks without needing to hold the entire state locally.
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.
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.
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!
Copyright © 2025 Paradigm Operations LP All rights reserved. “Paradigm” is a trademark, and the triangular mobius symbol is a registered trademark of Paradigm Operations LP