Everything you want to know about Ethereum Stateless

Source: Dev.to

Introduction

To verify blocks today, running a node requires a 2 TB+ NVMe SSD and significant bandwidth. This hardware barrier forces centralisation, pushing users to rely on trusted third‑parties like Infura or Alchemy instead of verifying the chain themselves.

The Constraints: Latency & Bandwidth

Why can’t we just send the data needed to verify a block?

To verify a block statelessly, a node needs specific account values (balances, nonces, code) plus a cryptographic proof that these values are correct. This package is called the Witness.

The problem is network propagation. Blocks must spread across the global P2P network in seconds. With today’s mathematics, the Witness would be 10–20 MB per block. At that size, propagation slows down, stale‑block rates increase, and only massive data‑centres can keep up.

Goal: shrink the proof from ~20 MB to < 100 KB per block.

The Architecture of Statelessness

Statelessness splits the network into two distinct classes of nodes:

The Bottleneck: Merkle‑Patricia Tries

Ethereum currently uses Merkle‑Patricia Tries (Radix‑16). In this structure each node has 16 children. To prove that one specific child value exists, you must provide the hashes of all 15 siblings at every level of the tree’s depth.

The Math

Size ≈ 15 × Depth × 32 bytes

The size scales linearly. As the state grows, the tree gets deeper and the proof gets bigger. Today this results in roughly 3–4 KB per account. In a busy block consuming 30 M gas, the total witness data exceeds the bandwidth budget of the P2P network.

The Fix: Verkle Trees & Vector Commitments

Ethereum is moving to Verkle Trees.

In a Verkle tree each node has 256 children instead of 16. Proving one child among 256 would naïvely require sending 255 sibling hashes – a massive amount of data.

The Solution: Polynomials

Instead of hashing the siblings, we treat the 256 children as coefficients v of a polynomial P(x):

[ P(x) = v_0 + v_1 x + v_2 x^2 + \dots + v_{255} x^{255} ]

We then commit to the entire polynomial using KZG commitments.

The KZG Magic Formula 🔮

The commitment C is a single curve point derived from a secret value s:

[ C = G \cdot P(s) ]

To prove a specific child value y at index z, the prover computes a quotient polynomial Q(x):

[ Q(x) = \frac{P(x) - y}{x - z} ]

Why this works:
If the value at index z truly equals y, then subtracting y from the polynomial makes it perfectly divisible by ((x - z)). If the value were different, a non‑zero remainder would remain, and (Q(x)) would not be a valid polynomial. By providing the commitment to (Q(x)), the prover demonstrates that the division was clean and the data is correct.

The proof is simply the commitment to this quotient polynomial Q(x). It is a constant 48 bytes, regardless of whether the tree is wide or narrow.

The Impact: Bandwidth Saved

This reduces the stateless block witness from ≈ 10 MB down to ≈ 200 KB.

The Engineering Challenges

1. The Trade‑off: Trusted Setup

KZG commitments require a Structured Reference String (SRS) – a set of parameters generated using a secret value s.

Risk: If an attacker learns s, they can forge proofs (P’(s) = P(s)) and trick the network into accepting bad data.

Defense: The “Powers of Tau” ceremony. Over 140 000 participants contributed entropy to generate these parameters. As long as one participant destroyed their “toxic waste” (the secret randomness), the system remains mathematically secure.

2. The Concurrency Trap (Race Condition)

Who should generate these proofs?

Ethereum has chosen Weak Statelessness because of a fundamental distributed‑systems problem: the race condition. If users had to make proofs themselves, their transactions would often fail when the network is busy. Placing the burden on Block Builders (Proposers) gives them the server capacity to regenerate proofs instantly.

Future‑Proofing: State Expiry

Another piece of the puzzle is State Expiry (EIP‑7736). Statelessness solves the verification problem, but the underlying database (stored by proposers) still grows endlessly.

Mechanism: Epoch‑based tree rotation.
Logic: If a leaf (account) is not accessed for ~1 year, it is dropped from the active tree.
Restoration: To use that account again, the user must provide a proof from the archive to reactivate it.

Conclusion: The “Verge” Vision

All of this math serves a singular vision in Vitalik’s roadmap, known as “The Verge.” The goal is to make the chain so lightweight that verifying Ethereum no longer requires trusting centralized providers like Alchemy or Infura.

Summary & Specs

The roadmap continues, but the mathematics and engineering outlined above lay the foundation for a truly decentralized, lightweight Ethereum.

KZG Polynomials

KZG Polynomials compress 256 siblings into 48 bytes.

Network

Reduces bandwidth overhead by ~99 %.

UX

“Weak” statelessness prevents transaction failures.

Target

The “Hegota” Upgrade (H2 2026).

Related EIPs

• EIP‑6800 (Verkle Trees)
• EIP‑4762 (Gas Costs)

Top Resources

• Vitalik Buterin: “Verkle Trees” – Link
• Dankrad Feist: “Verkle Trie for Eth1 State” – Link