How Execution Models Work: Stateful vs Stateless Architectures

TL;DR

- Stateless execution: validators don’t store the full state; they just verify transitions using cryptographic witnesses.

- Stateful execution: every validator keeps and updates the entire world state (Ethereum mainnet’s traditional model).

- Stateless relies on compact proofs (Verkle trees, STARKs) and strong DA layers.

- Core trade-off: far lower hardware cost + better decentralization vs. higher proof size and bandwidth.

- Today’s reality: pure stateless is rare; most modular stacks use stateless execution + stateful DA/settlement (hybrid).

- Leading examples: Ethereum Verge (Verkle), Polygon AggLayer, Celestia-based rollups, and lazy bridging.

Why Execution Models Matter in 2025

The way a blockchain node accesses and updates state is no longer an implementation detail; it has become one of the primary scaling and sovereignty levers in modular designs. As rollups, appchains, and sovereign L2s proliferate, architects must decide whether validators will carry terabytes of historical state or verify state transitions without ever storing the state themselves. 

The choice between stateless and stateful execution directly impacts decentralization, hardware barriers, data availability costs, and cross-chain composability.

Defining the Two Models

Stateful Execution – The Classic Approach

In a stateful model, every full node maintains a complete, up-to-date copy of the entire world state (account balances, smart-contract storage, code hashes, etc.). When a block is proposed:

1. The block producer includes transactions and a new state root.

2. Each validator re-executes every transaction against its local state copy.

3. If the resulting state root matches the one in the block, the block is accepted.

Ethereum, Solana, BNB Chain, and almost every monolithic L1 operate this way. The advantage is simplicity and immediate finality of state queries, any node can answer “what is the balance of address X?” without talking to anyone else.

The downside is obvious in 2025: Ethereum’s full archive node now exceeds 14 TB and growing. Even pruned full nodes require ~1 TB SSD and 32+ GB RAM, pricing out most individual operators.

Stateless Execution

In a stateless model, validators do not keep the world state locally. Instead, every transaction (or batch) is accompanied by witness data, cryptographic proof that the transaction has access to the required state slices (e.g., Merkle branches in Patricia trees or Verkle proofs).

The validation flow becomes:

1. Block producer attaches witnesses + transactions + new state root.

2. Validators check that witnesses are valid against the last accepted state root.

3. Validators re-execute transactions using only the provided witness data.

4. If the computed new state root matches the block’s claim, accept.

No node ever stores more than a few blocks of recent state. The burden shifts from storage to bandwidth and cryptographic verification.

Technical Trade-offs at Scale

Hardware Requirements & Decentralization

Stateless wins decisively here. A stateless Ethereum client being tested on Verge testnets today runs comfortably on a $300 mini-PC or even high-end Raspberry Pi 5 clusters. In contrast, running a stateful execution node on most L1s or L2s requires enterprise-grade hardware.

Real-world evidence: Celestia’s data-availability light nodes already operate statelessly with <8 GB RAM, while Ethereum execution nodes struggle under state bloat.

Bandwidth & Proof Size

The main drawback of pure stateless execution has always been witness bloat. With Ethereum’s legacy Merkle–Patricia Trie, a single ERC-20 transfer typically requires around 1–3 KB of witness data. Even at 1,000 TPS, this translates to tens of megabits per second of proofs alone, already pushing the limits of what is practical for stateless clients.

That’s why the entire ecosystem is now racing toward Verkle trees and STARK recursion: both shrink witnesses by 20–30× and make stateless clients practical at real-world throughput.

Data Availability Guarantees

Stateless clients are only as secure as the underlying data availability. If the block producer withholds part of the witness or state delta, a stateless validator cannot detect fraud without the full data.

This is why stateless execution almost always pairs with a dedicated DA layer (Celestia, Ethereum DAS post-Prague, Avail). The DA layer remains stateful, meaning it must store and serve data, but the execution validators stay lightweight and stateless.

Synchronous vs Asynchronous Composability

Stateful rollups (e.g., Arbitrum One pre-Atlas, OP Stack chains) offer synchronous composability: a token on one rollup can be used in another rollup in the same block if they share the same settlement layer.

Stateless designs tend toward asynchronous composability because state proofs take time to generate and propagate. Projects like Polygon AggLayer and Succinct’s SP1 bridges are solving this with pre-confirmation mechanisms and shared stateless bridges.

Real-World Implementations 

Ethereum – The Verge Roadmap (Verkle Trees)

Ethereum’s upcoming “The Verge” upgrade replaces Patricia Merkle trees with Verkle trees, reducing witness sizes from kilobytes to ~30–50 bytes per storage slot. EIP-6800 and EIP-7691 lay the groundwork for fully stateless clients by 2026–2027. Once live, anyone will be able to run a full validating node on a laptop while still verifying the entire chain.

Celestia + Rollups – DA Stateless, Execution Mixed

Celestia itself is fully stateless for data availability sampling. Rollups posting to Celestia (e.g., Doma, Movement) typically run stateful execution nodes today, but projects like Eclipse and Citrus (Celestia-based SVM rollup) are moving toward stateless SVM clients using STARK proofs and Celestia DA.

Polygon AggLayer – Unified Stateless Bridge

The AggLayer implements a shared stateless proof aggregator. Individual chains can remain stateful internally, but cross-chain messages are proven via stateless ZK proofs against a unified state root. This gives the security of a single shared settlement layer without forcing every validator to store every chain’s state.

Hybrid Approaches – The Practical Middle Ground

Pure stateless execution remains rare in production. Most teams adopt one of three hybrid patterns:

- Stateful execution + stateless validation (e.g., zkSync Era’s boojum prover generates proofs that any stateless node can verify).

- Stateless execution clients + stateful DA/settlement (Ethereum + Celestia model).

- Stateless bridging layer on top of stateful chains (AggLayer, Near’s Chain Signatures).

These hybrids capture most decentralization benefits while keeping proof costs manageable.

Looking Ahead

By 2027, the default assumption in modular architecture will likely be “execution is stateless, data availability and settlement are minimally stateful.” Advances in Verkle trees, STARK recursion, and distributed witness distribution (e.g., Portal Network, Helios stateless light client) are removing the last major obstacles.

For builders choosing an execution model today:

- If you prioritize maximum decentralization and long-term sovereignty → go stateless from day one (pair with Celestia/Avail/Ethereum DAS).

- If you need synchronous composability and are comfortable with higher hardware requirements → stateful execution with aggressive pruning and eventual migration path to stateless.

The stateless model isn’t a silver bullet, but it is rapidly becoming table stakes for any chain that wants to remain credibly neutral and globally accessible as state grows without bound.

The future of scalable, sovereign blockchains is one where no single entity, no matter how well-funded, has to store the entire history of the chain to participate in consensus. That future is already being built.