Verkle Trees Explained: Ethereum's Path to Stateless Clients

Verkle trees are a proposed change to Ethereum’s state data structure. They matter because validating a block currently assumes that a node has a large local copy of Ethereum state, while a stateless client would validate the same block from a compact witness supplied with it. This guide explains what a Verkle tree is, why Ethereum needs one, how it differs from a Merkle Patricia Trie, and what the transition would mean for node operators and application developers.

The Ethereum project is not replacing transaction execution with a different virtual machine through Verkle trees. The change is to how state is committed to and proved. The execution rules still determine the next state; the tree makes the relevant state easier to authenticate without sending an entire database to every validator.

What Are Verkle Trees?

A Verkle tree is a cryptographic commitment tree with a wide branching factor. Like a Merkle tree, it produces one root commitment for many key-value pairs. A proof can show that a value belongs to that committed set, or that a value is absent, without requiring the verifier to download every other value.

The important difference is how internal nodes commit to their children. A conventional binary or hexary Merkle tree hashes child nodes together. A Verkle tree uses a vector commitment, which can commit to many positions while keeping an opening proof relatively small. Ethereum’s EIP-6800 specification defines a state-tree design using high-width nodes and a commitment scheme based on the Bandersnatch curve.

The name combines “vector commitment” and “Merkle.” It describes the proof properties rather than a single implementation library. The tree still has paths, leaves, roots, updates, and proofs; vector commitments change the size and shape of the evidence a client needs to verify those paths.

Why Does Ethereum Need Them?

Ethereum clients use a state root in every block header. That root commits to accounts, contract code references, balances, nonces, and contract storage. To verify a block, a client executes the block’s transactions, reads the state needed by those transactions, applies the changes, and checks that its resulting root matches the proposer-provided root.

Today, that process is based on a hexary Merkle Patricia Trie. The Ethereum Patricia Merkle Trie documentation describes the state trie and the separate storage tries used by contracts. The structure is secure, but proofs contain many hashed intermediate nodes. As state grows, keeping a complete and recent database becomes a significant disk, I/O, and synchronization requirement for full nodes.

The alternative is a stateless client. It does not keep the complete state database locally. Instead, a block or a block-related network message carries:

• The account and storage values needed to execute the transactions.
• A witness containing the commitments or proof data that connects those values to the previous state root.
• The block and transaction information needed to replay execution.

The client checks the witness, executes the transactions, and verifies the new root. It still verifies the same state transition; it simply obtains the relevant state on demand. For this model to work on a peer-to-peer network, witnesses must be small enough to propagate and process within a block slot.

EIP-6800 gives the scale of the problem motivating the change: an account access in the current tree averages close to 3 kB of witness data, while a Verkle design targets roughly 200 bytes per account access in its stated model. Those are design estimates rather than a promise about every future block, but they show why reducing proof overhead is central to statelessness.

How Does a Verkle State Tree Work?

At a high level, the state transition still follows the familiar sequence:

1. A client receives a block and its transactions.
2. The execution engine identifies the account and storage keys it must read or update.
3. A state provider supplies the corresponding values and a witness.
4. The client verifies the witness against the parent state commitment.
5. The client executes the transactions and applies the writes.
6. The resulting commitment is compared with the state root in the new block.

The proof is not a replacement for execution. A valid witness can establish that a starting value belongs to the committed state, but it cannot make invalid EVM execution valid. Execution rules, transaction signatures, consensus checks, and state-transition logic remain separate responsibilities.

Merkle Patricia Tries and Verkle Trees Compared

The comparison is about state commitments, not security versus insecurity. Both structures can provide cryptographic integrity when implemented correctly. Verkle trees aim to make the proof bandwidth and client-storage trade-off more suitable for a network where not every validator must retain all state locally.

Key Components and Concepts

Vector commitments

A vector commitment binds an ordered list of values to a short commitment. A prover can later open one or more positions and give a proof that the supplied values occupy those positions in the committed vector. The verifier does not need every unrelated child. In Ethereum’s proposed design, the commitment scheme is chosen so that many state accesses can share parts of a proof.

State keys and tree paths

Ethereum needs a deterministic mapping from an account address, contract code, and storage slot to positions in the tree. A state-tree migration therefore involves more than copying leaves into a new database. The protocol must define the key encoding, how account fields are represented, how contract storage is embedded, and how updates preserve the commitment expected by every client.

Witnesses

A witness is the compact package of state fragments and cryptographic evidence needed to verify a particular execution. A witness may prove both present values and, depending on the operation, that a relevant key is absent. The block producer or a supporting network service can assemble it; the receiving client checks it rather than trusting the producer’s claim.

Witness size depends on access patterns. Ten transactions that repeatedly touch the same state may share proof information, while transactions that touch unrelated accounts and storage slots require more openings. “Small witnesses” therefore means a substantially better scaling property, not a fixed byte count for every block.

State transition and migration

The transition cannot simply change the root format in one client release while leaving existing state semantics undefined. A protocol upgrade needs a migration strategy, compatibility rules for old and new representations, updated gas assumptions, and client implementations that agree on the same root. EIP-6800 describes a staged approach in which a new Verkle state tree is introduced alongside the existing tree before a later phase relies on it exclusively.

Real-World Use Cases

Lower-resource full and partial nodes

Stateless validation can reduce the need for every validating process to keep the complete active state locally. That could make participation more practical on machines with less disk or improve the number of independent validation processes an operator can run. It does not eliminate all storage: archival nodes, state providers, block history, databases, caches, and recovery copies remain useful.

More flexible validator infrastructure

When state access can be supplied through witnesses, node software can separate execution from state storage more cleanly. A validator may use a local cache, a remote state service, or a combination, depending on latency and availability requirements. This flexibility creates new operational dependencies, so a production operator would need redundant state providers and clear behavior for missing or invalid witnesses.

Scaling Ethereum applications

Verkle trees do not directly increase an application’s transaction throughput or turn a rollup into a different security model. Their contribution is at the base-layer state-access bottleneck. Smaller witnesses could make it easier for nodes and light clients to verify blocks, which supports Ethereum’s decentralization goals as applications and rollups increase demand for state reads.

Rollups still have separate execution, sequencing, settlement, and data-availability concerns. The relationship between those layers is covered in our Layer 2 scaling solutions guide, while the wider separation of blockchain responsibilities is explained in modular blockchain architecture.

Getting Started: Inspecting the Current State Model

Verkle trees are a protocol-development topic, not a feature that application developers can enable on Ethereum mainnet with a command. You can still inspect the current state-root interface and see the boundary that a future state-tree change must preserve.

The following JSON-RPC request asks an Ethereum node for a block by number. The response includes stateRoot, the commitment that the client calculates after executing the block:

RPC_URL="https://your-ethereum-rpc.example"

curl -sS "$RPC_URL" \
  -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}' \
  | jq '{number, hash, stateRoot}'

For a contract storage read, eth_getProof can return a value together with proof data when the selected node supports the method:

curl -sS "$RPC_URL" \
  -H 'content-type: application/json' \
  --data '{
    "jsonrpc":"2.0",
    "method":"eth_getProof",
    "params":[
      "0x0000000000000000000000000000000000000000",
      ["0x0"],
      "latest"
    ],
    "id":2
  }' | jq .

These calls expose the current account-proof interface; they do not create a Verkle proof. For implementation work, use a client or research repository that explicitly documents its tree format, commitment library, test vectors, and network compatibility. Do not point a production node at an experimental Verkle implementation or assume that a proof from one design can be verified by another.

Operators evaluating future stateless-client designs should measure:

• Witness assembly and verification latency under realistic access patterns.
• Bandwidth and cache hit rates for state providers.
• Recovery behavior when a provider is unavailable or returns malformed data.
• Consistency between independently implemented execution clients.
• Storage requirements for local caches, historical state, and archival recovery.

Common Misconceptions

“Verkle trees make Ethereum stateless immediately.”

No. They are a prerequisite for practical stateless clients, not the complete client architecture. Protocol changes, witness distribution, state migration, networking, gas accounting, and client support must all be coordinated before validators can rely on the new model.

“A Verkle tree stores less information.”

The tree changes how information is committed to and proved. It does not make account balances, contract storage, or execution results disappear. Some nodes will still store the full state for performance, indexing, archival, or service purposes; other clients may use witnesses and partial state.

“Smaller witnesses remove all node hardware requirements.”

They reduce one important requirement: carrying a large local state database for every validation path. Nodes still need CPU for execution, bandwidth for blocks and witnesses, reliable storage for their chosen retention policy, and safeguards against unavailable or malicious state providers.

“Verkle trees are the same as zero-knowledge proofs.”

Both use advanced cryptography, but they solve different problems. A Verkle proof authenticates values relative to a committed data structure. A zero-knowledge proof can establish properties of a computation while hiding information, depending on its construction. They can be used in related systems, but one is not a substitute for the other.

Related Articles

• Data availability and sampling design
• Modular blockchain architecture
• Layer 2 scaling solutions explained
• Ethereum gas optimization systems

Verkle trees are best understood as an infrastructure change aimed at making Ethereum validation more flexible as state grows. Their success depends on the complete system around the tree: deterministic state encoding, compact and safe witnesses, reliable distribution, compatible clients, and an operational model that does not turn remote state access into a single point of failure.

Last updated: 2026-09-13.