Stateless Client

Instead of holding the full state (e.g., all account balances), a stateless client receives a compact witness—a Merkle proof—alongside each new block. This proof cryptographically attests that the transactions within the block are valid against the current state root. The client only needs to store the constant-sized state root (e.g., 32 bytes for Ethereum).

Traditional Merkle Patricia Tries produce large witnesses. Stateless clients often depend on more advanced cryptographic accumulators like Verkle Trees (using Vector Commitments and KZG commitments). These structures produce constant-sized or logarithmically smaller proofs, making witness bandwidth practical for real-world deployment.

The core trade-off shifts resource requirements from local storage to network bandwidth. A stateless node does not need terabytes of SSD for state, but it must download a witness for every block it validates. This makes the design highly suitable for light clients, rollup validators, and resource-constrained environments.

By decoupling state storage from validation, stateless clients are a foundational technology for stateless blockchains and stateless rollups. They allow validators to participate in consensus without the hardware burden of full state, enabling networks to scale state size almost indefinitely without pricing out node operators.

Stateless clients typically require a weak subjectivity checkpoint—a recent, trusted block header—to bootstrap. They cannot historically validate the chain from genesis alone. They must also trust that the block proposer will provide a valid, complete witness, which introduces different trust assumptions compared to a full node.

Ethereum's The Verge upgrade is centered on implementing Verkle Trees to enable stateless clients. This will allow validators to run without storing state, drastically reducing hardware requirements and strengthening network decentralization. It is a critical step before Verkle Proofs can be used in stateless execution.

The primary motivation is to remove the massive state storage requirement from consensus participants. Instead of storing terabytes of data, a stateless client only needs a small, constant-sized cryptographic proof (a Witness) to validate blocks, enabling participation on resource-constrained devices.

By lowering the hardware barrier, stateless clients make running a full validating node feasible for more users. This combats centralization pressure and strengthens network security by increasing the number of independent verifiers, moving away from reliance on a few large archive nodes.

New nodes can join the network almost instantly. There is no need to download and process the entire historical state, which can take days. This enables fast sync and better user experience for wallets and light clients that require full security guarantees.

Statelessness is a prerequisite for advanced scaling techniques like stateless rollups and verkle trees. It allows block producers to handle state execution while enabling a large set of verifiers to check their work efficiently, a model essential for Ethereum's Verge upgrade.

While blocks must include witness data for verification, the overall data load can be optimized. Techniques like bandwidth-efficient protocols and aggregated proofs aim to keep network requirements manageable, trading some bandwidth for massive storage savings.

This architecture cleanly separates the roles of block proposers (who must access state) and block validators (who verify with proofs). This specialization allows for more efficient network design and paves the way for proposer-builder separation (PBS) models.

A stateless client does not store the full Merkle-Patricia Trie representing account balances and contract storage. Instead, it validates blocks using a witness—a compact cryptographic proof (like a Merkle proof) that contains all the state data accessed by the transactions in that block. The client only needs to know and trust the current state root (the hash at the top of the state tree).

Transitioning from Merkle to Verkle Trees is a key roadmap goal for stateless clients. Verkle Trees use Vector Commitments and polynomial commitments to generate much smaller witnesses. This reduces proof size from ~1 MB to ~150 bytes, making stateless verification practically feasible for light clients and even full nodes.

Ethereum's path to statelessness is part of The Verge upgrade. The roadmap involves:

• Deploying Verkle Trees for state storage.
• Enabling stateless block validation where block producers provide the necessary witness.
• Ultimately allowing full nodes to operate without storing state, drastically reducing hardware requirements and improving decentralization.

Benefits include:

• Lower Node Requirements: Drastically reduces storage and bandwidth needs.
• Improved Decentralization: Lowers barriers to running a fully verifying node.
• Faster Sync Times: Nodes can sync from genesis using only block headers and proofs.

Trade-offs involve increased block size due to attached witnesses and initial complexity in protocol changes.

While both are lightweight, they differ fundamentally. A light client (like Ethereum's LES client) trusts majority consensus and requests specific state data from full nodes. A stateless client performs full cryptographic verification of every block using proofs, offering trust-minimized security without storing state. Stateless design can enhance light client protocols.

Statelessness is often paired with state expiry proposals. To manage infinite state growth, older, inactive state could be 'forgotten' by the network. Nodes would need to provide proofs of history to reactivate it. This creates a stateless blockchain where only recent, active state needs to be proven, separating the concepts of block history and state storage.

The witness (proof of state) required for block validation must be transmitted with every block. For large, active states, this data can be substantial, creating a bandwidth bottleneck. Solutions like witness compression and state expiry are being researched to manage this overhead, but they add protocol complexity.

Generating the cryptographic proofs (e.g., Merkle proofs, Verkle proofs) for a block's state changes is computationally intensive for block producers. This shifts the burden from validators to proposers, potentially centralizing block production to entities with significant computational resources.

A stateless client must be able to fetch any piece of state data on-demand. This relies on a robust peer-to-peer network of nodes that store the full state. Ensuring this data is always available and resistant to censorship attacks is a critical and unsolved challenge at scale.

Traditional Merkle trees are inefficient for stateless clients because updating them requires recomputing all hashes to the root. Newer structures like Verkle trees (using vector commitments) and RSA accumulators are essential, but they are novel cryptographic constructs that require extensive auditing and standardization.

Integrating statelessness deeply changes core protocol mechanics, including:- Fork choice rules: Clients need proofs for the entire chain history, not just the latest state.- Sync protocols: Initial syncing and catching up require new methods beyond downloading the full state.- Gas accounting: Gas costs must account for witness verification, not just execution.

Migrating an existing, stateful blockchain (like Ethereum) to a stateless or state expiry model is a massive, multi-year coordination challenge. It requires careful hard fork planning, backward compatibility considerations, and widespread client software upgrades, risking network fragmentation if not managed perfectly.