How to Support Stateless Client Designs

A stateless client is a blockchain node that does not store the entire world state. Instead, it relies on cryptographic proofs, specifically Merkle proofs or Verkle proofs, to validate the state information needed to execute new blocks. The core state data—account balances, contract code, and storage slots—is provided alongside transactions in a bundle called a witness. This shifts the storage burden from the node operator to the block proposer, allowing nodes to run with minimal local storage, potentially on devices like smartphones or lightweight servers.

The primary driver for stateless clients is state growth. The Ethereum world state currently exceeds hundreds of gigabytes and grows continuously, creating a high barrier to entry for new node operators. By making validation stateless, the network can scale without requiring each participant to store this ever-expanding dataset. This design is a cornerstone for Ethereum's Verge upgrade, which will implement Verkle trees—a more efficient cryptographic structure for generating compact witnesses compared to traditional Merkle-Patricia trees.

Supporting stateless validation requires changes at both the consensus and execution client levels. Execution clients (like Geth, Nethermind) must be able to generate the witness for a proposed block and verify incoming witnesses using a stateless execution engine. Consensus clients must propagate these witness data alongside block proposals. Developers can experiment today using testnets configured for statelessness, such as those running early Verkle tree implementations, to understand the new block validation workflow.

For dApp and smart contract developers, the shift is largely transparent but has implications for gas optimization. Operations that access widely dispersed storage slots will generate larger witnesses, increasing block size. Best practices will involve designing storage layouts that keep related data close together (using contiguous storage slots) to minimize witness size. Tools like the Ethereum Execution API will eventually provide endpoints for fetching witnesses, which will be essential for building light clients and other stateless applications.

The transition to a fully stateless Ethereum is a multi-year roadmap. Interim solutions like state expiry may be deployed first, where old, unused state is archived, and nodes must provide proofs to reactivate it. This hybrid model helps manage state bloat while the tooling and infrastructure for pure stateless validation are finalized. The end goal is a network where running a fully validating node requires minimal resources, securing Ethereum's foundation as a decentralized, global computer.

The core requirement for stateless clients is a shift from storing the entire state to verifying it cryptographically. This is enabled by cryptographic accumulators, primarily Merkle Patricia Tries (MPTs) as used in Ethereum, or Verkle Trees as proposed for future upgrades. You must understand how these trees commit to the entire state (accounts, storage, code) in a single root hash. The client's job is to validate that a piece of data, like an account balance, belongs to the committed state using a Merkle proof (or Verkle proof), which is a set of sibling hashes along the path from the leaf to the root.

You need a deep familiarity with the specific block header structure of the chain you're working with. For Ethereum, this means knowing the fields: stateRoot, receiptsRoot, transactionsRoot, and the recent withdrawalsRoot. A stateless client receives a block header and a proof; it recomputes the root from the proof and asserts it matches the header's stateRoot. Implementation requires libraries for RLP (Recursive Length Prefix) encoding/decoding and Keccak256 hashing, as these are fundamental to Ethereum's Merkle tree construction.

On the execution side, your client must be able to process a witness. A witness contains all the state data (account and storage values) accessed during block execution, along with their Merkle proofs. The EVM execution logic remains the same, but instead of querying a local database, it reads from the provided witness and cryptographically verifies each accessed value against the state root. This requires modifying the client's state access layer to be proof-aware.

For development and testing, you'll need access to tools that generate these proofs. Simply syncing a standard full node is insufficient. You should use a proof-generating node implementation or a library like turbo-geth's witness extractor. Testing involves creating test vectors: a pre-state root, a block to execute, the resulting post-state root, and the corresponding witness that validates the transition. The Ethereum Execution API Specs provide guidance on witness-related RPC methods.

Finally, consider the networking layer. Stateless clients rely on the peer-to-peer network to receive blocks alongside their corresponding witnesses. You must understand the wire protocols (like Ethereum's devp2p) and any proposed extensions for witness propagation, such as the BlockWitness network message. Implementing efficient witness compression and caching strategies is also crucial for performance, as redundant data across blocks can be eliminated.

A stateless client does not store the full blockchain state (account balances, contract storage). Instead, it receives and validates witnesses—cryptographic proofs that a piece of state is correct—from the network. This drastically reduces storage requirements, enabling lightweight clients like phones or browsers to fully verify transactions without trusting a third party. The core challenge is generating compact, verifiable proofs for any state access a transaction might need.

The primary cryptographic tool enabling this is the Merkle-Patricia Trie (MPT) or a Verkle Tree. These data structures hash the entire state into a single root. A witness is a Merkle or polynomial commitment proof that a specific leaf (e.g., an account's balance) exists under that root. For Ethereum, the shift from MPTs to Verkle Trees (via EIP-6800) is critical, as Verkle proofs are significantly smaller, making stateless clients practical for bandwidth-constrained environments.

To support stateless validation, block builders must provide a witness alongside each block. This witness contains all the state proofs required to execute the block's transactions. Clients can then execute the block using only the block data and the witness, verifying each state read against the state root in the block header. Protocols must define a standard format for these witnesses, such as the SSZ serialization used in Ethereum's beacon chain for efficient proof aggregation.

Developers building for a stateless future should design protocols with witness minimization in mind. This involves structuring state accesses to be predictable and localized. Techniques include using storage keys that can be derived from public data, batching operations within a single contract, and avoiding patterns that require random access across vast state segments. Smart contract audits should now include witness size analysis as a security and efficiency metric.

Implementing a basic stateless client involves libraries like go-verkle or reth. The workflow is: 1) Receive a block and its associated witness. 2) For each transaction, extract the required state proofs from the witness. 3) Execute the transaction, using the proof to validate each SLOAD or BALANCE opcode call against the expected state root. 4) Reject the block if any proof is invalid or missing. This shifts the trust assumption from the node's local database to the cryptographic soundness of the proof system.

The transition to statelessness is a multi-phase process. An intermediate step is state expiry, where old, unused state is removed from active storage but remains accessible via historical proofs. Full statelessness, where even block producers can be stateless, requires widespread adoption of Verkle Trees and efficient witness propagation networks (like the DAS network in Ethereum's danksharding roadmap). This evolution will fundamentally improve blockchain scalability and decentralization.

Stateless clients are a scaling paradigm where nodes verify blocks without storing the entire state. Instead, they rely on witnesses—cryptographic proofs that a specific piece of state data (like an account balance) is part of the current state root. The core challenge is designing a witness generation system that is sufficient (contains all needed data), compact (minimizes size), and verifiable (efficient to check). This requires a deep understanding of the underlying state tree, typically a Merkle-Patricia Trie (MPT) in Ethereum or a Verkle tree in newer designs.

Witness generation occurs during block construction. For a transaction accessing accounts A and B, the block producer must include a Merkle proof for each. This proof is the set of sibling hashes along the path from the leaf node (the account data) to the root. In an MPT, this includes branch nodes and extension nodes. The generated witness is then packaged with the block. Stateless clients receive the block and witness, recompute the root hash using the provided proof, and verify it matches the block header's state root, all without local state storage.

Efficiency is paramount. A naive witness containing all trie nodes for a transaction can be large. Witness compression techniques are critical, such as using binary Merkle trees for simpler proofs or Verkle trees (using vector commitments) which offer constant-sized proofs regardless of state size. Projects like Ethereum's stateless roadmap focus on Verkle trees for this reason. Another method is witness aggregation, where proofs for multiple accessed state items are merged to eliminate redundant node data.

For developers, generating witnesses requires interacting with a client's proof generation API. Using Ethereum execution clients as an example, you can use the eth_getProof RPC method to fetch a proof for an account and its storage slots. The returned object contains the account proof and storage proofs, which together form the witness. Here's a conceptual snippet for a block builder:

pythonCopy
# Pseudo-code for witness collection
witness_data = []
for address in tx.get_accessed_addresses():
    proof = eth_rpc.get_proof(address, block_number)
    witness_data.append(proof)
# Serialize and attach witness_data to the block

Implementing stateless client logic involves verifying these witnesses. The client must have the logic to hash nodes in the correct order and compute the expected root. Libraries like Trie in Go-Ethereum or MerkleTree.js provide functions for proof verification. The primary security consideration is soundness: the system must guarantee that a valid witness can only be generated for data that is actually in the committed state. Any flaw here compromises the entire chain's security, as clients accept invalid state transitions.

The future of witness design lies in standardization and specialization. As rollups and light clients proliferate, efficient witness formats like SSZ (Simple Serialize) with Merkleization in Ethereum 2.0, or Plonky2 proofs in zk-rollups, are becoming essential. The goal is to move towards clients that only need the block header and a tiny, universally verifiable witness, dramatically reducing hardware requirements and enabling truly decentralized validation on resource-constrained devices.

Stateless client design is a paradigm where a node verifies blockchain state without storing it locally. Instead of maintaining a full copy of the state trie, the client receives a witness—a cryptographic proof containing the specific state data needed to execute a block. The core verification relies on the state root committed in the block header. This model drastically reduces storage and bandwidth requirements, enabling resource-light nodes that can participate in consensus or execution validation. Key to this architecture are verkle trees or advanced Merkle proofs, which compress witness sizes to be practical for propagation.

Integrating stateless support requires changes at the protocol and client levels. First, the blockchain's state commitment scheme must be upgraded. Ethereum's shift to a Verkle tree structure, via EIP-6800, is the canonical example, as it enables efficient polynomial commitment proofs. Your protocol must define a new block validity rule: execution must succeed using only the provided witness and the pre-state root. Clients will need new network protocols to request and serve witnesses (e.g., via GetBlockWitness in Ethereum's devp2p). The execution engine must be modified to accept a witness and use it to populate a transient state cache during block processing.

For developers, the primary task is modifying the execution client. When a new block arrives, the engine receives the block and its associated witness. The execution logic must validate the witness against the trusted pre-state root, typically by verifying a proof that the provided key-value pairs belong to the committed tree. Then, it executes transactions using this verified, partial state. A reference implementation is found in Ethereum's Erigon client, which has early support for stateless execution. Testing requires a devnet configured with the new state tree and tooling to generate valid witnesses for transactions.

Challenges include witness size management and syncing. Even with Verkle trees, witnesses for complex blocks can be large (aiming for 1-2 MB). Protocols need efficient witness compression and gossip strategies. Additionally, a stateless client cannot historically validate the chain from genesis without state; it must trust a recent checkpoint or use a weak subjectivity sync. Future optimizations involve state expiry, where old state is automatically removed from the consensus requirement, and proof aggregation to bundle multiple updates. Supporting stateless designs is essential for scaling validator participation and enabling lightweight verifying clients on devices like phones or browsers.

Stateless clients represent a fundamental shift in blockchain node architecture, moving away from storing the entire state to verifying it cryptographically. The core enabling technologies are Verkle trees for efficient state proofs and witnesses that contain the necessary Merkle/Verkle proofs for transaction execution. This design drastically reduces hardware requirements, enabling light clients to validate the chain with near-full-node security. Major ecosystems like Ethereum (via The Verge) and Polkadot are actively researching and implementing these concepts to solve state growth, the primary bottleneck to decentralization.

For developers looking to build with or for stateless clients, the next steps are practical and protocol-specific. On Ethereum, familiarize yourself with the EIP-6800 specification for Verkle trees and test implementations in clients like Geth or Reth. Experiment with generating and serving witnesses using libraries from the ethereum/verkle GitHub repository. For other chains, study their unique state models; a Cosmos SDK chain using IAVL trees has different witness requirements than a Solana client using concurrent Merkle trees. Building a simple proof-of-concept that fetches a state proof and verifies it locally is an excellent starting project.

The research frontier is equally active. Key open problems include optimizing witness compression algorithms, designing efficient protocols for witness gossip across peer-to-peer networks (like Ethereum's Portal Network), and creating robust incentives for witness providers. Researchers can contribute by exploring new cryptographic accumulator structures beyond Verkle trees or formalizing the security models of stateless validation in adversarial network conditions. Engaging with the community through the Ethereum Research forum or the R&D channels of client teams is crucial for collaboration.

Supporting stateless client infrastructure is a community effort. You can contribute by running a bootnode or a witness server for networks that support them, helping to decentralize this critical data layer. For validators and node operators, staying informed about client upgrades that introduce stateless components is essential for a smooth transition. Finally, advocating for and testing these designs on public testnets provides invaluable real-world data that guides their development toward a more scalable and decentralized blockchain future.