Mina’s architecture is built around the ability to maintain a succinctly verifiable state, setting it apart from traditional blockchains that grow endlessly in size with each transaction. At the heart of this design are recursive SNARKs, which encode the entire chain history into one short, easily verifiable proof.
And SNARK workers are a key component of the Mina Protocol: they provide the fuel for the chain’s succinctness. They enable Mina to achieve scalability without sacrificing its lightweight design. This blog will break down the unique mechanisms that make this possible, from recursive proof generation to the innovative Snarketplace and scan state systems.
Proof recursion in Mina
In Mina, each transaction is proved in a SNARK. Formally, the resulting proof is a statement that says: “The prover knows a valid transaction such that this new ledger state is valid for the chain.” Such a proof requires some computation to be created, but is very inexpensive to verify.
The magic happens with the recursion: two proofs can be combined in one proof called a merge proof. Such a proof is a statement that says: “The prover knows two valid proofs that verify.” It can combine either two transaction proofs or two other merge proofs together. Hence it is possible to merge any number of proofs into one (by merging the merge proofs), at the cost of proportional computational work. The validity of the merge proof implies the validity of all the underlying proofs. This is the key to succinctness in Mina.
Assume you want to include four transactions in a block. Each of these transactions needs to be proven. Instead of including four proofs for each transaction, the chain builds a tree: it places these transaction proofs as leaves, computes merge proofs pairwise, and then computes merge proofs for the merge proofs until there is only one proof that contains all the others. This last proof is called the ledger proof and ensures the validity of all four transactions. The ledger state corresponding to this proof is called the snarked ledger.
With this mechanism, a block producer that wants to include four transactions needs to include four transaction proofs, two merge proofs, and one ledger proof. As generating proofs requires extensive hardware, the chain would be considerably slow if the block producer had to generate them by itself. Even if there is room for parallelization among the four base proofs and the two merge proofs, it would still need to wait for the n-layer of proofs to be able to compute the n+1-layer.
To tackle this issue, the Mina protocol leverages two mechanisms: delay and parallelization.
How the network leverages the decentralized efforts of SNARK workers to achieve this goal
Note: in Mina, a SNARK work refers to a proof or to the production of a proof that is powered by a snark worker.
Snarketplace: decentralizing and parallelizing SNARK work
To maximize transaction throughput, parallelization, and decentralization, proof production is delegated to another type of node: SNARK workers. When a new block is created, the newly added transactions and merges for previously included proofs are up for proving. A SNARK worker will then set a price, generate proofs and broadcast them for block producers to purchase. This is Mina’s Snarketplace.
Scan state: delaying providing a consistent queue of work
To increase transaction throughput and parallelization, a delay is allowed between transaction inclusion and proof inclusion. This means that proofs are included in a later block than their underlying transaction.
When a block producer wants to include transactions, instead of providing proofs for these transactions, it must include an equivalent quantity of snark work that corresponds to past transactions included in some previous block. The newly included transactions are added as pending work to the scan state and proofs for these (aka completed works) will be included in future blocks.
The scan state specifies which SNARK work must be included at each block. It works as a queue of required work, described in detail here: https://docs.minaprotocol.com/mina-protocol/scan-state.
If none of the work required is available on the Snarketplace or if the available works are too expensive, then the block producer won’t be able to include coinbase transactions as well, thereby losing all block rewards. Hence SNARK workers, by providing work on time at a fair price, form an important part of the Mina network.
In Conclusion
Mina’s architecture showcases how recursive SNARKs and decentralized proof production come together to maintain a succinct, verifiable blockchain. By offloading proof generation to SNARK workers via the Snarketplace and using the scan state to queue work, the protocol achieves both efficiency and decentralization, enabling Mina to scale while keeping its state succinctly verifiable.
This design not only ensures Mina’s succinctness but also highlights the potential for collaboration between block producers and SNARK workers in achieving it. If you’re interested in contributing to this process, you can learn more about running a SNARK worker in the Mina documentation or in this Guide for SNARK Work.