Sparse Merkle Tree
zkProver's data is stored in the form of a special _sparse Merkle tree_ (SMT), which is a tree that combines the concept of a Merkle tree and that of a Patricia
zkProver's data is stored in the form of a special sparse Merkle tree (SMT), which is a tree that combines the concept of a Merkle tree and that of a Patricia trie. The design is based on how the sparse Merkle trees are constructed and how they store keys and values.
The content of this document is rather elementary. Experienced developers can fast-forward to later sections and only refer back as the need arises.
A typical Merkle tree has leaves, branches and a root. A leaf is a node with no child-nodes, while a branch is a node with child-nodes. The root is therefore the node with no parent-node.
See the below figure for an example of how a hash function is used to create a Merkle tree recording eight values;

Firstly, each leaf is nothing but the hash value of a particular value , where is an element of the index-set .
Secondly, the branch nodes are computed as follows;
Thirdly, the root is computed as .
Leaves that share a parent-node are called siblings. The same terminology applies to branches. For example, and are sibling branches because they are branches of the same parent, . Similarly, and are sibling branches.
Keys and navigating a Merkle tree
Note the bits used to label edges in figure above. The strings of these bits are called keys, and they indicated where a node is located in a Merkle tree. Since keys uniquely locate nodes, they are used to navigate from the root to the leaves, and backwards.
Suppose one is given the key-value pair , where the key is .
In order to locate the key-value pair in the Merkle depicted in the figure above, the key is read bit-by-bit from the right-most bit to the left-most bit. While traversing the tree from the root downwards,
-
a zero-key-bit "" means "follow the edge going to the left",
-
a key-bit "" means "follow the edge going to the right".
Since , as follows:
- Read the least-significant bit of , which is , hence traverse the tree to the left, and reach .
- Then read the second significant key-bit, which is "" in this case. So take the edge going to the right, reaching .
- Again, read the next key-bit, which is "", hence follow the edge going to the right, reaching the leaf .
Since is a leaf and not a branch, and the navigation was correctly done with respect to the given key , the must be the leaf storing the value .
One can similarly climb the tree, going in the reverse direction, by using the key-bits of the given key in the reverse order. That is, starting with the last key-bit used to reach the leaf and ending with the least-significant bit of the key.
The tree-address of the value , herein refers to the position of the leaf , denoted by the key-bits used to reach but in the reverse order.
In the above example, the tree-address of is 011.
Merkle proof example
Merkle trees can be used as commitment schemes. And here is an example that follows the (key,value)-pair approach used in the zkProver. Consider the Merkle tree shown in the figure above.
If the prover has committed to a value by appending a new leaf to the Merkle tree as depicted in the above figure, he must then avail the following information, to enable verification of his claim;
- The Merkle root, denoted by ,
- The value , and
- The siblings; , and .
Instead of searching through all hash values stored in the tree, the verifier uses only a few hash values of relevant siblings. That is, three siblings in this case.
The verifier then checks the prover's claim by computing the Merkle root as follows;
-
He computes , which is the hash of the value .
-
Then uses the sibling to compute , which should be the same as the branch node .
-
Next, he computes , corresponding to the branch node .
-
Now, uses .
The Merkle proof is concluded by checking whether equals to the publicly known root .
The symbol tilde denoted , is used throughout the document to indicate that the computed value, , still needs to be checked, or tested to be true.
Last updated on
Simple Smt
Understanding the finer details of how the Storage state machine operates requires a good grasp of the way the zkProver's sparse Merkle trees (SMTs) are constru
Architecture
As an Ethereum Layer 2 scaling solution, Polygon zkEVM gathers transactions into batches after executing them. Aggregated batches are then dispatched to Ethereu