Statelessness

Instead of storing the entire state, validators verify transactions using cryptographic witnesses (e.g., Merkle proofs) provided by the sender. This proof demonstrates the sender's knowledge of the current state (like an account balance) without the validator needing to store it locally. This reduces the hardware requirements for running a node.

• Core Mechanism: Sender includes a proof of state inclusion/validity.
• Validator Role: Checks the proof's cryptographic validity against a known state root.

Validators or light clients only need to store a tiny, constant-sized cryptographic commitment to the global state, such as a Merkle root or a Verkle root. The state size for a node does not grow with the number of users or smart contracts, eliminating one of the major bottlenecks to blockchain scalability and node decentralization.

• Key Data: A single root hash (e.g., 32 bytes).
• Contrast: Contrast with stateful chains where node storage grows linearly with usage.

The computational and bandwidth cost of proving state is borne by the transaction sender, not the network validators. This is reflected in the transaction's gas cost, which includes the fee for transmitting and verifying the witness. This model aligns economic incentives and prevents spam by making expensive computations a user-side cost.

• Economic Shift: Moves state proof burden and cost to the user.
• Transaction Size: Witnesses increase TX size, impacting gas fees.

Stateless clients are ultra-lightweight network participants that can verify block validity and the inclusion of their own transactions without syncing any historical state. They only need the current block header and the relevant witness for their transactions. This enables trust-minimized wallets and devices with very limited resources to participate in consensus.

• Capability: Verify execution without storing state.
• Use Case: Mobile wallets, IoT devices, and scalable light clients.

To manage the growing history that users must store, stateless designs often incorporate state expiry policies. Old, inactive state can be pruned from the required proof set, and users must provide longer proofs or interact with archive nodes to reactivate it. This requires robust protocols for storing and accessing historical data off-chain.

• Challenge: Managing long-term state availability.
• Solution: Networks of archive nodes and incentivized storage.

Traditional Merkle proofs become too large for statelessness at scale. Verkle trees, using Vector Commitments like polynomial commitments, enable extremely small and efficient witnesses (e.g., ~200 bytes vs. kilobytes). This is a critical cryptographic advancement making practical stateless validation feasible for Ethereum and other chains.

• Efficiency: Constant-sized proofs regardless of state size.
• Adoption: A core part of Ethereum's stateless roadmap.

Statelessness is a blockchain scaling architecture where validators or light clients can verify new blocks without needing to store the entire global state (e.g., account balances, smart contract storage). Instead, they rely on compact cryptographic proofs (like Merkle proofs or Verkle proofs) that attest to the correctness of state changes. The primary goal is to remove state storage as the primary bottleneck to decentralization, allowing nodes to operate with minimal hardware requirements.

• Full Node: Stores the entire blockchain history and the complete world state. Verifies all transactions by executing them against this local state.
• Stateless Client: Does not store the state. To verify a block, it receives a witness—a cryptographic proof containing all the state data accessed by the block's transactions. It checks the proof against a known state root (like a Merkle root).
• Half-Stateless/Stateful Validator: A proposed hybrid where validators are stateless, but a small subset of specialized nodes (state providers) maintain the state to generate witnesses.

A major innovation enabling practical statelessness is the Verkle tree. It is a vector commitment scheme that improves upon Merkle trees:

• Smaller Proof Sizes: Witnesses are constant-sized (~150 bytes) regardless of the amount of data accessed, unlike Merkle proofs which grow linearly.
• Efficient Updates: Allows for more efficient state updates, crucial for high-throughput blockchains.
• Ethereum's Path: Ethereum's Stateless Ethereum roadmap heavily relies on transitioning from Merkle Patricia Tries to Verkle Tries to make stateless validation feasible.

• Decentralization: Lowers node hardware requirements (CPU/RAM over storage), enabling more participants to run validating nodes.
• Security: Increases the number of independent validators, strengthening network censorship resistance.
• Light Client Performance: Enables truly trust-minimized light clients that can verify execution, not just consensus.
• Network Efficiency: Potentially reduces the bandwidth needed for new nodes to sync, as they don't need to download the entire state history.

• Witness Size: Even with Verkle trees, witnesses must be propagated with each block, increasing bandwidth requirements for block producers and relays.
• Complexity: Introduces significant protocol complexity in proof generation, verification, and networking layers.
• State Provider Role: In hybrid models, reliance on state providers creates a new potential centralization vector that must be carefully designed.
• Legacy Support: Transitioning an existing stateful chain (like Ethereum) to statelessness is a massive, multi-year engineering challenge.

• ZK-Rollups: Inherently stateless from the perspective of the L1, as they submit validity proofs (ZK-SNARKs/STARKs) that attest to correct state transitions without the L1 needing the L2 state.
• Mina Protocol: Uses recursive zk-SNARKs to maintain a constant-sized blockchain snapshot (~22KB), representing a form of statelessness.
• Witnesses: The cryptographic proofs (Merkle, Verkle) that are the essential data payload for stateless verification.
• State Expiry: A complementary concept where old, unused state is archived, reducing the active state size that stateless clients need proofs for.