Programming note: This is the first of a three part series on Mina Protocol, its new zkApps update, and MEV on Mina. Feedback is encouraged, as my content will include mistakes.
I recently became involved in Mina Protocol, an L1 blockchain that uses zk-SNARKs to enable a whole new set of applications centered on user identity, privacy, and security. Currently, their blockchain uses Proof of Stake and a recursive SNARK mechanism to record new blocks, and they are in the process of launching zkApps to their mainnet, which will bring smart contracts to Mina.
While Mina shares a lot of similarities with other blockchains, especially Cardano, its consensus mechanism, Ouroboros Samisika, also includes several SNARK-based innovations that are very interesting to dissect. A big selling point of Mina is that its blockchain is “constant size”, requiring only ~100 MB to host a full node no matter how long the blockchain gets. Meanwhile, other blockchains like Ethereum require 1000 GB (as of Q3 2022) to host a full node, and that number grows as the blockchain lengthens.
My goal here is to share what I discovered about the MEV landscape on Mina, which is unique due to Mina’s SNARK technology. However, there is a lot of pre-requisite knowledge of Mina and its zkApps required to understand my MEV analysis, so I decided to split this up into a three part series. In this post, we explore how Mina Protocol uses SNARKs in its consensus mechanism to achieve this “constant size” milestone in blockchain innovation.
Overview
We start with a cursory overview of how consensus on Mina Protocol currently works (for the full explanation, read their whitepaper). I find that the best starting point for reasoning about the current Mina Protocol is to imagine a version of Bitcoin (so only payments, no smart contracts) that is secured by Proof of Stake.
Now, the big difference is that Mina represents its blockchain as a single recursive SNARK. Each time a new block is added to the Mina “blockchain”, it is actually compiled into a SNARK. The SNARK for this block and the recursive SNARK of the previous state of the blockchain are then combined and compiled into a new recursive SNARK representing the new state of the blockchain with this block included (hence the “recursive” nature of the SNARK).
This feature means that nodes on the Mina network do not need to store a blockchain that grows with time. Instead, each node just stores the single recursive SNARK which remains constant in size, making Mina an incredibly lightweight blockchain to run. We now break down the big questions for how this SNARK feature works.
I. What is being compiled into a SNARK?
Each time a new block is being added, there are actually two types of SNARKs being created. First, each transaction selected for that block is compiled into a SNARK which proves the validity of the transaction (e.g. valid signature, no double spent). Second, the block is compiled into a SNARK which (1) checks that each transaction’s SNARK is valid, (2) proves the validity of the block construction (e.g. valid proposer, correct block header), and (3) proves this block is a valid continuation of the blockchain represented by the previous recursive SNARK. This SNARK is thus recursive because of (3), and it represents the updated state of the blockchain.
II. Who builds each SNARK?
Each time a block proposer decides the transactions to be included in the next block, they are responsible for building the second SNARK, the recursive one that represents the updated state of the blockchain. However, they will outsource the construction of SNARKs validating each selected transaction to a group of users called SNARK workers, who compete inside of a SNARK marketplace for the chance to compile transactions into SNARKs.
III. When does each SNARK get built?
Your first intuition for a timeline of events may be:
The Proof of Stake protocol randomly selects the next block proposer.
The block proposer selects some transactions from its mempool (perhaps the ones paying the highest fees) to include in the next block.
The block proposer pays SNARK workers on the SNARK marketplace to compile each transaction into a SNARK.
The SNARK workers produce SNARKs for each transaction.
The block proposer combines those SNARKs and the block into a recursive SNARK representing the new state of the blockchain.
However, this timeline can introduce some issues, namely that a block proposer may be incentivized to choose transactions that are cheaper to SNARK for their block, thus effectively censoring more complex transactions. To help mitigate this misalignment of incentives, the true timeline of events is closer to:
The Proof of Stake protocol randomly selects the next block proposer.
The block proposer selects some transactions from its mempool to include in the next block.
That block of transactions is added to a temporary blockchain only consisting of blocks whose transactions have not yet been compiled into SNARKs. This temporary blockchain is short, but not empty.
The block proposer pays SNARK workers on the SNARK marketplace to compile the transactions from the oldest block on this temporary blockchain into SNARKs. Thus, the block proposer is paying for transactions that are not from their block to be compiled.
The SNARK workers produce SNARKs for those transactions.
This oldest block is removed from the temporary blockchain.
Once the proposer’s block is the oldest on the temporary blockchain, its transactions will be compiled into SNARKs, paid by some future block proposer.
The block proposer combines those SNARKs and the block into a recursive SNARK representing the new state of the blockchain.
This timeline means that the block producer is incentivized to include transactions, whether cheap or expensive to SNARK, in their block: the price for SNARK workers to build those transactions will be paid by a future block producer, not them.
A nice diagram of this timeline from the whitepaper is included below.
This SNARK-based blockchain is very unique, and allows Mina Protocol to be hosted on much more lightweight devices (possibly even inside web browsers) than other blockchains. This concludes the first of our three part series on Mina Protocol, its new zkApps update, and MEV on Mina. Stay tuned for the next segment!