Snark Worker in Mina

1 Introduction

The Mina series of blogs includes:

Most blockchain protocols have only one type of node operator, usually called miner, validator or block producer, while Mina also has a second type of node operator, Snark Worker.

Snark Workers are important members of maintaining the health of the Mina network. Snark Workers are responsible for generating SNARK proofs for transactions in the network, thereby helping to maintain the succinctness of the Mina chain.

2. Why is Snark Worker needed?

Mina's unique property is the succinct blockchain. When each block producer proposes a new block for the network, it must also include the zk-SNARK of that block. So that the node can ignore all the historical data that has been solidified before, and only need to keep the SNARK.

However, in Mina, not only block producers are required to generate SNARK proofs for blocks, but also SNARK proofs for transactions. This is because the blockchain SNARK does not make any statements of the validity of transactions within that block.

For example, if the state hash in the current block header is a6f8792226..., a new block with state hash is received 0ffdcf284f..., the new block contains all transactions selected by the block producer and the corresponding metadata, and a new block corresponding to the new block is also received. blockchain SNARK proof to verify the following statement:
"There exists a block with a state hash 0ffdcf284f which extends the blockchain with a previous best tip with state hash a6f8792226."

Note that this statement does not have any life on the validity of the transactions in the new block. By doing nothing to trust the blockchain SNARK, we could be tricked by a malicious block producer who sent the block. Luckily, we have that raw block that verifies every transaction to make sure it's valid. But what about other nodes in the network that only receive proofs without validating transactions within each block?

To ensure that nodes can operate without trusting Mina, it is important that each node can verify the state of the chain without replaying transactions. To achieve this, a blockchain SNARK proof is not enough. It is also necessary to know that these transactions are also valid. Well, since SNARKs are very useful for this, a naive suggestion might be to generate a SNARK as each transaction comes in, and then combine them.

However, generating SNARK proofs is computationally expensive - if SNARKs are generated serially for each transaction, transaction throughput will be low and blocks will skyrocket. Also, in real-world transactions arrive asynchronously, making it difficult to predict when to perform the next item of work.

Fortunately, the following two properties of SNARKs can be exploited:

  • 1) Proofs can be merged: 2 proofs can be combined to form a merge proof.
  • 2) Merge is associative: regardless of the order of the combination, the final merge proof is the same.

These two properties of SNARKs allow us to take advantage of parallelization. SNARK proofs can be generated in parallel if proofs can be merged, regardless of the order of merging. The first generated proof can be subsequently combined with the generated proof. Think of it as a binary tree, with the bottom row (leaf) as independent transaction proofs, and each parent row as merge proofs. Combined with the root in turn, the root represents a state update performed by applying all the transactions.
In addition, since SNARK proofs are independent of each other, they can also be parallelized - that is, anyone can participate in the generation of SNARK proofs. The final result is that the distributed work pool is permissionless, and anyone with computing power can participate in the Mina network as Snark Workers, observe transactions that require SNARK, and contribute their computing power. At the same time, corresponding compensation will also be obtained through Snarketplace.

3. High Throughput with Slow Snarks

For details, see: High Throughput with Slow Snarks
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here
insert image description here

4. Snarketplace

The key to understanding Snark Work is:

  • Block producers use their block rewards to purchase snark work from snark workers.

There is no protocol for pricing Snarks, nor does it provide protocol-level incentives for Snark Workers to generate snarks. Incentives are pure peer-to-peer, dynamically established by a public marketplace called snarketplace.

One might ask, why do block producers need to buy SNARKs? The reason is that to ensure that the state in the Mina block header is valid, all transactions in the block need to be snarked. However, if we keep adding more transactions without snark them at the same rate, over time we accumulate work that can never be completed. To reach steady state equilibrium, we need to process work at roughly the same rate as the work increase rate.

Since block producers profit by including transactions in blocks (through transaction fees and coinbase transactions), they are responsible for offsetting transactions by purchasing an equal amount of completed snark work, creating demand for snark work. However, their priority is to buy snark work from snarketplace at the lowest price. Instead, Snark Workers want to maximize profits while selling snark work. These two roles play two sides of the market and over time create a balance for the snark work at market prices.

5. How to price snark work?

We expect the snarketplace to rebalance dynamically - eg following the simple laws of supply and demand. While in the bigger picture, each snark work applies to a different transaction, the snark work is largely a commodity (meaning, it doesn't matter which Snark Worker produces the commodity, it will be the same ). However, there are some nuances, so it might be helpful to shed some light on pricing strategy:

  • If the market price is X, it may be valid to sell snark work (like X-1) for less than X, provided it is profitable after deducting operating expenses.
  • Block producers are incentivized to buy more snark work from the same Snark Worker because they only need to include a fee transfer transaction in the block.
    • Basically, the way block producers pay Snark Woker is through a special type of transaction called a fee transfer. Block producers are motivated to minimize the number of fee transfers, as each transaction is a discrete transaction that needs to be added to the block (and thus offset by more snark work). So the best case is to buy a bundle of snark work from the same Snark Worker.
  • Some snark work will be more important than others as it will free up memory for the entire tree (see the video above for more details). This is achieved through different work selection methods. Currently, the two methods supported natively are sequential and random. However, neither approach takes advantage of dynamic markets, an area of ​​improvement where the Mina community can develop solutions.

Since all the data on snarks and prices is public, there are several ways to check the snarketplace. An example is using the GraphQL API, other options include using the CLI, or rolling a custom solution that tracks the snark in the snark mempool.
Stay tuned for a more detailed analysis of the snarketplace dynamics. We will also publish an economic white paper soon to provide more context.

References

[1] Mina Doc——Snark Workers
[2] What are SNARK Workers and the Snarketplace?
[3] Guide to Snark Work
[4] High Throughput with Slow Snarks
[5] SNARKs and Snark Workers FAQ

Guess you like

Origin blog.csdn.net/mutourend/article/details/124300155