The Verkle tree is a commitment scheme that works similarly to the Merkle tree, but the witnesses are much smaller. It works by replacing the hash values in the Merkle tree with vector promises, which makes wider branching factors more effective.

*Thanks to Kevaundray Wedderburn for the feedback on the post.*

Table of Contents

## Overview

For details on how the verkle tree works, see:

The purpose of this article is to explain the specific layout Draft verkle tree EIPIt is aimed at client developers who want to implement a Verkle tree and look for an introduction before delving into EIP.

Verkle trees have made many changes to the tree structure. The most significant changes are:

- Switch from 20-byte key to 32-byte key (not to be confused with 32-byte address, this is a separate change);
- Attempt to merge account and storage; finally
- The verkle trie itself is introduced, which uses vector promises instead of hashing.

As the vector commitment scheme of the verkle tree, we use *Pedersen Commitment*. Pedersen promises based on elliptic curves.For an introduction to Pedersen promises and how to use inner product parameters to use them as polynomial or vector promises, see here.

The curve we use is Bandar SnackThis curve was chosen because it is high-performance, and also because it will allow the efficient SNARK in BLS12_381 to reason about verkle trees in the future. This is useful for summarizing and allowing upgrades. Once feasible, all witnesses can be compressed into one SNARK without further committing updates.

Bandersnatch’s curve order/scalar field size is $p = 131089687937815476198619351270464914593091558934405702517864033067296876728025$3. Therefore, we can only safely submit a bit string of up to 252 bits, otherwise the field will overflow. We chose a branching factor (width) of 256 for the verkle tree, which means that each commitment can submit up to 256 252-bit values (or to be precise, up to an integer of $p-1$). We write it as $mathrm{Commit}(v_0, v_1, …, v_{255})$ to submit to a list $v$ of length 256.

## The layout of the verkle tree

One of the design goals of the Verkle tree EIP is to make access to adjacent locations (such as storage with almost the same address or adjacent code blocks) inexpensive.In order to do this, a key consists of a *Dry* 31 bytes and one *suffix* 1 byte, 32 bytes in total. The key scheme is designed so that “closed” storage locations are mapped to the same stem and different suffixes.For details, please see Ecological Park Draft.

The verkle tree itself consists of two types of nodes:

*Expansion node*, Represents 256 values with the same stem but different suffixes*Internal node*, There are up to 256 child nodes, which can be other internal nodes or extended nodes.

The promise to the extended node is the promise to the 4-element vector; the remaining positions will be 0. It is $C = mathrm{Commit}(1, mathrm{stem}, C_1, C_2)$

C₁ and C₂ are the other two promises, they promise all values that have a value equal to $mathrm{stem}$. The reason we need to promise is that the value has 32 bytes, but we can only store 252 bits per field element. Therefore, a single promise is not enough to store 256 values. Therefore, C₁ stores the values with suffixes 0 to 127, and C₂ stores 128 to 255, where the value is divided into two parts to fit the field size (we will talk about it later).

The extension together with the commitments C₁ and C₂ is called the “extension and suffix tree” (EaS for short).

**figure 1** *Means to traverse the verkle tree to obtain the key 0xfe0002abcd..ff04: The path passes through 3 internal nodes, each node has 256 child nodes (254, 0, 2), and an extended node represents abcd..ff And two suffix tree promises, including value 04, v₄. Please note that $texttt{stem}$ is actually the first 31 bytes of the key, including the path through the internal node.*

### Commitment to value leaf nodes

Each extension and suffix tree node contains 256 values. Because a value is 256 bits wide, and we can only safely store 252 bits in a field element, if we simply try to store a value in a field element, four bits will be lost.

To circumvent this problem, we choose to divide the 256 values into two groups, each with 128 values. Each 32-byte value in the group is split into two 16-byte values. So a value $v_i in mathbb{B}*{32}$ becomes $v^text{(lower)}*{i} in mathbb{B}*{16}$ and $v^text{(top)}*{i} in mathbb{B}*{16}$ makes $v^text{(lower)}*{i} ++ v^text{(top)}_{i} = v_i$.

A “leaf tag” is added to $v^text{(lower)}*{i}$ is used to distinguish between leaves that have never been visited and leaves that have been covered by 0. Never remove any value from the Verkle treeThis is required for the upcoming state expiration plan. The tag is set at the 129th position, which is $v^text{(lower,modified)}*{i} = v^text{(below)}

*{i} + 2^{128}$ If you have visited vᵢ before, and $v^text{(lower,modified)}*{i} = 0$ if vᵢ has never been visited.

Then define the two commitments C₁ and C₂ as

### Commitment to expand nodes

The commitment to the expansion node consists of an “expansion token”, which is just the number 1, two subtree commitments C₁ and C₂, and *Dry* The key that caused this expansion node.

$C = mathrm{Commit}(1, mathrm{stem}, C_1, C_2)$

Unlike the expanded node in the Merkle-Patricia tree, it only contains the part of the key that connects the parent internal node to the child internal node, and the stem covers the entire key to that point. This is because the Verkle tree was designed with stateless proofs in mind: if a new key is inserted to “split” the expansion into two parts, there is no need to update the old sibling, which allows the use of smaller proofs.

### Commitment of internal nodes

Internal nodes have a simpler calculation method for their commitments: nodes are treated as a vector of 256 values, which are the root commitments (field representation) of each of their 256 subtrees. The promise of the empty subtree is $0$.If the subtree is not empty, the promise of the internal node is

$C = mathrm{Commit}(C_0, C_1, …, C_{255})$

Where Cᵢ is the child of the internal node, if the child is empty, it is 0.

## Insert into the tree

Figure 2 illustrates the process of inserting a new value into the tree, which becomes interesting when the stem collides over a few initial bytes.

**figure 2** *The value v₁₉₂ is inserted at the position 0000010000...0000 In a verkle tree containing only the position value v₁₂₇ 0000000000...0000. Because the stem is different at the third byte, add two internal nodes up to different bytes. Then insert another “extension and suffix” tree, which has a complete 31-byte stem. The initial node remains unchanged, and the value of $C^2_0$ is the same as the value of $C^0_0$ before insertion.*

## Shallower tree, smaller proof

The Verkle tree structure makes the tree shallower, thereby reducing the amount of data stored. However, its true power comes from the ability to produce smaller evidence, the witness. This will be explained in the next article.