Verkle trees store commitments. The on-chain structure is a root hash, a cryptographic fingerprint for the entire Ethereum state, not the data.
the-ethereum-roadmap-merge-surge-verge
Blog
What Verkle Trees Actually Store on Chain
Verkle trees are the cryptographic engine for Ethereum's 'Verge' upgrade. They don't store user data; they store compact proofs that enable stateless clients, slashing node hardware requirements and unlocking the next wave of scalability.
introduction
THE COMMITMENT
The Misconception: Everyone Thinks Verkle Trees Store Data
Verkle trees store cryptographic commitments to state, not the state data itself, enabling stateless clients.
The state lives off-chain. Full nodes and services like Infura or Alchemy hold the actual data, which clients verify against the Verkle root.
This enables statelessness. Clients like Geth or Reth no longer need a local state database, verifying proofs from the network instead.
Evidence: The current Merkle-Patricia Trie requires ~650MB for a proof. A Verkle proof for the same state is ~150 bytes.
key-trends
VERKLE TREE DATA MODEL
The Scalability Trilemma, Re-framed
Verkle Trees are not just a faster Merkle Tree; they fundamentally change what data must be stored on-chain to prove state.
01
The Problem: Witness Bloat
Merkle proofs require all sibling hashes along a path, leading to massive ~1KB proofs for simple operations. This is the core bottleneck for stateless clients and light nodes.
- Gas Cost: High proof size directly translates to high calldata costs for L2s and bridges.
- Bandwidth: Syncing the chain requires downloading excessive redundant data.
~1KB
Merkle Proof
>90%
Redundant Data
02
The Solution: Vector Commitments
Verkle Trees use polynomial commitments (like KZG) to commit to all children of a node at once. A proof needs only a single ~128-byte witness per node, not all siblings.
- Proof Size: Collapses from kilobytes to ~200 bytes for most operations.
- Stateless Future: Enables practical stateless clients, where validators don't store state.
~200B
Verkle Proof
10x
More Efficient
03
On-Chain Storage: Only Deltas & Roots
The chain stores the compact Verkle root. Full nodes store the tree for execution. The revolutionary shift: clients only need the root and tiny proofs to verify any state.
- State Growth: Historical state can be pruned aggressively; only the current root is sacred.
- Sync Speed: New nodes can sync via proofs of the latest state, not the entire history.
~32B
Root Hash
TB->GB
Storage Shift
04
The Ethereum Pragma Portal Network
Verkle Trees enable the Portal Network vision: a decentralized network of light clients serving state proofs. This breaks the full-node-as-gatekeeper model.
- Decentralization: Low-resource devices can participate in consensus and data serving.
- Resilience: State is distributed across a P2P network, not centralized in infra providers.
P2P
Network
Light Client
First-Class
05
Implications for L2s & Bridges
With tiny state proofs, L2 fault proofs and cross-chain messaging (like LayerZero, Across) become cheaper and faster. Bridges can verify state with minimal on-chain footprint.
- Cost: Drastically reduces the L1 gas cost of verification.
- Security: Enables more frequent and granular state attestations for oracle networks.
-90%
Bridge Cost
Real-Time
Attestations
06
The New Trilemma: Bandwidth, Storage, Decentralization
Verkle Trees reframe the trilemma from 'Scalability, Security, Decentralization' to an engineering trade-off within data availability. The constraint shifts to bandwidth for proofs vs. storage for state.
- Winner: Protocols that minimize on-chain footprint (Rollups, Validiums) gain a structural advantage.
- Loser: Designs requiring full historical state on-chain become obsolete.
Bandwidth
New Bottleneck
Storage
Optimized
deep-dive
THE DATA
Anatomy of a Proof, Not a Database
Verkle Trees store cryptographic commitments, not raw state data, forcing clients to treat the chain as a proof system.
Verkle Trees store commitments. They replace the Merkle Patricia Trie's leaf nodes with vector commitments (like KZG or IPA). Each commitment is a 32-byte hash that cryptographically binds to a batch of state data, such as account balances or storage slots.
Clients verify proofs, not data. A light client queries for a specific state value (e.g., a USDC balance). The network returns a constant-sized proof (~150 bytes) and the requested data, not the entire branch. This is the core shift from a data-fetching to a proof-verification model.
The chain is a state root. The only persistent on-chain data is the single Verkle root in the block header. All other state data exists off-chain with nodes. This architecture mirrors the stateless client vision of Ethereum's roadmap and Celestia's data availability layer.
Evidence: A Verkle proof for an account is ~150 bytes. A comparable Merkle proof in Ethereum today is ~3KB. This 90%+ reduction in proof size is the prerequisite for statelessness and ultra-light clients.
DATA STRUCTURE
Merkle-Patricia vs. Verkle: A Storage Proof Showdown
Comparing the core data stored on-chain and required for state proof generation in Ethereum's legacy and proposed state trees.
| On-Chain Storage & Proof Component | Merkle-Patricia Trie (Current) | Verkle Trie (EIP-6800) | Impact |
|---|---|---|---|
Primary Node Type Stored | Branch & Extension Nodes | Internal & Stem Nodes | Structural Foundation |
Key-Value Pair Storage | Full 256-bit keys & values at leaves | 32-byte stems + 256-bit suffix/commitment | Key Compression |
Proof Witness Size (Per Account) | ~3-4 KB (avg, 6-7 node paths) | < 200 Bytes (avg, 1-2 node paths) | Bandwidth & Gas |
Node Hash Size | 32 Bytes (Keccak-256) | 32 Bytes (Pedersen/Bandersnatch) | Cryptographic Primitives |
Required for Proof: Sibling Hashes | Yes (All siblings per level) | No (Uses vector commitments) | Proof Complexity |
On-Chain Proof Verification Cost | ~45k gas (cold SLOAD) | < 3k gas (estimated) | Stateless Client Viability |
State Root Update Complexity | O(k logâ‚– n) node updates | O(1) commitment update per block | Block Building & Finality |
future-outlook
THE DATA LAYER
The Verge Ecosystem: What Unlocks Next
Verkle trees store cryptographic state proofs, not raw data, enabling stateless clients and exponential scaling.
Verkle trees store commitments. They replace Ethereum's Merkle Patricia Tries with a single 256-bit root that commits to the entire state. This root is the only data full nodes must store permanently.
The tree holds vector commitments. Each node is a polynomial commitment (using IPA/KZG schemes) to its children. This structure allows for constant-sized proofs regardless of state size, unlike Merkle proofs which grow logarithmically.
Clients store only the root. Stateless clients, like those envisioned for Portal Network or Light Clients, verify execution using a single Verkle proof per block. This decouples state growth from node hardware requirements.
This enables stateless validation. Protocols like Ethereum's The Verge and Polygon zkEVM leverage this for trust-minimized light clients. The proof size for a complex Uniswap swap drops from ~1KB to ~150 bytes.
takeaways
VERKLE TREE DATA MODEL
TL;DR for Protocol Architects
Verkle trees are the state commitment structure for stateless Ethereum, fundamentally changing what data clients must store.
01
The Problem: Witness Bloat Breaks Statelessness
Merkle Patricia Tries require massive ~1 MB witnesses for state proofs, making stateless clients impractical. This is the core bottleneck for light client scalability and sync speed.
- Witness Size: ~1 MB per block (MPT) vs. ~150 bytes (Verkle)
- Sync Time: Days to weeks for full nodes today
- Bandwidth Cost: Prohibitively high for light clients
~1 MB
Old Witness
~150 B
Verkle Witness
02
The Solution: Vector Commitments & 256-Way Trees
Verkle trees use KZG polynomial commitments to commit to 256 values per node, collapsing proof paths. They store the same core state data (account balances, code, storage slots) but with a radically efficient proof system.
- Branching Factor: 256 children per node vs. 16 in MPT
- Core Tech: KZG commitments (or IPA) for constant-size proofs
- On-Chain Data: Still the state root hash, but the proving data structure is off-chain
256x
Branch Factor
O(1)
Proof Size
03
What's Actually Stored On-Chain? Just the Root.
The chain itself only stores the single 32-byte Verkle root in the block header. All other data (tree nodes, values) is stored off-chain by full nodes and builders. This enables stateless validation where clients only need the root and a tiny witness.
- Block Header: One 32-byte root commitment
- Client Requirement: Root + ~150 byte witness for validation
- Node Role Shift: Full nodes become data availability providers
32 B
On-Chain Root
~150 B
Client Needs
04
The Architectural Pivot: Enabling Stateless Everything
This data model unlocks stateless clients, 1-of-N trust assumptions for bridges like LayerZero, and ultra-lightweight rollup provers. It's foundational for the Ethereum roadmap (The Verge).
- Light Clients: Feasible on mobile devices
- Bridges/Rollups: Cheap, verifiable state proofs
- Network Health: Reduces sync time to hours, not weeks
1-of-N
Trust Model
Hours
Sync Time
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall