Hash chiplet

Miden VM "offloads" all hash-related computations to a separate hash processor. This chiplet supports executing the Rescue Prime Optimized hash function (or rather a specific instantiation of it) in the following settings:

A single permutation of Rescue Prime Optimized.
A simple 2-to-1 hash.
A linear hash of $n$ field elements.
Merkle path verification.
Merkle root update.

The chiplet can be thought of as having a small instruction set of $11$ instructions. These instructions are listed below, and examples of how these instructions are used by the chiplet are described in the following sections.

Instruction	Description
`HR`	Executes a single round of the VM's native hash function. All cycles which are not one less than a multiple of $8$ execute this instruction. That is, the chiplet executes this instruction on cycles $0, 1, 2, 3, 4, 5, 6$ , but not $7$ , and then again, $8, 9, 10, 11, 12, 13, 14$ , but not $15$ etc.
`BP`	Initiates computation of a single permutation, a 2-to-1 hash, or a linear hash of many elements. This instruction can be executed only on cycles which are multiples of $8$ , and it can also be executed concurrently with an `HR` instruction.
`MP`	Initiates Merkle path verification computation. This instruction can be executed only on cycles which are multiples of $8$ , and it can also be executed concurrently with an `HR` instruction.
`MV`	Initiates Merkle path verification for the "old" node value during Merkle root update computation. This instruction can be executed only on cycles which are multiples of $8$ , and it can also be executed concurrently with an `HR` instruction.
`MU`	Initiates Merkle path verification for the "new" node value during Merkle root update computation. This instruction can be executed only on cycles which are multiples of $8$ , and it can also be executed concurrently with an `HR` instruction.
`HOUT`	Returns the result of the currently running computation. This instruction can be executed only on cycles which are one less than a multiple of $8$ (e.g. $7$ , $15$ etc.).
`SOUT`	Returns the whole hasher state. This instruction can be executed only on cycles which are one less than a multiple of $8$ , and only if the computation was started using `BP` instruction.
`ABP`	Absorbs a new set of elements into the hasher state when computing a linear hash of many elements. This instruction can be executed only on cycles which are one less than a multiple of $8$ , and only if the computation was started using `BP` instruction.
`MPA`	Absorbs the next Merkle path node into the hasher state during Merkle path verification computation. This instruction can be executed only on cycles which are one less than a multiple of $8$ , and only if the computation was started using `MP` instruction.
`MVA`	Absorbs the next Merkle path node into the hasher state during Merkle path verification for the "old" node value during Merkle root update computation. This instruction can be executed only on cycles which are one less than a multiple of $8$ , and only if the computation was started using `MV` instruction.
`MUA`	Absorbs the next Merkle path node into the hasher state during Merkle path verification for the "new" node value during Merkle root update computation. This instruction can be executed only on cycles which are one less than a multiple of $8$ , and only if the computation was started using `Mu` instruction.

Chiplet trace

Execution trace table of the chiplet consists of $16$ trace columns and $3$ periodic columns. The structure of the table is such that a single permutation of the hash function can be computed using $8$ table rows. The layout of the table is illustrated below.

hash_execution_trace

The meaning of the columns is as follows:

Three periodic columns $k_{0}$ , $k_{1}$ , and $k_{2}$ are used to help select the instruction executed at a given row. All of these columns contain patterns which repeat every $8$ rows. For $k_{0}$ the pattern is $7$ zeros followed by $1$ one, helping us identify the last row in the cycle. For $k_{1}$ the pattern is $6$ zeros, $1$ one, and $1$ zero, which can be used to identify the second-to-last row in a cycle. For $k_{2}$ the pattern is $1$ one followed by $7$ zeros, which can identify the first row in the cycle.
Three selector columns $s_{0}$ , $s_{1}$ , and $s_{2}$ . These columns can contain only binary values (ones or zeros), and they are also used to help select the instruction to execute at a given row.
Twelve hasher state columns $h_{0}, ..., h_{11}$ . These columns are used to hold the hasher state for each round of the hash function permutation. The state is laid out as follows:
- The first four columns ( $h_{0}, ..., h_{3}$ ) are reserved for capacity elements of the state. When the state is initialized for hash computations, $h_{0}$ should be set to $0$ if the number of elements to be hashed is a multiple of the rate width ( $8$ ). Otherwise, $h_{0}$ should be set to $1$ . $h_{1}$ should be set to the domain value if a domain has been provided (as in the case of control block hashing). All other capacity elements should be set to $0$ 's.
- The next eight columns ( $h_{4}, ..., h_{11}$ ) are reserved for the rate elements of the state. These are used to absorb the values to be hashed. Once the permutation is complete, hash output is located in the first four rate columns ( $h_{4}, ..., h_{7}$ ).
One index column $i$ . This column is used to help with Merkle path verification and Merkle root update computations.

In addition to the columns described above, the chiplet relies on two running product columns which are used to facilitate multiset checks (similar to the ones described here). These columns are:

$b_{c hi p}$ - which is used to tie the chiplet table with the main VM's stack and decoder. That is, values representing inputs consumed by the chiplet and outputs produced by the chiplet are multiplied into $b_{c hi p}$ , while the main VM stack (or decoder) divides them out of $b_{c hi p}$ . Thus, if the sets of inputs and outputs between the main VM stack and hash chiplet are the same, the value of $b_{c hi p}$ should be equal to $1$ at the start and the end of the execution trace.
$p_{1}$ - which is used to keep track of the sibling table used for Merkle root update computations. Specifically, when a root for the old leaf value is computed, we add an entry for all sibling nodes to the table (i.e., we multiply $p_{1}$ by the values representing these entries). When the root for the new leaf value is computed, we remove the entries for the nodes from the table (i.e., we divide $p_{1}$ by the value representing these entries). Thus, if both computations used the same set of sibling nodes (in the same order), the sibling table should be empty by the time Merkle root update procedure completes (i.e., the value of $p_{1}$ would be $1$ ).

Instruction flags

As mentioned above, chiplet instructions are encoded using a combination of periodic and selector columns. These columns can be used to compute a binary flag for each instruction. Thus, when a flag for a given instruction is set to $1$ , the chiplet executes this instruction. Formulas for computing instruction flags are listed below.

Flag	Value	Notes
$f_{r p r}$	$1 - k_{0}$	Set to $1$ on the first $7$ steps of every $8$ -step cycle.
$f_{b p}$	$k_{2} \cdot s_{0} \cdot (1 - s_{1}) \cdot (1 - s_{2})$	Set to $1$ when selector flags are $(1, 0, 0)$ on rows which are multiples of $8$ .
$f_{m p}$	$k_{2} \cdot s_{0} \cdot (1 - s_{1}) \cdot s_{2}$	Set to $1$ when selector flags are $(1, 0, 1)$ on rows which are multiples of $8$ .
$f_{m v}$	$k_{2} \cdot s_{0} \cdot s_{1} \cdot (1 - s_{2})$	Set to $1$ when selector flags are $(1, 1, 0)$ on rows which are multiples of $8$ .
$f_{m u}$	$k_{2} \cdot s_{0} \cdot s_{1} \cdot s_{2}$	Set to $1$ when selector flags are $(1, 1, 1)$ on rows which are multiples of $8$ .
$f_{h o u t}$	$k_{0} \cdot (1 - s_{0}) \cdot (1 - s_{1}) \cdot (1 - s_{2})$	Set to $1$ when selector flags are $(0, 0, 0)$ on rows which are $1$ less than a multiple of $8$ .
$f_{so u t}$	$k_{0} \cdot (1 - s_{0}) \cdot (1 - s_{1}) \cdot s_{2}$	Set to $1$ when selector flags are $(0, 0, 1)$ on rows which are $1$ less than a multiple of $8$ .
$f_{ab p}$	$k_{0} \cdot s_{0} \cdot (1 - s_{1}) \cdot (1 - s_{2})$	Set to $1$ when selector flags are $(1, 0, 0)$ on rows which are $1$ less than a multiple of $8$ .
$f_{m p a}$	$k_{0} \cdot s_{0} \cdot (1 - s_{1}) \cdot s_{2}$	Set to $1$ when selector flags are $(1, 0, 1)$ on rows which are $1$ less than a multiple of $8$ .
$f_{m v a}$	$k_{0} \cdot s_{0} \cdot s_{1} \cdot (1 - s_{2})$	Set to $1$ when selector flags are $(1, 1, 0)$ on rows which are $1$ less than a multiple of $8$ .
$f_{m u a}$	$k_{0} \cdot s_{0} \cdot s_{1} \cdot s_{2}$	Set to $1$ when selector flags are $(1, 1, 1)$ on rows which are $1$ less than a multiple of $8$ .

A few additional notes about flag values:

With the exception of $f_{r p r}$ , all flags are mutually exclusive. That is, if one flag is set to $1$ , all other flats are set to $0$ .
With the exception of $f_{r p r}$ , computing flag values involves $3$ multiplications, and thus the degree of these flags is $4$ .
We can also define a flag $f_{o u t} = k_{0} \cdot (1 - s_{0}) \cdot (1 - s_{1})$ . This flag will be set to $1$ when either $f_{h o u t} = 1$ or $f_{so u t} = 1$ in the current row.
We can define a flag $f_{o u t}^{'} = k_{1} \cdot (1 - s_{0}^{'}) \cdot (1 - s_{1}^{'})$ . This flag will be set to $1$ when either $f_{h o u t} = 1$ or $f_{so u t} = 1$ in the next row.

We also impose the following restrictions on how values in selector columns can be updated:

Values in columns $s_{1}$ and $s_{2}$ must be copied over from one row to the next, unless $f_{o u t} = 1$ or $f_{o u t}^{'} = 1$ indicating the hout or sout flag is set for the current or the next row.
Value in $s_{0}$ must be set to $1$ if $f_{o u t} = 1$ for the previous row, and to $0$ if any of the flags $f_{ab p}$ , $f_{m p a}$ , $f_{m v a}$ , or $f_{m u a}$ are set to $1$ for the previous row.

The above rules ensure that we must finish one computation before starting another, and we can't change the type of the computation before the computation is finished.

Computation examples

Single permutation

Computing a single permutation of Rescue Prime Optimized hash function involves the following steps:

Initialize hasher state with $12$ field elements.
Apply Rescue Prime Optimized permutation.
Return the entire hasher state as output.

The chiplet accomplishes the above by executing the following instructions:

[BP, HR]                 // init state and execute a hash round (concurrently)
HR HR HR HR HR HR        // execute 6 more hash rounds
SOUT                     // return the entire state as output

Execution trace for this computation would look as illustrated below.

hash_1_permutation_trace

In the above ${a_{0}, ..., a_{11}}$ is the input state of the hasher, and ${b_{0}, ..., b_{11}}$ is the output state of the hasher.

Simple 2-to-1 hash

Computing a 2-to-1 hash involves the following steps:

Initialize hasher state with $8$ field elements, setting the second capacity element to $d o main$ if the domain is provided (as in the case of control block hashing) or else $0$ , and the remaining capacity elements to $0$ .
Apply Rescue Prime Optimized permutation.
Return elements $[4, 8)$ of the hasher state as output.

The chiplet accomplishes the above by executing the following instructions:

[BP, HR]                 // init state and execute a hash round (concurrently)
HR HR HR HR HR HR        // execute 6 more hash rounds
HOUT                     // return elements 4, 5, 6, 7 of the state as output

Execution trace for this computation would look as illustrated below.

hash_2_to_1_hash

In the above, we compute the following:

${c_{0}, c_{1}, c_{2}, c_{3}} \leftarrow ha s h ({a_{0}, a_{1}, a_{2}, a_{3}}, {b_{0}, b_{1}, b_{2}, b_{3}})$

Linear hash of n elements

Computing a linear hash of $n$ elements consists of the following steps:

Initialize hasher state with the first $8$ elements, setting the first capacity register to $0$ if $n$ is a multiple of the rate width ( $8$ ) or else $1$ , and the remaining capacity elements to $0$ .
Apply Rescue Prime Optimized permutation.
Absorb the next set of elements into the state (up to $8$ elements), while keeping capacity elements unchanged.
Repeat steps 2 and 3 until all $n$ elements have been absorbed.
Return elements $[4, 8)$ of the hasher state as output.

The chiplet accomplishes the above by executing the following instructions (for hashing $16$ elements):

[BP, HR]                    // init state and execute a hash round (concurrently)
HR HR HR HR HR HR           // execute 6 more hash rounds
ABP                         // absorb the next set of elements into the state
HR HR HR HR HR HR HR        // execute 7 hash rounds
HOUT                        // return elements 4, 5, 6, 7 of the state as output

Execution trace for this computation would look as illustrated below.

hash_linear_hash_n

In the above, the value absorbed into hasher state between rows $7$ and $8$ is the delta between values $t_{i}$ and $s_{i}$ . Thus, if we define $b_{i} = t_{i} - s_{i}$ for $i \in [0, 8)$ , the above computes the following:

${r_{0}, r_{1}, r_{2}, r_{3}} \leftarrow ha s h (a_{0}, ..., a_{7}, b_{0}, ..., b_{7})$

Verify Merkle path

Verifying a Merkle path involves the following steps:

Initialize hasher state with the leaf and the first node of the path, setting all capacity elements to $0$ s. a. Also, initialize the index register to the leaf's index value.
Apply Rescue Prime Optimized permutation. a. Make sure the index value doesn't change during this step.
Copy the result of the hash to the next row, and absorb the next node of the Merkle path into the hasher state. a. Remove a single bit from the index, and use it to determine how to place the copied result and absorbed node in the state.
Repeat steps 2 and 3 until all nodes of the Merkle path have been absorbed.
Return elements $[4, 8)$ of the hasher state as output. a. Also, make sure the index value has been reduced to $0$ .

The chiplet accomplishes the above by executing the following instructions (for Merkle tree of depth $3$ ):

[MP, HR]                    // init state and execute a hash round (concurrently)
HR HR HR HR HR HR           // execute 6 more hash rounds
MPA                         // copy result & absorb the next node into the state
HR HR HR HR HR HR HR        // execute 7 hash rounds
HOUT                        // return elements 4, 5, 6, 7 of the state as output

Suppose we have a Merkle tree as illustrated below. This Merkle tree has $4$ leaves, each of which consists of $4$ field elements. For example, leaf $a$ consists of elements $a_{0}, a_{1}, a_{2}, a_{3}$ , leaf be consists of elements $b_{0}, b_{1}, b_{2}, b_{3}$ etc.

hash_merkle_tree

If we wanted to verify that leaf $d$ is in fact in the tree, we'd need to compute the following hashes:

$r \leftarrow ha s h (e, ha s h (c, d))$

And if $r = g$ , we can be convinced that $d$ is in fact in the tree at position $3$ . Execution trace for this computation would look as illustrated below.

hash_merkle_tree_trace

In the above, the prover provides values for nodes $c$ and $e$ non-deterministically.

Update Merkle root

Updating a node in a Merkle tree (which also updates the root of the tree) can be simulated by verifying two Merkle paths: the path that starts with the old leaf and the path that starts with the new leaf.

Suppose we have the same Merkle tree as in the previous example, and we want to replace node $d$ with node $d^{'}$ . The computations we'd need to perform are:

$r \leftarrow ha s h (e, ha s h (c, d)) r^{'} \leftarrow ha s h (e, ha s h (c, d^{'}))$

Then, as long as $r = g$ , and the same values were used for $c$ and $e$ in both computations, we can be convinced that the new root of the tree is $r^{'}$ .

The chiplet accomplishes the above by executing the following instructions:

// verify the old merkle path
[MV, HR]                    // init state and execute a hash round (concurrently)
HR HR HR HR HR HR           // execute 6 more hash rounds
MPV                         // copy result & absorb the next node into the state
HR HR HR HR HR HR HR        // execute 7 hash rounds
HOUT                        // return elements 4, 5, 6, 7 of the state as output

// verify the new merkle path
[MU, HR]                    // init state and execute a hash round (concurrently)
HR HR HR HR HR HR           // execute 6 more hash rounds
MPU                         // copy result & absorb the next node into the state
HR HR HR HR HR HR HR        // execute 7 hash rounds
HOUT                        // return elements 4, 5, 6, 7 of the state as output

The semantics of MV and MU instructions are similar to the semantics of MP instruction from the previous example (and MVA and MUA are similar to MPA) with one important difference: MV* instructions add the absorbed node (together with its index in the tree) to permutation column $p_{1}$ , while MU* instructions remove the absorbed node (together with its index in the tree) from $p_{1}$ . Thus, if the same nodes were used during both Merkle path verification, the state of $p_{1}$ should not change. This mechanism is used to ensure that the same internal nodes were used in both computations.

AIR constraints

When describing AIR constraints, we adopt the following notation: for column $x$ , we denote the value in the current row simply as $x$ , and the value in the next row of the column as $x'$ . Thus, all transition constraints described in this note work with two consecutive rows of the execution trace.

Selector columns constraints

For selector columns, first we must ensure that only binary values are allowed in these columns. This can be done with the following constraints:

$s_{0}^{2} - s_{0} = 0 | degree = 2 s_{1}^{2} - s_{1} = 0 | degree = 2 s_{2}^{2} - s_{2} = 0 | degree = 2$

Next, we need to make sure that unless $f_{o u t} = 1$ or $f_{o u t}^{'} = 1$ , the values in columns $s_{1}$ and $s_{2}$ are copied over to the next row. This can be done with the following constraints:

$(s_{1}^{'} - s_{1}) \cdot (1 - f_{o u t}^{'}) \cdot (1 - f_{o u t}) = 0 | degree = 7 (s_{2}^{'} - s_{2}) \cdot (1 - f_{o u t}^{'}) \cdot (1 - f_{o u t}) = 0 | degree = 7$

Next, we need to enforce that if any of $f_{ab p}, f_{m p a}, f_{m v a}, f_{m u a}$ flags is set to $1$ , the next value of $s_{0}$ is $0$ . In all other cases, $s_{0}$ should be unconstrained. These flags will only be set for rows that are 1 less than a multiple of 8 (the last row of each cycle). This can be done with the following constraint:

$s_{0}^{'} \cdot (f_{ab p} + f_{m p a} + f_{m v a} + f_{m u a}) = 0 | degree = 5$

Lastly, we need to make sure that no invalid combinations of flags are allowed. This can be done with the following constraints:

$k_{0} \cdot (1 - s_{0}) \cdot s_{1} = 0 | degree = 3$

The above constraints enforce that on every step which is one less than a multiple of $8$ , if $s_{0} = 0$ , then $s_{1}$ must also be set to $0$ . Basically, if we set $s_{0} = 0$ , then we must make sure that either $f_{h o u t} = 1$ or $f_{so u t} = 1$ .

Node index constraints

Node index column $i$ is relevant only for Merkle path verification and Merkle root update computations, but to simplify the overall constraint system, the same constraints will be imposed on this column for all computations.

Overall, we want values in the index column to behave as follows:

When we start a new computation, we should be able to set $i$ to an arbitrary value.
When a computation is finished, value in $i$ must be $0$ .
When we absorb a new node into the hasher state we must shift the value in $i$ by one bit to the right.
In all other cases value in $i$ should not change.

A shift by one bit to the right can be described with the following equation: $i = 2 \cdot i^{'} + b$ , where $b$ is the value of the bit which is discarded. Thus, as long as $b$ is a binary value, the shift to the right is performed correctly, and this can be enforced with the following constraint:

$b^{2} - b = 0$

Since we want to enforce this constraint only when a new node is absorbed into the hasher state, we'll define a flag for when this should happen as follows:

$f_{an} = f_{m p} + f_{m v} + f_{m u} + f_{m p a} + f_{m v a} + f_{m u a}$

And then the full constraint would looks as follows:

$f_{an} \cdot (b^{2} - b) = 0 | degree = 6$

Next, to make sure when a computation is finished $i = 0$ , we can use the following constraint:

$f_{o u t} \cdot i = 0 | degree = 4$

Finally, to make sure that the value in $i$ is copied over to the next row unless we are absorbing a new row or the computation is finished, we impose the following constraint:

$(1 - f_{an} - f_{o u t}) \cdot (i^{'} - i) = 0 | degree = 5$

To satisfy these constraints for computations not related to Merkle paths (i.e., 2-to-1 hash and liner hash of elements), we can set $i = 0$ at the start of the computation. This guarantees that $i$ will remain $0$ until the end of the computation.

Hasher state constraints

Hasher state columns $h_{0}, ..., h_{11}$ should behave as follows:

For the first $7$ row of every $8$ -row cycle (i.e., when $k_{0} = 0$ ), we need to apply Rescue Prime Optimized round constraints to the hasher state. For brevity, we omit these constraints from this note.
On the $8$ th row of every $8$ -row cycle, we apply the constraints based on which transition flag is set as described in the table below.

Specifically, when absorbing the next set of elements into the state during linear hash computation (i.e., $f_{ab p} = 1$ ), the first $4$ elements (the capacity portion) are carried over to the next row. For $j \in [0, 4)$ this can be described as follows:

$f_{ab p} \cdot (h_{j}^{'} - h_{j}) = 0 | degree = 5$

When absorbing the next node during Merkle path computation (i.e., $f_{m p} + f_{m v} + f_{m u} = 1$ ), the result of the previous hash ( $h_{4}, ..., h_{7}$ ) are copied over either to $(h_{4}^{'}, ..., h_{7}^{'})$ or to $(h_{8}^{'}, ..., h_{11}^{'})$ depending on the value of $b$ , which is defined in the same way as in the previous section. For $j \in [0, 4)$ this can be described as follows:

$(f_{m p} + f_{m v} + f_{m u}) \cdot ((1 - b) \cdot (h_{j + 4}^{'} - h_{j + 4}) + b \cdot (h_{j + 8}^{'} - h_{j + 4})) = 0 | degree = 6$

Note, that when a computation is completed (i.e., $f_{o u t} = 1$ ), the next hasher state is unconstrained.

Multiset check constraints

In this sections we describe constraints which enforce updates for multiset check columns $b_{c hi p}$ and $p_{1}$ . These columns can be updated only on rows which are multiples of $8$ or $1$ less than a multiple of $8$ . On all other rows the values in the columns remain the same.

To simplify description of the constraints, we define the following variables. Below, we denote random values sent by the verifier after the prover commits to the main execution trace as $α_{0}$ , $α_{1}$ , $α_{2}$ etc.

$m = o p_{l ab e l} + 2^{4} \cdot k_{0} + 2^{5} \cdot k_{2} v_{h} = α_{0} + α_{1} \cdot m + α_{2} \cdot (c l k + 1) + α_{3} \cdot i v_{a} = j = 0 \sum 3 (α_{j + 4} \cdot h_{j}) v_{b} = j = 4 \sum 7 (α_{j + 4} \cdot h_{j}) v_{c} = j = 8 \sum 11 (α_{j + 4} \cdot h_{j}) v_{d} = j = 8 \sum 11 (α_{j} \cdot h_{j})$

In the above:

$m$ is a transition label, composed of the operation label and the periodic columns that uniquely identify each transition function. The values in the $k_{0}$ and $k_{2}$ periodic columns are included to identify the row in the hash cycle where the operation occurs. They serve to differentiate between operations that share selectors but occur at different rows in the cycle, such as BP, which uses $o p_{l inha s h}$ at the first row in the cycle to initiate a linear hash, and ABP, which uses $o p_{l inha s h}$ at the last row in the cycle to absorb new elements.
$v_{h}$ is a common header which is a combination of the transition label, a unique row address, and the node index. For the unique row address, the clk column from the system component is used, but we add $1$ , because the system's clk column starts at $0$ .
$v_{a}$ , $v_{b}$ , $v_{c}$ are the first, second, and third words (4 elements) of the hasher state.
$v_{d}$ is the third word of the hasher state but computed using the same $α$ values as used for the second word. This is needed for computing the value of $v_{l e a f}$ below to ensure that the same $α$ values are used for the leaf node regardless of which part of the state the node comes from.

Chiplets bus constraints

As described previously, the chiplets bus $b_{c hi p}$ , implemented as a running product column, is used to tie the hash chiplet with the main VM's stack and decoder. When receiving inputs from or returning results to the stack (or decoder), the hash chiplet multiplies $b_{c hi p}$ by their respective values. On the other side, when sending inputs to the hash chiplet or receiving results from the chiplet, the stack (or decoder) divides $b_{c hi p}$ by their values.

In the section below we describe only the hash chiplet side of the constraints (i.e., multiplying $b_{c hi p}$ by relevant values). We define the values which are to be multiplied into $b_{c hi p}$ for each operation as follows:

When starting a new simple or linear hash computation (i.e., $f_{b p} = 1$ ) or when returning the entire state of the hasher ( $f_{so u t} = 1$ ), the entire hasher state is included into $b_{c hi p}$ : $v_{a ll} = v_{h} + v_{a} + v_{b} + v_{c}$

When starting a Merkle path computation (i.e., $f_{m p} + f_{m v} + f_{m u} = 1$ ), we include the leaf of the path into $b_{c hi p}$ . The leaf is selected from the state based on value of $b$ (defined as in the previous section): $v_{l e a f} = v_{h} + (1 - b) \cdot v_{b} + b \cdot v_{d}$

When absorbing a new set of elements into the state while computing a linear hash (i.e., $f_{ab p} = 1$ ), we include deltas between the last $8$ elements of the hasher state (the rate) into $b_{c hi p}$ : $v_{ab p} = v_{h} + v_{b}^{'} + v_{c}^{'} - (v_{b} + v_{c})$

When a computation is complete (i.e., $f_{h o u t} = 1$ ), we include the second word of the hasher state (the result) into $b_{c hi p}$ : $v_{res} = v_{h} + v_{b}$

Using the above values, we can describe the constraints for updating column $b_{c hi p}$ as follows.

$b_{c hi p}^{'} = b_{c hi p} \cdot ((f_{b p} + f_{so u t}) \cdot v_{a ll} + (f_{m p} + f_{m v} + f_{m u}) \cdot v_{l e a f} + f_{ab p} \cdot v_{ab p} + f_{h o u t} \cdot v_{res} + 1 - (f_{b p} + f_{m p} + f_{m v} + f_{m u} + f_{ab p} + f_{o u t}))$

The above constraint reduces to the following under various flag conditions:

Condition	Applied constraint
$f_{b p} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{a ll}$
$f_{so u t} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{a ll}$
$f_{m p} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{l e a f}$
$f_{m v} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{l e a f}$
$f_{m u} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{l e a f}$
$f_{ab p} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{ab p}$
$f_{h o u t} = 1$	$b_{c hi p}^{'} = b_{c hi p} \cdot v_{res}$
Otherwise	$b_{c hi p}^{'} = b_{c hi p}$

Note that the degree of the above constraint is $7$ .

Sibling table constraints

Note: Although this table is described independently, it is implemented as part of the chiplets virtual table, which combines all virtual tables required by any of the chiplets into a single master table.

As mentioned previously, the sibling table (represented by running column $p_{1}$ ) is used to keep track of sibling nodes used during Merkle root update computations. For this computation, we need to enforce the following rules:

When computing the old Merkle root, whenever a new sibling node is absorbed into the hasher state (i.e., $f_{m v} + f_{m v a} = 1$ ), an entry for this sibling should be included into $p_{1}$ .
When computing the new Merkle root, whenever a new sibling node is absorbed into the hasher state (i.e., $f_{m u} + f_{m u a} = 1$ ), the entry for this sibling should be removed from $p_{1}$ .

To simplify the description of the constraints, we use variables $v_{b}$ and $v_{c}$ defined above and define the value representing an entry in the sibling table as follows: $v_{s ib l in g} = α_{0} + α_{3} \cdot i + b \cdot v_{b} + (1 - b) \cdot v_{c}$

Using the above value, we can define the constraint for updating $p_{1}$ as follows:

$p_{1}^{'} \cdot ((f_{m v} + f_{m v a}) \cdot v_{s ib l in g} + 1 - (f_{m v} + f_{m v a})) = p_{1} \cdot ((f_{m u} + f_{m u a}) \cdot v_{s ib l in g} + 1 - (f_{m u} + f_{m u a}))$

The above constraint reduces to the following under various flag conditions:

Condition	Applied constraint
$f_{m v} = 1$	$p_{1}^{'} \cdot v_{s ib l in g} = p_{1}$
$f_{m v a} = 1$	$p_{1}^{'} \cdot v_{s ib l in g} = p_{1}$
$f_{m u} = 1$	$p_{1}^{'} = p_{1} \cdot v_{s ib l in g}$
$f_{m u a} = 1$	$p_{1}^{'} = p_{1} \cdot v_{s ib l in g}$
Otherwise	$p_{1}^{'} = p_{1}$

Note that the degree of the above constraint is $7$ .

To make sure computation of the old Merkle root is immediately followed by the computation of the new Merkle root, we impose the following constraint:

$(f_{b p} + f_{m p} + f_{m v}) \cdot (1 - p_{1}) = 0 | degree = 5$

The above means that whenever we start a new computation which is not the computation of the new Merkle root, the sibling table must be empty. Thus, after the hash chiplet computes the old Merkle root, the only way to clear the table is to compute the new Merkle root.

Together with boundary constraints enforcing that $p_{1} = 1$ at the first and last rows of the running product column which implements the sibling table, the above constraints ensure that if a node was included into $p_{1}$ as a part of computing the old Merkle root, the same node must be removed from $p_{1}$ as a part of computing the new Merkle root. These two boundary constraints are described as part of the chiplets virtual table constraints.

Polygon Miden VM