Stateless Clients

The core cryptographic structure enabling statelessness. Verkle trees replace Merkle Patricia Tries, using vector commitments to generate constant-sized proofs (~150 bytes) regardless of data size. This allows a client to verify any piece of state (e.g., an account balance) with a single, small proof from a block producer, eliminating the need to store the entire state trie.

The proof package required for block validation. A witness contains all the Verkle proofs needed to execute and validate the transactions in a block. Block producers (e.g., validators) must generate and broadcast this witness alongside the block. Stateless clients receive the block and witness, use the proofs to recompute state changes, and verify the new state root.

The fundamental exchange at the heart of the design. Stateless clients trade massive state storage requirements (terabytes) for increased bandwidth consumption. They download compact proofs for each block instead of storing the global state. This shifts the burden from long-term storage to network overhead, making node operation feasible on resource-constrained devices.

The process by which a client verifies a block without a local state DB. The client:

• Receives a new block and its associated witness.
• Uses the witness proofs to cryptographically compute the expected post-execution state root.
• Compares this computed root to the state root committed in the block header.
• If they match, the block and all transactions are valid. No prior state knowledge is needed.

Two models with different requirements for block producers.

• Weak Statelessness: Only regular clients are stateless. Block producers (validators) must still hold the full state to construct blocks and witnesses. This is Ethereum's near-term goal.
• Strong Statelessness: All nodes, including block producers, are stateless. This requires more complex protocols like state expiry or state rent to manage state growth, and is a longer-term research goal.

Key applications that benefit from stateless architecture.

• Light Clients: Become truly trust-minimized, verifying execution with proofs instead of relying on social consensus.
• Rollups: ZK-Rollups are inherently stateless between their prover and verifier. Stateless Ethereum clients would allow for seamless, low-cost verification of ZK-rollup proofs on L1, enhancing interoperability and security.

A stateless client is a blockchain node that validates new blocks and transactions without maintaining a full copy of the global state (e.g., account balances, smart contract storage). Instead, it relies on cryptographic proofs, like Merkle proofs or SNARKs, to verify that state changes proposed in a block are correct. This drastically reduces the hardware requirements for running a node, enabling verification on resource-constrained devices.

The critical piece of information a stateless client needs is called a witness. A witness contains the cryptographic proofs required to verify a specific state transition.

• For an account balance update, the witness includes a Merkle proof demonstrating the account's prior state within the state root.
• For a complex smart contract interaction, it may require a zk-SNARK proving the execution was valid. The block producer is responsible for generating and attaching the witness for all state accessed in the block.

A Verkle Tree is a cryptographic data structure, proposed as an upgrade to Merkle Patricia Tries, designed explicitly for efficient stateless clients. Its key innovation is using Vector Commitments (like KZG polynomial commitments) instead of simple hash functions. This allows witnesses to be constant-sized (~100-200 bytes) regardless of the amount of state accessed, solving the witness size explosion problem that makes Merkle-tree-based stateless clients impractical for Ethereum today.

Benefits:

• Low Hardware Barrier: Enables lightweight nodes with strong security guarantees.
• Decentralization: Lowers the cost of running a validating node.
• Fast Sync: Nodes can sync almost instantly by verifying the latest block with a witness.

Trade-offs & Challenges:

• Increased Block Size: Witness data increases the on-chain data burden for block producers.
• Producer Overhead: Block producers must generate proofs for all state accesses, increasing computational load.
• Complexity: Introduces new cryptographic assumptions and engineering challenges.

Ethereum's roadmap, via The Verge, aims to introduce stateless clients. The path involves:

1. Transitioning the state tree to a Verkle Tree (EIP-6800).
2. Enabling stateless validation where consensus nodes (validators) can verify blocks without storing state.
3. Eventually moving to a stateless block production model, which may require advanced proof systems like SNARKs. This evolution is critical for sustaining Ethereum's decentralization as its state grows exponentially.

• Light Client: Downloads block headers and relies on full nodes for state data (trusted model). A stateless client is a more secure, untrusted variant.
• State Expiry / History Expiry: Complementary proposals to limit the active state size, making stateless witness generation more manageable.
• ZK-Rollups: These Layer 2 solutions are inherently stateless from the perspective of the main chain, which only verifies validity proofs of state transitions.
• Client Diversity: Stateless clients could improve this by allowing more participants to run verifying software.

State expiry is a complementary protocol change that automatically removes ('expires') inactive state after a certain period (e.g., one year). This prevents the historical state from growing indefinitely, a requirement for practical stateless clients.

• Mechanism: Expired state is moved to a separate history tree. To reactivate it, a user must provide a proof against this historical archive.
• Benefit: Limits the working state that block producers must maintain, reducing their hardware burden.

Weak subjectivity is a security model where nodes must periodically sync with a trusted source (e.g., a checkpoint) to ensure they are on the correct chain. It is often discussed in the context of stateless clients and light clients.

• Necessity: A fully stateless node, starting from genesis, cannot distinguish the canonical chain from a long-range attack without recent, trusted information.
• Checkpoints: Clients sync a recent, signed weak subjectivity checkpoint (a block header) to bootstrap their view of the chain.