1 Introduction

For the previous blog, see:

Snark Worker in Mina

The Scan State in Mina is a data structure used to decouple the generation of transaction SNARKs, which can be generated by Snark Worker instead of block producers.

Since block producers no longer need to generate transaction SNARKs, block production time can be kept constant regardless of transaction throughput. In addition, the scan state data structure supports parallelized generation of transaction SNARK proofs, which can be done by multiple competing Snark Workers.

The scan state consists of a forest of full-binary trees, where each node of these trees is a job that requires a snark worker to complete. The scan state periodically returns a single proof from the top of a tree that attests to the correctness of all transactions at the base of the tree.

Block producers include the issued ledger proof in the blockchain SNARK they generate, proving that the current state of the chain is valid, and certifying the validity of all transactions contained in the snarked ledger.
Therefore, regardless of transaction throughput, the block time may remain the same, and the scan state can be adjusted to match the desired transaction throughput.

Note: In steady state, when all slots are filled and all required proofs are complete, each block emits a ledger proof.

2. scan state parameter

The scan state mainly has the following parameters:

1) transaction_capacity_log_2: defines the maximum number of transactions that can be included in a block:max_no_of_transactions = 2^{transaction_capacity_log_2}
2) work_delay: Ensure that there is enough time for the snark workers to complete the snark work. Block producers will not be able to include any transactions without a completed proof available. With work_delay, you can define the maximum number of trees allowed in the scan sate: max_number_of_trees = (transaction_capacity_log_2 + 1) * (work_delay + 1) + 1.

The maximum number of proofs allowed in each block is:
max_number_of_proofs = 2^{transaction_capacity_log_2 + 1} - 1

The above constraints on scan state ensure that each block skill releases a proof, and the merge node that is to be updated after adding proofs corresponding to its children is always empty.

When the maximum number of transactions is determined, the transaction throughput can be dynamically adjusted. Scan state can handle unlimited transaction throughput at the cost of logarithmically increasing transaction proof latency.

3. including transactions

Block producers can include the maximum number of transactions defined in scan state when building blocks. When including transactions, choose any available transaction fee and pay yourself a coinbase reward. Every transaction added by a block producer is converted into a new base job and added to the scan state.

For each additional transaction, block producers must include an equal number of completed snark work that corresponds to a sequence of jobs that already exist in the scan state. These completed jobs, when added to the scan state, create new merge jobs except when it is for the root node, in which case the proof is simply returned as a result.

Block producers do not complete the snark work themselves, but buy completed work from any snark workers according to the bidding in the snark pool.

4. Scan state example

Suppose the parameters of scan state are: max_no_of_transactions = 4, work_delay = 1, which means there can be a maximum amount of work to complete equal to 7 and a maximum number of 7 trees.

You can use the following command to view the content of scan state:

mina advanced snark-job-list

The basic process is:
[ BIndicates base job, Mindicates merge job, and the following numbers indicate the order of adding to scan state. ]
[Orange: Indicates pending work to be completed by Snark Workers;
Green: Indicates completed work, Snark Workers will submit the completed work to the snark pool. There may be multiple Snark Workers to complete the same work, however, the block producer may only purchase the one with the lowest fee in the snark pool. ]
【Snark work is bundled into a work package typically containing two workIds, with the exception of the final root proof of a tree. Prorated work for a transaction is two proofs, so this ensures the equality of transactions included and snark work to be purchased .]

1) During genesis, the scan state is empty.
2）Block 1: A block producer includes four transactions into the scan state labeled B1. These transactions fill the base of the first tree.
3）Block 2: At the second block, a block producer adds another four transactions (B2). These are added to a second tree, once again filling the base. There are no proofs required due to the work delay of 1 block.
4）Block 3: At the third block, a block producer adds four B3 transactions to the third tree but must include four proofs for the first tree. As a result of including these completed base proofs, two new M3 merge jobs are created.
5）Block 4: For the fourth block, a block producer adds another four transactions (B4) to the base of the fourth tree. They must include four proofs corresponding to the work added in block 2. Again, two M4 merge jobs are created as a result.
6）Block 5: In the fifth block, another four transactions are included to fill the base of tree five (B5), and six proofs must be included (B3s and M3s). The M3 merge jobs result in a final pending merge job for the first tree (M5).
7）Block 6: In the sixth block, another four transactions (B6) are added, filling the base of the sixth tree. Six proofs are included (B4 and M4), and three new merge jobs are created (M6).
8) Block 7: In the seventh block, a further four transactions (B7) are added by the block producer filling the base of the seventh tree. Seven trees are the maximum number of trees according to the specified scan state constants. The maximum number of proofs (7) are included (B5 and M5). These included proofs create three new merge jobs (M7), and additionally, the top M5 proof is emitted from the scan state.

The proof released by the first tree is the corresponding Block The ledger proof of the transaction added in 1. At this time, all the contents of the first tree will be cleared to create space for additional transactions.
9) Block 8: In the eighth block, the block producer adds two transactions (B8) and includes 4 (B6) proofs. These included proofs result in two new merge jobs (M8). Note that only four proofs are required for adding two transactions. [Note that at this time, when adding 2 transactions, only 4 proofs are required. 】
10）Block 9: In the ninth block, the block producer adds three transactions (B9). Three proofs (M6) are required for the slots to be occupied in the currently unfilled tree. Four proofs were added in the previous block, and therefore only three more needs to be done (given the maximum work is 7). The M6 proof from tree two is returned as the ledger proof. The third B9 transaction goes into the now empty tree, and two B7 proofs are added.
11）Block 10: In block ten, the block producer adds four transactions and, as a result, includes seven proofs (B7, M7, and two B8s).
12）Block 11: In the eleventh block, the block producer adds three transactions (B11) and completes five proofs (B9, B9, M8, M8, M9) in that order. In addition, the M9 ledger proof is returned from the fourth tree.

5. Integrate with Snark Pool

The newly added job to the scan state is the pending job of Snark Workers. Snark Workers complete the required transaction SNARKs, and do not list prices for the work they complete. When the node receives and passes the verification of the completed work and the price is the lowest, the node will add the completed work to its local snark pool.
[When multiple Snark Workers complete the same work, only the one with the lowest fee will be included in the snark pool. ]
The current snark pool can be viewed through GraphQL or the command line:

mina advanced snark-pool

When the block producer includes completed proofs in the block to offset any transactions they add, the block producer needs to purchase the corresponding work from the snark pool. For example, still continuing the example in Section 4, taking the new block 12 as an example, if the block producer needs to add 3 transactions in Block 12, including a coinbase, a user payment and a fee transfer to the snark worker, the block production The user needs to purchase 3 completed snark works, because each snark work contains 2 workIds, so it corresponds to 6 proofs (1 B9 proof, 3 B10 proofs, 1 M9 Proof and 1 M10 proof).
During block generation, the snark pool may include completed work, and the best bid for the desired job (0.025, 0.165, 0.1, and 0.5 in the example).
insert image description here
Block producers will consider the price of available work before choosing a transaction. The first transaction that the block producer will add is the coinbase transaction (corresponding to coinbase reward). If the transaction fee cannot cover the snark work fee that it needs, the block producer will not add the transaction to its block. Block producers will not buy work unless it is profitable.
When the need is for unresponsive completed snark work to be purchasable, the corresponding transaction is also not added to the block. This may result in an empty block, and of course there may be no transactions to be added, which means there is no incentive for block producers.

References

[1] Scan State

appendix

The Mina series of blogs includes:

Scan State in Mina