LibraryScaling2018Design paperCorpus record
Verkle Trees
Verkle trees. John Kuszmaul.
Verkle trees use vector commitments so a proof of many leaves shares one commitment path. The proof is shorter, at the cost of a polynomial-commitment assumption.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
A stateless-client pitch should say whether the proof is a Merkle sibling list or a Verkle opening, and what setup that requires.
The five-minute read
The defect
A Merkle proof of a piece of state grows with the width of the tree. A stateless client that needs many proofs spends its bandwidth on sibling hashes.
The rule
Verkle trees use vector commitments so a proof of many leaves shares one commitment path. The proof is shorter, at the cost of a polynomial-commitment assumption.
How it is put together
Width can be large because the proof does not carry every sibling. The commitment is not a simple hash. Stateless validation is the reason to care.
Where the claim stops
The thesis is not an Ethereum specification.
One action, walked through
- Commit to a wide node with a vector commitment.
- A proof shows the path of commitments down to the leaf.
- The verifier checks openings rather than hashing siblings.
- How wide is a node?
The argument, unpacked
Why it is still on the desk
A stateless-client pitch should say whether the proof is a Merkle sibling list or a Verkle opening, and what setup that requires.
After the text
Ethereum research adopted Verkle trees as a proposed state structure. Shipping is a later decision.
What has to be true
- The thesis is not an Ethereum specification.
- Shorter proofs do not remove the need for the data to exist.
- The cryptographic assumption is stronger than a hash.
What happened after the paper
Ethereum research adopted Verkle trees as a proposed state structure. Shipping is a later decision.
What to check before you use the idea
- How wide is a node?
- What commitment opens a child?
- Is there a setup, and who ran it?
Terms
- Vector commitment
- A commitment to a list that can open one index.
- Stateless client
- A verifier that checks a block from a proof, without storing all state.
The problem the paper names
A Merkle proof of a piece of state grows with the width of the tree. A stateless client that needs many proofs spends its bandwidth on sibling hashes.
What the design proposes
- Width can be large because the proof does not carry every sibling.
- The commitment is not a simple hash.
- Stateless validation is the reason to care.
How the mechanism is specified
- Commit to a wide node with a vector commitment.
- A proof shows the path of commitments down to the leaf.
- The verifier checks openings rather than hashing siblings.
What this page does not treat as proven
- The thesis is not an Ethereum specification.
- Shorter proofs do not remove the need for the data to exist.
- The cryptographic assumption is stronger than a hash.
Why a venture studio still reads it
A stateless-client pitch should say whether the proof is a Merkle sibling list or a Verkle opening, and what setup that requires.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.