Lesson 8 — Stateless Ethereum — reading ress and stateless-validator side by side

Question

Stateless Ethereum = validators run without state. Provers generate witness data + execution proof; validators verify with no DB. Read the two reference impls side by side.

Principle (minimum model)

• Stateless validator. Receives (block + state proof + execution proof) → verifies → finalises. No state DB; no MPT.
• Prover side. Has the state; computes the trie proof + execution proof for each block. Heavier compute; lighter consumers.
• Reference impl 1: ress. Ethereum Foundation's stateless-validator reference. Verkle-tree-based (next-gen of MPT).
• Reference impl 2: stateless-validator (reth). Reth's stateless mode. MPT-based; production-tuneable.
• Trade-off. Verkle (smaller proofs, harder DX) vs MPT (larger proofs, more compat).
• Hardware cost. Stateless validator runs on a Raspberry Pi; full validator needs SSD + RAM.
• Future. Pectra / Prague hard fork will enable stateless verification. Major shift in chain economics.
• Production impact. Smaller validators → more decentralisation. Lower hardware cost → more participation.

Worked example + steps

Stateless Ethereum — reading ress and stateless-validator side by side

A full Reth node on mainnet today wants ~3 TB of disk and the IOPS that match. Most of the people reading this lesson can't run one — not on a laptop, not on a typical VPS, not even on a hobbyist NUC. So the people who do run them become a small priesthood, and Ethereum's "anyone can verify" claim quietly stops being true at the validator layer.

A stateless client is the way out. Paradigm's ress re-validates every mainnet block with 14 GB of disk. MegaETH's stateless-validator re-validates an entire high-TPS L2 on commodity hardware. Both are Rust. Both verify Ethereum-equivalent state transitions. They made different design choices at every interesting layer — and reading them side by side is the cheapest way to learn what those choices even are.

1. Why stateless matters beyond "less disk"

The Paradigm blog post that ships with ress names four use cases. None of them is "save a hard drive."

• L1 decentralization. Anyone with a laptop can run a fully validating execution client. Validator set is no longer hardware-gated.
• L1 gas scaling. Today the gas limit is bottlenecked on what a stateful full node can keep up with — random-I/O for state reads dominates. A stateless verifier reads the witness from memory; the I/O ceiling moves.
• Optimistic L2 security. Fraud-proof watchtowers don't want to run reth for every L2 chain they watch. A stateless verifier per chain is cheap.
• Native rollups. The "EVM as a service" direction Vitalik described needs a re-executable verifier embedded in L1 — and that verifier can't carry a 3 TB state.

So stateless is not a "small node" feature. It's a verifier-layer feature for a particular class of clients that need to re-execute Ethereum cheaply, repeatedly, possibly inside a zkVM, possibly on hundreds of chains at once.

2. What "stateless" means, precisely

A stateless client validates a block without holding the entire world state in storage. To do that, every state read the block performs (and the post-state root it has to recompute) must come from a witness — a cryptographic bundle proving, against the previous block's trusted state root, exactly what values were at the slots the block touches.

The stateless party never sees the rest of the state. It does see — and re-derive — the post-state root, which then becomes the trusted root for the next witness.

The witness has to come from somewhere. In every stateless design, some non-stateless party (a Reth full node in ress's case, a MegaETH sequencer in stateless-validator's case) generates it. That asymmetry is the whole bargain: a small number of stateful witness-providers makes a much larger number of stateless verifiers possible.

3. Two independent implementations

Two production Rust stateless clients exist as of 2026. They were built by different teams, for different chains, with different priorities. That's the gift — most curricula get one reference implementation to study. We get two.

Paradigm's ress (Reth Stateless)

• Repo: paradigmxyz/ress
• Target chain: Ethereum mainnet, fully validating.
• Disk: 14 GB (vs ~3 TB for full Reth).
• Witness source: any full Reth node running with --ress.enable. Ress peers with it over a dedicated RLPx subprotocol named ress — see crates/ress/protocol in Reth.
• Witness format: Merkle Patricia Trie proofs (the format you saw in the MPT lesson — same AccountProof / StorageProof shape).
• Bytecode: fetched from the stateful peer on demand (via a separate GetBytecode message). Ress caches what it has seen; missing entries pull from the peer.
• Validation flow: consensus client sends NewPayload → ress requests witness + missing bytecode from a Reth peer → validates payload in memory → returns PayloadStatus.
• Production status: experimental, but the team ran ress-backed validators on Holesky and passed 206 of 226 Hive Cancun tests.

MegaETH's stateless-validator

• Repo: megaeth-labs/stateless-validator
• Target chain: MegaETH (a high-TPS Ethereum-compatible L2, OP-Stack-derived).
• Witness source: the MegaETH sequencer, served via a dedicated witness RPC endpoint (--witness-endpoint).
• Witness format: SALT proofs, not MPT — see megaeth-labs/salt. SALT is a static 4-level 256-ary trie whose leaves are SHI hash-table buckets, committed with Banderwagon + IPA — Banderwagon is a prime-order elliptic curve derived from Bandersnatch (a curve defined over BLS12-381's scalar field, picked for vector-commitment efficiency); IPA is Inner Product Argument, a logarithmic-size proof primitive originally from Bulletproofs and reused in Ethereum's Verkle tree research. ~1 GB of memory authenticates 3 billion items.
• Bytecode: partial statelessness. Contract code is NOT in the witness. The validator fetches bytecode on demand from a public RPC and caches it locally in a bounded ContractCache (crates/stateless-db/src/cache.rs).
• Validation flow: three-stage pipeline (FETCH → PROCESS → ADVANCE) in crates/stateless-core/src/pipeline. Multiple validation workers run in parallel on different blocks — embarrassingly parallel because each block has its own witness and its own pre-state root.
• Execution engine: pluggable. Default is vanilla revm. A second backend uses the formal K semantics of the EVM developed with Pi². Together with the JIT-compiled sequencer executor, that gives MegaETH three independent client implementations of the same state transition function.
• Trust model: the validator only checks the state transition. Canonicality comes from op-node deriving the L2 chain from L1 + DA — that's what makes the validator trust-minimized, not just trustless against a single RPC provider.

🔍 Find in repo. Open bin/stateless-validator/src/app.rs and find where the validator wires up the pipeline. Compare against ress's main entry — what does each treat as the "outer loop" of the node?

4. Side-by-side

5. Predict why partial statelessness

The MegaETH README spells it out: contract code changes infrequently compared to state. Hot DeFi contracts emit and read state every block; their bytecode hasn't changed since deployment. Embedding bytecode in every witness re-ships the same hundred kilobytes block after block. Fetching it once and caching locally is the obvious move — if you're willing to accept that the validator now has a small persistent store (it does — the bounded ContractCache in crates/stateless-db/src/cache.rs).

Ress doesn't get the same easy win because it's targeting mainnet, where one chain's worth of contract code is large but not unbounded, and the symmetry of "everything comes from one peer" simplifies the protocol. Different chain, different trade.

6. Predict why two execution engines

A consensus bug in revm is a consensus bug across every Reth fork in existence. If MegaETH ran only revm-derived clients, a single subtle interpreter bug — even one revm shares with itself across versions — could split or freeze the chain with no second opinion available. A formally-specified K-semantics executor disagrees with a buggy revm by design: the bug doesn't exist in the math. The MegaETH README calls this the small Trusted Computing Base principle and explicitly frames the pluggable engine as preventing single-points-of-failure.

This is also why the validator chose a single-threaded vanilla revm interpreter and in-memory storage as the default — simplicity over performance, so the TCB is small enough to audit thoroughly. The JIT-compiled sequencer takes the performance hit so the validator doesn't have to.

7. What the contrast teaches that one alone can't

If you'd only read ress, you'd come away thinking:

• Witnesses are MPT proofs (they aren't always)
• Stateless means fully stateless (it doesn't have to)
• The execution engine is the EVM's interpreter (it's a choice)
• Stateless clients are paced by the consensus layer (they don't have to be)

If you'd only read stateless-validator, you'd come away thinking:

• Stateless clients always need a custom commitment scheme (mainnet ones use MPT)
• Stateless clients always need an L2-style trust-minimized derivation pipeline (mainnet ones use Engine API)
• Statelessness is L2-shaped (it isn't — Paradigm's pitch is explicitly L1)

The contrast teaches the degrees of freedom in stateless design. Every aspect in the table above is a design choice someone made — not a fact about statelessness. When you fork either codebase for your own chain, those are the dials you'll be turning.

🔍 Find in repo. Open crates/stateless-core/src/evm_database.rs and find WitnessDatabase. It implements revm::DatabaseRef — every state read during execution goes through it. What does it return on a read that isn't in the witness? That answer is the contract between witness-generation (sequencer) and witness-consumption (validator). The same contract exists in ress, structured differently — find it.

8. Recall before you move on

Without scrolling:

1. Why is a stateless client useful beyond saving disk? Name two non-disk use cases.
2. What's the witness, and what does the verifier cryptographically check it against before reading any value out of it?
3. ress and stateless-validator make opposite calls on bytecode. State the call each made and the workload reason for the difference.
4. Why does MegaETH ship two execution engines for one chain? What failure does that prevent?
5. Of every aspect in the Section 4 table, which single difference do you think drives the most downstream design? Argue your pick in one sentence.

If 1–4 are shaky, scroll back. If you can't argue 5, you haven't internalized the contrast yet — the table is a flat list, but every row is connected to several others, and the lesson isn't done with you until you can trace at least two of those connections.

Further reading

• Paradigm blog: Stateless Reth Nodes — the use-case framing in Section 1 comes from here.
• paradigmxyz/ress — README, then bin/ entry point, then the RLPx subprotocol in paradigmxyz/reth/crates/ress/protocol.
• megaeth-labs/stateless-validator — README, then crates/stateless-core/src/pipeline, then crates/stateless-core/src/executor.rs.
• megaeth-labs/salt — the authenticated KV store that replaces the MPT in MegaETH's witness format.

Summary (3 lines)

• Stateless Ethereum = validators verify without state. Prover does heavy compute; consumers verify witness + execution proof.
• Two refs: ress (Verkle) + reth stateless-validator (MPT). Verkle smaller proofs; MPT more compat.
• Future: Pectra / Prague enables stateless. Major shift: validator hardware cost down, decentralisation up.