Statelessness: The Final Frontier of Decentralization. // Aayush Giri

An Ethereum full node running Geth sits around 650 to 700 GB of SSD in steady state, with the database growing about 14 GB a week and dropping back after a prune. The underlying state itself grows by about 30 GB a year on top of the accumulating history. An archive node on Geth's path-based layout is 1.9 to 2.0 TB; the older hash-based archive is above 12 TB. EthStaker's 2026 minimums for a solo validator are a quad-core CPU, 32 GB of RAM, 4 TB of SSD, and 10 Mbps of bandwidth both ways. That is the machine that secures Ethereum today.

It is also the reason the solo-staker share of nearly a million active validators keeps drifting down.

Statelessness is the proposal that this machine should be a laptop, then a phone, then eventually a smart watch. Not in a marketing sense. In the literal sense that a node should verify a block without storing the state the block touches, by accepting a short cryptographic witness from whoever produced the block. The state tree does not go away. It gets served from elsewhere. Your node keeps the chain honest without keeping the chain.

The headline work for 2026 is about execution throughput and post-quantum signatures. Statelessness sits under both. Without it, the only way to raise the gas limit without bleeding solo stakers is to keep asking them for more disk. With it, the gas limit rises and the hardware target falls at the same time. The headliners get the big-picture coverage, and they deserve it. This piece is about the part that decides who gets to run a node in 2030.

What a Stateless Client Actually Is

A stateless client is a full node that does not store the state trie. When a block arrives, it arrives with a witness: the exact set of account and storage leaves the block's transactions touch, plus a cryptographic proof that each leaf is part of the current state root. The client executes the block against the witness, recomputes the new state root, and checks it matches the header. Same validation, same security, no disk.

Two knobs decide whether this works in practice.

01Witness size. The witness travels with the block, so it costs bandwidth and verification time. A 3 MB witness is a non-starter. A 150 KB witness is borderline. A sub-100 KB witness is where stateless clients become cheaper than stateful ones for most home operators.
02Commitment scheme. The tree's hash function and commitment scheme decide the witness size and whether the whole thing survives a future quantum computer. This is the fight Ethereum has been having with itself for two years.

The Idea Is Older Than the Tech

The stateless client concept is not new. Vitalik posted it on ethresear.ch in late 2017. The Ethereum Foundation's 1.x team wrote "The State of Stateless Ethereum" in December 2019 and "The Stateless Ethereum Tech Tree" in January 2020. Both made the same argument: stateless clients are possible; they are just not small enough yet.

The problem in 2020 was the state tree itself. A single ERC-20 transfer in the current hexary Merkle-Patricia trie needs 1 to 3 KB of witness data. A full block with thousands of state touches measures in megabytes. That number has to come down before any of this ships to mainnet.

Verkle trees were the fix. Vitalik's June 2021 post made the case: replace the hexary Merkle-Patricia trie with a tree built on polynomial vector commitments, and the witness for a 1,000-value block drops from roughly 3.5 MB to roughly 150 KB. A 23x reduction. Per-account witnesses shrink to about 200 bytes. Per-storage-slot witnesses shrink to 30 to 50 bytes. The Kaustinen testnet launched in 2023 and ran through multiple relaunches. Geth, Nethermind, Besu, Nimbus, and Erigon all built Verkle branches. The plan was to ship Verkle in the first hard fork after Pectra.

Then, in mid-2024, the assumption underneath Verkle cracked.

Why Verkle Slipped

Verkle's witness compression comes from elliptic-curve polynomial commitments. An elliptic-curve commitment is breakable by a sufficiently large quantum computer. So is every ECDSA signature Ethereum uses. So is the BLS aggregation scheme on the consensus layer, which is exactly why the 2026 Hegotá fork exists. The question the core devs spent 2024 arguing was whether it is worth shipping a state tree that will have to be replaced again inside a decade.

Vitalik's October 23, 2024 post, "Possible futures of the Ethereum protocol, part 4: The Verge", is the moment this became public.

Over the past year the Verge has become much more open-ended, and there are several possibilities.

The alternative he laid out is a binary Merkle tree with a STARK-friendly hash, wrapped in a SNARK. STARKs are post-quantum by construction. The witness is not 150 KB; it is a proof on the order of a megabyte. But it is a proof you verify once per block, and it survives the quantum transition that Verkle does not.

The performance numbers stopped being hypothetical around the same time. Polygon benchmarked 1.7 million Poseidon hashes per second on a laptop with circle STARKs. The Ethereum Foundation put up a $1M Poseidon Prize and a $1M Proximity Prize in 2024 and 2025 to get STARK-friendly hashing audited and hardened. In January 2025, Guillaume Ballet, Vitalik Buterin, Dankrad Feist, Ignacio Hagopian, and others filed EIP-7864: replace the hexary Keccak Merkle-Patricia trie with a unified binary tree. The current draft uses BLAKE3 for implementation friction, with Keccak and Poseidon2 as candidates once the cryptography settles.

EIP-7864's headline claim: a binary tree with a fast hash produces Merkle branches about 4x shorter than the current hexary structure, and swapping the hash for a STARK-friendly variant buys another 3x to 100x in proving efficiency.

The Numbers That Decide

The comparison the debate keeps returning to:

witness size comparison

# Current (hexary MPT + Keccak)
per-account witness       = 1–3 KB     # worst case ~9 KB
1000-value block witness  = ~3.5 MB
full node state           = ~700 GB
archive node              = 18–20 TB   # Geth, 2026

# Verkle (hexary-ish tree, IPA/KZG commitments)
per-account witness       = ~200 B
per-storage-slot witness  = 30–50 B
1000-value block witness  = ~150 KB    # 23x smaller than today
post-quantum              = no
maturity                  = Kaustinen testnet since 2023, multi-client

# Binary tree + STARK (EIP-7864 direction)
per-block witness         = ~0.8 MB measured; sub-MB target
post-quantum              = yes (hash-based)
maturity                  = draft spec, depends on Poseidon2 audits
proving speed             = 1.7M Poseidon hashes/sec on a laptop

Verkle is smaller on the wire. Binary-plus-STARK is larger on the wire but smaller in the long run because it does not need to be replaced again. The short-term argument is about witness KB. The long-term argument is about whether you ship the same tree twice.

Statelessness Is Only a Third of the Story

A stateless client validates blocks without the state. It still has to answer RPC queries, serve historical data to other peers, and sync new nodes. That work has to live somewhere.

History expiry is the first half of the answer. EIP-4444 and its partial rollout in 2025 say full nodes stop serving pre-Merge history after a year; anyone who wants it fetches it from archival operators or from the Portal Network. The July 2025 client rollout was the first time mainnet clients started actually deleting old bodies and receipts. That is how a "full node" shrinks below 700 GB without losing its validation guarantees.

The Portal Network is the other half. It is a DHT-based peer-to-peer network designed specifically to serve the pieces a light or stateless client needs: block headers, receipts, state access by key. Piper Merriam and the old Trinity team started it years ago on the observation that the existing devp2p network was not built for light-client access. The launch clients are Trin (Rust, Ethereum Foundation-funded) and Nimbus Fluffy (Nim, from Status). A stateless execution client on a phone is useless without something like Portal to ask "give me account 0xabc's storage at slot 0x12" without running a full archive yourself.

Put together: statelessness trims what a node stores per block. History expiry trims what a node stores across history. Portal serves the lookups a trimmed node still needs. Each piece on its own is interesting. Together, they are the reason a smart watch is a credible long-term node target.

The Solo-Staker Case

Every time the state grows past the price point of a reasonable off-the-shelf NVMe, some fraction of solo stakers exit, and their ETH ends up in a pooled operator. That is how centralization accrues: not in one dramatic step, but in a slow consolidation of people who were willing to run their own node at one price point and are not willing at the next.

Vitalik's stated target in "The Verge" is that fully-verifying clients, and staking nodes, should not need more than a few GB of storage. A Raspberry Pi 5 has 8 GB of RAM and takes a microSD. That machine cannot run a 2026 validator. It can run a stateless 2028 validator, if the stack ships.

That is the argument for treating statelessness as the final decentralization fight. Not the flashiest. The last one where the hardware bar genuinely decides who gets to participate.

Who Should Care, and Why

If you run a client, the choice in Glamsterdam is a real implementation budget. EIP-6800 is drafted and tested on Kaustinen. EIP-7864 is drafted and waiting on Poseidon2 audits. Whichever lands, every execution client rebuilds its storage engine against a new tree. That is a one-off cost that pays back for a decade.

If you solo-stake, statelessness is the first upgrade in the post-Merge era that visibly lowers your hardware bill instead of raising it. The right bet is to hold current hardware until Glamsterdam ships, then downsize. Not the other direction.

If you build light-client infra, Trin and Nimbus Fluffy are where to watch. A stateless L1 without a working Portal Network is a feature that only data-center operators can actually run. Portal is what lets the feature reach users.

If you build L2 or rollup infra, the same trees matter. An L2 that wants to prove its state against L1 through a SNARK is easier to build on a STARK-friendly tree than on a polynomial-commitment tree. The Glamsterdam decision shapes the next wave of L2 proof systems.

How the Pieces Fit

The path from here to a node on a phone is three specs, none of which are locked in yet.

01A new state tree: Verkle (EIP-6800, mature, not post-quantum) or binary plus STARK (EIP-7864, draft, post-quantum).
02History expiry: EIP-4444 direction, already rolling out partially since July 2025.
03A light-client data layer: Portal Network, with Trin and Nimbus Fluffy as the launch clients.

The core devs pick one state tree in Glamsterdam. If they pick Verkle, nodes get light in 2026 and 2027, and the tree gets redone once STARK-based proving is production-ready. If they pick binary plus STARK directly, nodes stay heavy a little longer, then make the jump once. Both answers ship statelessness. The question is the number of migrations.

I have watched this debate since 2023 and the mood has flipped twice. For what it is worth, the call I would make in Glamsterdam is binary plus STARK if the Poseidon2 audits land in time, and Verkle if they do not, on the grounds that one state-tree migration per decade is better than two. That is a preference, not a prediction. The decision is not mine.

If either ships in Glamsterdam, and history expiry keeps landing, and Portal's launch clients reach mainnet, the hardware target for a validating Ethereum node drops from a 4 TB NVMe to a phone inside three years.

That is the outcome.

Statelessness: The Final Frontier of Decentralization.