Padding-kk state machine

All Keccak-related state machines are accessed through the Padding-KK state machine. It is therefore responsible for handling queries from the Main state machine. The common queries are requests for digests of messages, together with validation of these digests.

In this document, the workings of the Padding-KK SM are described. How it validates the validity of hash values, input string lengths, and input string reading to ensure that padding requirements are followed.

First, keep in mind that the Padding-KK SM’s operations are byte-based, whereas the Keccak-F SM’s actions are bit-based. This discrepancy in string formats is handled by the Padding-KK-Bit SM.

Padding and the Keccak-F SM¶

Although the hashing of messages is carried out by the Keccak-F SM, the padding happens in the Padding-KK SM. Messages are presented to the Padding-KK SM as byte-strings in hexadecimal form. But the Padding-KK-Bit SM ensures that these are presented as bit-strings to the Keccak-F SM.

Even though Keccak-F SM receives strings of any length as inputs, each input-message to the Keccak-F SM is first split into blocks of 1088 bits (i.e., 136 bytes), called the bit rate (or rate). If the tail-end of the splits is shorter than 136 bytes, or if the original message is shorter than 136 bytes, a specific string is appended to it in order to form a full 136-byte string. The appended bits (or bytes) are referred to as the padding.

Keccak’s first padding-rule is to append the string $100^{*} 1$ of the appropriate length. That is, the padding always consists of two 1’s and a string of 0’s between them.

The second padding rule: If the input-message is exactly 136 bytes long, or a multiple of 136 bytes, then a block of 136 bytes consisting of just the padding $100^{*} 1$ , must be appended.

It is crucial to emphasise that the Polygon zkEVM follows the Keccak construction used in the Ethereum. So then the Padding-KK SM does not append any other ‘fixed’ bits to the padding, such as appending “ $01$ ” as it is done in the FIPS’s SHA-3. Therefore, as far as the Keccak-F hash function is concerned, the Polygon zkEVM does not follow the FIPS.202 Standard.

Input strings and padding¶

Consider the strings $s_{1}, s_{2}, \dots, s_{n}$ that need to be hashed.

Note that the bits (or bytes) of these strings cannot be simply combined and presented as one stream of bits (or bytes) as though they belong to one long string. But each string $s_{i}$ need to be treated as an individual string, and thus must first be separately padded in line with the above-mentioned padding rules. Only thereafter, depending on the SM involved, can the bytes or the bits be fed into the relevant SM.

The idea here is to map each string to one or several blocks of 136 bytes (1088 bits), and include the proper padding at the tail-end part.

Schema of input strings allocation in Keccak

Observe that, as shown in the first string in the Figure above; Whenever the length of a certain string is a multiple of the block length of 136 bytes, a new block containing only the padding must be appended. Once this is done, the new resulting string can be provided to the Keccak-F SM for hashing.

Dealing with Main SM queries¶

The Padding-KK SM is in charge of validating that the padding rule is correctly performed, as well as validating each of the prescribed operations;

Validate the lengths of given strings ${s_{i}}$ . (i.e., length check),
Validate the hashes of certain strings ${s_{i}}$ . (i.e., digest check),
Validate reads from 1 to 32 bytes of string ${s_{i}}$ . (i.e., read check).

Next is to prepare the machinery that will enable the Padding-KK SM achieve these three checks.

Setting up columns for verification purposes¶

We now design a series of columns that will enable us to completely verify correctness of every state transitions.

$freeIn$ : This register will store every byte of the padded input (as commented before), one byte per row.
$address$ : This register will store an increasing sequence of integers starting from 0, changing its value at the beginning of a new string. Of course, an address completely determines the corresponding string of a certain byte.
$connected$ : This register represents the connection between two blocks. If $connected$ is 1, the actual block is in the same string with the previous block. Otherwise, the last block is in the previous string.
$lastBlock$ : This register flags the last row of every block. If $lastBlock$ is 1, the next block will start in the next row of the table.
$rem$ : For each string, this register is a decreasing sequence of signed integers. Starting at the length of the current string and it keeps decreasing until the last block of the string is reached. Observe that this value can be negative since a padding may be present in the string. ( $rem$ is short for ‘remaining’.)
$len$ : For each string, this register stores original length (i.e., the length of the string before padding was appended). Therefore, this register remains constant for all rows of each string. Observe that, at the first row of each string, $len$ coincides with $rem$ .
$remIsZero$ : A computed register which is 1 whenever $rem$ is zero, and 0 otherwise.
$spare$ : The $spare$ register is 1 just after the byte $0x01$ , corresponding to the appearance of padding bits. Observe that it can happen that $spare$ is constantly 0 among a full string. This is because we can have the situation where the padding only consists of the byte $0x81$ .
$lastHash$ : This register is actually computed from the registers $spare$ , $remIsZero$ and $lastBlock$ as follows,

\begin{matrix} (Eqn.1) & lastHash = lastBlock \cdot (spare + remIsZero) \end{matrix}

This means $lastHash$ will be 1 whenever two things hold true. First, if $lastBlock = 1$ , and secondly, if the next block to be processed is contained in the next string.

Observe that $spare$ and $remIsZero$ cannot simultaneously be “1” (i.e., not in the same row). Moreover, it is very important to include $remIsZero$ in this computation because $spare$ alone cannot help detect that padding has occurred. For instance, if $pad = 0 x 81$ , then $spare$ would remain constant, continuing to record 0’s as if no padding took place.

Example: Padding check using columns¶

Let us illustrate this design with a table, using the columns defined above. Suppose the following strings have been padded and are ready for hashing:

s_{0} = 8000 \dots 00016 f 6 c 6 c 6568 s_{1} = 8000012 f \dots 11 | 616 c \dots 6966

where “|” indicates the end of a 136-byte block. In the below table, these 136-byte splits between blocks are indicated with a horizontal line.

\begin{array}{lccccc} freeIn & addr & connected & lastBlock & rem & len & remIsZero & spare & lastHash \\ 0 x 68 & 0 & 0 & 0 & 5 & 5 & 0 & 0 & 0 \\ 0 x 65 & 0 & 0 & 0 & 4 & 5 & 0 & 0 & 0 \\ 0 x 6 c & 0 & 0 & 0 & 3 & 5 & 0 & 0 & 0 \\ 0 x 6 c & 0 & 0 & 0 & 2 & 5 & 0 & 0 & 0 \\ 0 x 6 f & 0 & 0 & 0 & 1 & 5 & 0 & 0 & 0 \\ 0 x 01 & 0 & 0 & 0 & 0 & 5 & 1 & 0 & 0 \\ 0 x 00 & 0 & 0 & 0 & - 1 & 5 & 0 & 1 & 0 \\ \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots \\ 0 x 00 & 0 & 0 & 0 & - 129 & 5 & 0 & 1 & 0 \\ 0 x 80 & 0 & 0 & 1 & - 130 & 5 & 0 & 1 & 1 \\ 0 x 66 & 1 & 0 & 0 & 269 & 269 & 0 & 0 & 0 \\ 0 x 69 & 1 & 0 & 0 & 268 & 269 & 0 & 0 & 0 \\ \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots \\ 0 x 6 c & 1 & 0 & 0 & 135 & 269 & 0 & 0 & 0 \\ 0 x 61 & 1 & 0 & 1 & 134 & 269 & 0 & 0 & 0 \\ 0 x 11 & 1 & 1 & 0 & 133 & 269 & 0 & 0 & 0 \\ \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots \\ 0 x 2 f & 1 & 1 & 0 & 1 & 269 & 0 & 0 & 0 \\ 0 x 01 & 1 & 1 & 0 & 0 & 269 & 1 & 0 & 0 \\ 0 x 00 & 1 & 1 & 0 & - 1 & 269 & 0 & 1 & 0 \\ 0 x 80 & 1 & 1 & 1 & - 2 & 269 & 0 & 1 & 1 \end{array}

The above table illustrates how the columns can be used to record the executional trace of the Padding-KK State Machine. As it is our general approach, a strategy towards achieving verifiable computations, the next task is to describe the state transitions of the Padding-KK SM in terms of polynomials.

Description of state transitions in PIL¶

By capturing the relationships between and among the columns (registers defined above) in terms of equations, amounts to translating the execution of the padding into a verification code written in PIL.

In order to guarantee that the value recorded in the $rem$ register decreases until $lastHash$ is 1 (that is, the end of the string), use the relation,

$\begin{matrix} (Eqn.2) & {rem}^{'} \cdot (1 - lastHash) = (rem - 1) (1 - lastHash) \end{matrix}$
How can we validate the fact that $spare$ was constructed as expected?

First observe that $spare$ changes to 1 immediately after a 1 was recorded in the $remIsZero$ register. (i.e., immediately when the padding starts, and when $pad \neq 0 x 81$ .)

Secondly, notice that after this point, $spare$ remains 1 until (and including when) $lastHash$ equals 1. After which, $spare$ becomes 0.

Hence, these behaviour can be captured as, $$ \texttt{spare}’ \mathtt{ = (spare + remIsZero)\cdot (1 - lastHash)} \tag{Eqn.3} $$
Verifying correctness of the $connected$ register requires two constraints;

→ Checking that $connected$ is constant in each block

$\begin{matrix} (Eqn.4) & {connected}^{'} \cdot (1 - lastBlock) = connected \cdot (1 - lastBlock) \end{matrix}$

→ Checking two specific situations,
- When $lastBlock$ is 1 and $lastHash$ is 0 : in this case, the next value of $connected$ should be 0, because of the block change but within the same string.
- When both $lastBlock$ and $lastHash$ are 1 : in this case, the next value of $connected$ should be 0, due to the string change.
These two scenarios are verified with the following constraint,

$\begin{matrix} (Eqn.5) & {connected}^{'} \cdot lastBlock = (1 - lastHash) \cdot lastBlock \end{matrix}$
The $len$ register is constant within each string. It must therefore satisfy this relationship,

$\begin{matrix} (Eqn.6) & {len}^{'} \cdot firstHash = len \cdot (1 - lastHash) \end{matrix}$
Checking that $len$ and $rem$ coincide at the first state of each string, use the constraint,

$\begin{matrix} (Eqn.7) & len \cdot firstHash = rem \cdot firstHash \end{matrix}$

where $firstHash$ is a committed column and it is such that ${firstHash}^{'} = lastHash$ .

In fact, $firstHash$ is a shifted version of $lastHash$ , which is used to ensure that, when starting a string (and therefore, $firstHash = 1$ ), then $len = rem$ .

$\begin{array}{lccccc} lastHash & firstHash \\ 0 & 0 \\ \dots & \dots \\ 0 & 0 \\ 0 & 0 \\ \dots & \dots \\ 1 & 0 \\ 0 & 1 \\ \dots & \dots \end{array}$
Let us now specify the relations that satisfy the $addr$ register. As commented on before, $addr$ is constant within each string. Hence, $({addr}^{'} - addr) = 0$ if and only if $1 - lastHash \neq 0$ .

The constraint for the $addr$ register is therefore,

$\begin{matrix} (Eqn.8) & ({addr}^{'} - addr) \cdot (1 - lastHash) = 0 \end{matrix}$

Note that going from one string to the next, the values of the $addr$ register form an increasing sequence (increasing by steps of 1 from one string to the next).

However, since the polynomials utilized in this scheme are all cyclic (due to evaluations on roots of unity), there is a need to ensure that the $addr$ register resets to $0$ whenever the reading returns to the first row.

For this purpose, a register called $lastBlockLatch$ is added. And $lastBlockLatch$ is 1, if $lastBlock$ is 1 and the string, that the last block belongs to, is not the last one.

Similarly, another register called $lastHashLatch$ is added, and it is defined such that

$\begin{matrix} (Eqn.9) & lastHashLatch = lastBlockLatch \cdot (spare + remIsZero) \end{matrix}$

See below table for a comparison between the $latch$ and non- $latch$ registers.

$\begin{array}{lccccc} lastBlock & lastBlockLatch & lastHash & lastHashLatch \\ 0 & 0 & 0 & 0 \\ \dots & \dots & \dots & \dots \\ 1 & 1 & 0 & 0 \\ 0 & 0 & 0 & 0 \\ \dots & \dots & \dots & \dots \\ 1 & 1 & 1 & 1 \\ 0 & 0 & 0 & 0 \\ \dots & \dots & \dots & \dots \\ \dots & \dots & \dots & \dots \\ 1 & 0 & 1 & 0 \end{array}$
In order to grapple with the increasing but cyclic sequence of $addr$ , the following constraint is used,

$\begin{matrix} (Eqn.10) & ({addr}^{'} - 1 - addr) \cdot lastHashLatch = 0 \end{matrix}$
Now, checking whether $remIsZero$ is 1 if and only if $rem$ is 0, is done reversely by first committing the column $remInv$ , the inverse of $rem$ , and computing $remIsZero$ as: $$ \mathtt{remIsZero = 1 − rem · remInv} \tag{Eqn.11} $$

And then, as usual, check the relation, $remIsZero \cdot rem = 0$ .
Next is the $aFreeIn$ register which stores the input byte if and only if the current row does not corresponding to the padding. $aFreeIn$ is computed from the $remIsZero$ , $spare$ and $lastHash$ registers. This ensures loading the padding bytes at their correct positions.

In fact, this register will be used in the Plookup of the next state machine.

Observe that $aFreeIn$ can be computed as

$\begin{matrix} (Eqn.12) & aFreeIn = (1 - (remIsZero + spare)) \cdot freeIn + remIsZero + lastHash \cdot 0 x 80 \end{matrix}$

Let us carefully analyze this equation:
- If $remIsZero$ , $spare$ and $lastHash$ are all $0$ , then $aFreeIn$ equals $freeIn$ . As mentioned above, at the non-padding rows, we just store $freeIn$ .
- If $remIsZero$ is 1, $spare$ is 0 and $lastHash$ is 0, then $aFreeIn$ equals $0x01$ , which is the first byte of the padding.
- If $remIsZero$ is 0, $spare$ is 1 and $lastHash$ is 0, then $aFreeIn$ equals $0x00$ , which are the intermediate bytes of the padding.
- If $remIsZero$ is 0, $spare$ is 1 and $lastHash$ is 1, then $aFreeIn$ equals $0x80$ , which is the last byte of the padding.
- Lastly, we should consider the special case where the padding is only the byte $0x81$ . In this case, $spare$ is 0 at the last row meanwhile $lastHash$ and $remIsZero$ are both 1. Therefore, $aFreeIn$ equals $0x81$ , as we wanted.
See below table for all the above cases when computing $aFreeIn$ .

\begin{array}{lccccc} remIsZero & spare & lastHash & aFreeIn \\ 0 & 0 & 0 & freeIn \\ 1 & 0 & 0 & 0x01 \\ 0 & 1 & 0 & 0x00 \\ 0 & 1 & 1 & 0x80 \\ 1 & 0 & 1 & 0x81 \end{array}

Hash output check¶

We have thus far only dealt with correct inputs of the padding. Now, we will introduce several columns to deal with the hash itself.

Since KECCAK-256’s output is 256 bits long, we use eight (8) registers each of 32 bits to store the result of the hash function. Denote these registers by ${{hash}_{i} | i \in {0, 1, 2, \dots, 7}}$ .

As columns, these ${{hash}_{i}}$ registers will remain constant within a single string, because they represent the hash of a given string. The following constraints are therefore added,

\begin{matrix} (Eqn.13) & (hash' - hash) \cdot (1 - lastHash) = 0 \end{matrix}

A combination of other KECCAK-related state machines will be used to verify correctness of the output hash. The reason for this is that, for compatibility with the KECCAK-256 hash function, we first need to describe all inputs in terms of bits.

Length and read check operations¶

In this section we give a description of the design that will allow us to verify the lengths of input strings and the read operations.

Length check¶

The length check is almost trivial because the $len$ register has already been introduced.

Suppose one is given a length $l$ and an address $a$ . And the aim is to check if the string corresponding to the address $a$ has length $l$ .

The strategy is to use Plookup to verify that the given table contains a row with $len = l$ and an address $addr = a$ in the last row of the string (i.e., when $lastHash = 1$ ). That is to say, the table of columns; $len$ , $addr$ and $lastHash$ ; is as displayed in the table provided below.

\begin{array}{lccccc} lastHash & addr & len \\ 0 & 0 & \dots \\ \dots & \dots & \dots \\ 1 & 0 & \dots \\ 0 & 1 & \dots \\ \dots & \dots & \dots \\ 1 & 1 & \dots \\ 0 & \dots & \dots \\ \dots & \dots & \dots \\ 1 & \dots & \dots \\ 0 & a & l \\ \dots & \dots & \dots \\ 0 & a & l \\ 1 & a & l \\ 0 & a + 1 & \dots \\ \dots & \dots & \dots \end{array}

The PIL code for this Plookup looks like this:

hashKLen {addr, op 0} in PaddingKK . lastHashLatch {PaddingKK . addr, PaddingKK . len}

where $hashKLen$ flags whenever the operation is checked and the length is stored in $op 0$ .

Read check¶

Checking reads requires more columns to be introduced. Recall that, given given three parameters; the address $a$ of a string, the position $p$ of the starting byte of the string, and $l$ the total number of bytes that we want to read; the intention is to read the bytes of the string from the first to thirty second.

It takes 8 registers, each of 32-bits, to store the output of the read operation. Let us denote these registers by:

{{crV}_{i} | i \in {0, 1, 2, \dots, 7}}

Further 8 factor polynomials ${{crF}_{j} | j \in {0, 1, 2, \dots, 7}}$ are needed so as to correctly place the input bytes with respect to their right power of 2.

Before looking into the roles of the ${{crV}_{i}}$ registers and ${{crF}_{i}}$ factor polynomials, three more columns are necessary for describing the verification of the read operations. These registers are; $crLen$ , $crOffset$ and $crLatch$ ; and are defined as follows.

$crLen$ : A register that specifies the number bytes to be read. It is a number register, containing numbers between 1 and 32, and it remains constant in each of the readings we want to perform.
$crOffset$ : A decreasing sequence of values, starting from the length value of the read minus 1 (i.e., $crLen - 1$ ) and ends at 0, for each read. This is important for positioning each byte at the correct power of 2.
$crLatch$ : This is a computed column, using the same inverse technique as before. It records instances when the $crOffset$ register is 0. First, the register $crOffsetInv$ is committed, allowing $crLatch$ to be expressed as $$ \mathtt{crLatch = 1 − crOffset \cdot crOffsetInv} \tag{Eqn.14} $$ which satisfies the constraint, $crOffsetInv \cdot crLatch = 0$ .

Example: Read check using columns¶

Suppose we want to read the first 10 bytes of the address 6, and once finished, read the next two bytes of the same address thereafter. Here is the correct way of constructing the polynomials; $crLen$ , $crOffset$ and $crLatch$ . Consider the string, $s = 0 x . . .7355 ff 00111 a 6 e 6 e 1 f 02 ef 10$ .

\begin{array}{lccccc} aFreeIn & addr & crLen & crOffset & crLatch \\ 0 x 10 & 6 & 10 & 9 & 0 \\ 0 xef & 6 & 10 & 8 & 0 \\ 0 x 02 & 6 & 10 & 7 & 0 \\ 0 x 1 f & 6 & 10 & 6 & 0 \\ 0 x 6 e & 6 & 10 & 5 & 0 \\ 0 x 6 e & 6 & 10 & 4 & 0 \\ 0 x 1 a & 6 & 10 & 3 & 0 \\ 0 x 11 & 6 & 10 & 2 & 0 \\ 0 x 00 & 6 & 10 & 1 & 0 \\ 0 xff & 6 & 10 & 0 & 1 \\ 0 x 55 & 6 & 2 & 1 & 0 \\ 0 x 73 & 6 & 2 & 0 & 1 \\ \dots & \dots & \dots & \dots & \dots \end{array}

Note that the horizontal line is used to separate every 8 bytes, which are the exact number of bytes stored in a ${crV}_{i}$ register. We will later on see why this is important.

Several observations

Firstly, note that $crLatch$ is 1 if and only if $crOffset$ is 0.

Secondly, if we want to express the two read values as an array, the output will be $$ \mathtt{[0xff00111a6e6e1f02ef10, 0x7355]} $$ where the first element of the array has 10 bytes, whilst the second has 2 bytes. This coincides with each of the $crLen$ defined values.

Thirdly, observe the relationships that these registers; $crLen$ , $crOffset$ and $crLatch$ ; have to satisfy.

$(a)$ The $crOffset$ register decreases in every read, so we can express this as $$ \mathtt{crOffset′ \cdot (1 − crLatch) = (crOffset − 1) \cdot (1 − crLatch)} \tag{Eqn.15} $$ $(b)$ The $crLen$ register remains constant during each read operation, hence the following constraint applies, $$ \mathtt{crLen′ \cdot (1 − crLatch) = crLen \cdot (1 − crLatch)} \tag{Eqn.16} $$ $(c)$ The first $crOffset$ of every read is $crLen − 1$ . Hence, we need to specify the following relationship $$ \mathtt{crLatch \cdot crOffset’ = crLatch \cdot (crLen′ − 1)} \tag{Eqn.17} $$ $(d)$ In addition, we need to ensure that the address resets immediately after a string ends. Otherwise, we will read from a different string. For this reason, we need to introduce the following constraint $$ \mathtt{(1 − crLatch) \cdot lastHash} \tag{Eqn.18} $$ which, when combined with the previous constraints enforces the desired results.

The registers ${{crV}_{i}}$ and polynomial factors ${{crF}_{i}}$

Let us now turn to the registers ${crV}_{i}$ and polynomial factors ${crF}_{i}$ .

Consider the previous example, where the first element of the ‘output’ array is $$ \mathtt{0xff00111a6e6e1f02ef10} $$ Obviously, this element does not fit in a 32-bit register. So it needs to be split over three registers; ${crV}_{0}$ , ${crV}_{1}$ and ${crV}_{2}$ ; respectively as, $$ \mathtt{0x1f02ef10, 0x111a6e6e} \text{ and } \mathtt{0xff00} $$ Moreover, each byte has a corresponding weight $(2^{8})^{j}$ , for some $j \in {0, 1, 2, 3}$ , such that,

\begin{array}{r} 0 x 1 f 02 ef 10 = 0 x 10 \cdot 2^{0} + 0 xef \cdot 2^{8} + 0 x 02 \cdot 2^{16} + 0 x 1 f \cdot 2^{24} \\ 0 x 111 a 6 e 6 e = 0 x 6 e \cdot 2^{0} + 0 x 6 e \cdot 2^{8} + 0 x 1 a \cdot 2^{16} + 0 x 11 \cdot 2^{24} \\ 0 xff 00 = 0 x 00 \cdot 2^{0} + 0 xff \cdot 2^{8} \end{array}

Henceforth, we should reflect this in our state machine using the columns ${crF}_{i}$ and ${crV}_{i}$ for our previous example.

\begin{array}{lcccccc} aFreeIn & crLatch & {crV}_{0} & {crV}_{1} & {crV}_{2} & {crF}_{0} & {crF}_{1} & {crF}_{2} \\ 0 x 10 & 0 & 0 x 10 & 0 x 00 & 0 x 00 & 1 & 0 & 0 \\ 0 xef & 0 & 0 xef 10 & 0 x 00 & 0 x 00 & 2^{8} & 0 & 0 \\ 0 x 02 & 0 & 0 x 02 ef 10 & 0 x 00 & 0 x 00 & 2^{16} & 0 & 0 \\ 0 x 1 f & 0 & 0 x 1 f 02 ef 10 & 0 x 00 & 0 x 00 & 2^{24} & 0 & 0 \\ 0 x 6 e & 0 & 0 x 1 f 02 ef 10 & 0 x 6 e & 0 x 00 & 0 & 1 & 0 \\ 0 x 6 e & 0 & 0 x 1 f 02 ef 10 & 0 x 6 e 6 e & 0 x 00 & 0 & 2^{8} & 0 \\ 0 x 1 a & 0 & 0 x 1 f 02 ef 10 & 0 x 1 a 6 e 6 e & 0 x 00 & 0 & 2^{16} & 0 \\ 0 x 11 & 0 & 0 x 1 f 02 ef 10 & 0 x 111 a 6 e 6 e & 0 x 00 & 0 & 2^{24} & 0 \\ 0 x 00 & 0 & 0 x 1 f 02 ef 10 & 0 x 111 a 6 e 6 e & 0 x 00 & 0 & 0 & 1 \\ 0 xff & 1 & 0 x 1 f 02 ef 10 & 0 x 111 a 6 e 6 e & 0 xff 00 & 0 & 0 & 2^{8} \\ 0 x 55 & 0 & 0 x 55 & 0 x 00 & 0 x 00 & 1 & 0 & 0 \\ 0 x 73 & 1 & 0 x 7355 & 0 x 00 & 0 x 00 & 2^{8} & 0 & 0 \\ \dots & \dots & \dots & \dots & \dots & \dots & \dots & \dots \end{array}

Observe that registers ${{crV}_{i}}$ are actually cumulative up to the register’s maximal capacity of 4 bytes is reached, in which case the next reads are stored in the next ${crV}_{i + 1}$ register.

The registers ${{crF}_{i}}$ are responsible for correct positioning of each byte with respect to powers $(2^{8})^{j}$ , for $j \in {0, 1, 2, 3}$ , providing the decomposition stated above.

Lastly, observe that the rows corresponding to $crLatch = 1$ , store the complete result of the read in the registers ${{crV}_{i}}$ . These are the rows where validity of the read operation is checked via a Plookup.

Constraints pertaining to ${{crV}_{i}}$ and ${{crF}_{i}}$

The idea here is to compute a column ${crVC}_{i}$ defined by,

\begin{matrix} (Eqn.19) & {crVC}_{i} = {crV}_{i} + {crF}_{i} \cdot aFreeIn \end{matrix}

and then verify that the next state ${crV}_{i}^{'}$ coincides with ${crVC}_{i}$ whenever $crLatch$ is not equal to 1. This will confirm that the ${{crV}_{i}}$ registers are not only sequentially read, but are also correctly computed from the previous states. Hence, the following constraint needs to be added;

\begin{matrix} (Eqn.20) & {crV}^{'} = crVC \cdot (1 - crLatch) \end{matrix}

So far so good.

Now observe that the tuple $(crOffset, crF 0, crF 1, . . ., crF 7)$ is not totally arbitrary. In fact, it needs to be checked whether $crOffset \in {1, \dots, 32}$ and $crFi \in {1, 2^{8}, 2^{16}, 2^{24}}$ . This is done via a Plookup. That is, checking if the row corresponding to $crLatch = 1$ is contained among the previously computed table of constants having all possible combinations of the previous columns.

\begin{aligned} { \\ crOffset, \\ crF 0, \\ crF 1, \\ crF 2, \\ crF 3, \\ crF 4, \\ crF 5, \\ crF 6, \\ crF 7 \\ } in \\ { \\ k_crOffset, \\ k_crF 0, \\ k_crF 1, \\ k_crF 2, \\ k_crF 3, \\ k_crF 4, \\ k_crF 5, \\ k_crF 6, \\ k_crF 7 \\ }; \end{aligned}

Read operation and Main state machine¶

There are a few subtle details concerning the connection between the Read operation and the Main SM to be taken into account.

For instance, in order to avoid problems, reading from the last (probably smaller) block is not allowed. A constant column $r 8 Valid$ is therefore created specifically for checking if a read is done at the last block. So, $r 8 Valid$ will be 1 if and only if the current state is not at the last block. Hence, the Plookup in the Main SM’s PIL code (main.pil code; lines 663 to 676):

\begin{aligned} hashK + hashK 1 { \\ addr, \\ HASHPOS, \\ D0 * hashK + hashK1, \\ op0, op1, op2, op3, \\ op4, op5, op6, op7 \\ } in \\ PaddingKK . crLatch * PaddingKK . r 8 Valid { \\ PaddingKK . addr, \\ PaddingKK . len - PaddingKK . rem - PaddingKK . crLen + 1, \\ PaddingKK . crLen, \\ PaddingKK . crV 0 C, PaddingKK . crV 1 C, PaddingKK . crV 2 C, PaddingKK . crV 3 C, \\ PaddingKK . crV 4 C, PaddingKK . crV 5 C, PaddingKK . crV 6 C, PaddingKK . crV 7 C \\ }; \end{aligned}

Please note that these quoted code lines will differ with different versions. They should only be taken as examples for a particular code version.

Note that $HASHPOS$ is marking the position in the string of the byte where the reading starts. The Plookup shown above, maps the committed polynomial $HASHPOS$ in the Main SM to the linear combination of the committed polynomials; $len$ , $rem$ and $crLen$ ; of the Padding-KK SM as,

\begin{matrix} (Eqn.20) & len - rem - crLen + 1 \end{matrix}

Let us make use of the following example to clearly see why this linear combination works.

Example: Main SM and Padding-KK connection¶

Suppose we want to read bytes 2, 3 and 4 of the string $0 x 7766554433221100$ . The table of the reading, reflecting only the relevant columns, is as follows.

\begin{array}{lccccc} aFreeIn & len & rem & crLen & len - rem - crLen + 1 & {crV}_{1} \\ line 0 & 0 x 00 & 8 & 8 & 0 & 1 & 0 x 00 \\ line 1 & 0 x 11 & 8 & 7 & 0 & 2 & 0 x 00 \\ line 2 & 0 x 22 & 8 & 6 & 3 & 0 & 0 x 22 \\ line 3 & 0 x 33 & 8 & 5 & 3 & 1 & 0 x 3322 \\ line 4 & 0 x 44 & 8 & 4 & 3 & 2 & 0 x 443322 \\ line 5 & 0 x 55 & 8 & 3 & 0 & 6 & 0 x 00 \\ line 6 & 0 x 66 & 8 & 2 & 0 & 7 & 0 x 00 \\ line 7 & 0 x 77 & 8 & 1 & 0 & 8 & 0 x 00 \end{array}

Observe that, among the rows with $crLen = 3$ (the ones where the reading happens), only the row in $line 6$ contains the complete read-result, $0 x 443322$ , in the ${crV}_{i}$ column. That is, although $HASHPOS = 2$ , meaning the reading starts with byte 2 which is in $line 2$ , the reading is only complete in $line 6$ . And that’s the exact row where the linear combination works out to be

(len - rem - crLen + 1) = 2 = HASHPOS

Last update: January 17, 2024

Authors: avenbreaks