Programming note: This is the last 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.
In his mev.day talk, Phil Daian, co-founder of Flashbots, stated that MEV is fundamental to blockchains, and thus the role of a user should include auditing L1s and protocols to understand the possible negative externalities caused by MEV and how to redesign around them. Now that we understand the way Mina Protocol and its zkApps work, we can analyze the forms of MEV that Mina prevents, mitigates, and enables compared to other L1 blockchains.
MEV on Current Mina
Despite the SNARK-based innovations in the blockchain, Mina in its current form has largely the same MEV landscape as any PoS blockchain that only supports payments. The transactions still gather in public mempools, validators are selected using verifiable random functions (VRF) based on stake (if multiple validators are eligible, there is a deterministic tiebreaker available), the validators still control sequencing within blocks, and the consensus protocol still defers to the longest chain when conflicts arise. A sampling of MEV opportunities on current Mina:
Block re-orgs
This form of MEV occurs when a validator purposefully ignores a latest block in favor of its own block, and convinces the rest of the network to orphan that other block. This is easiest to achieve if a validator happens to propose two blocks in a row:
The blockchain has height 99, and validators A and B are both eligible to propose the next block for height 100.
Suppose validator A should win the tiebreaker. When validators A and B both propose their blocks for height 100, the network gradually propagates validator A’s block, as intended.
However, if validator B is in line to propose for height 101, validator B could instead ignore A’s block for their own block at height 100 when building for height 101.
The network gradually propagates validator B’s block at height 101, which built on validator B’s block at height 100 rather than validator A’s block. Thus, validator A’s block at height 100 has been orphaned despite winning the tiebreaker.
Transaction ordering
This form of MEV occurs when a validator orders the transactions they plan to include in their block to their own benefit. This is true for most, if not all, other major blockchains like Ethereum and Bitcoin.
Denial of service (DoS) attack by SNARK workers
The reliance of Mina on a SNARK marketplace to compile each transaction into a SNARK introduces a new form of MEV available if SNARK workers collude. Namely, if all SNARK workers agree to not compile a certain transaction into a SNARK, it prevents the Mina blockchain from growing.
However, this form of MEV requires collusion by 100% of SNARK workers, and the supply and demand structure of the SNARK marketplace means the profit for that SNARK balloons the longer that it stays uncompiled. Thus, the incentive for a SNARK worker to defect increases over time until some SNARK worker compiles the transaction into a SNARK, thus ending the DoS attack.
More complex MEV
Since Mina Protocol currently only supports payments, more complex forms of MEV like arbitrage or liquidations that require smart contracts are not present.
MEV on zkApp Mina
With zkApps, Mina will have smart contract functionality, which introduces a new set of MEV opportunities that resembles what can be found on Ethereum.
Front- and back-running with source code
Recall that zkApps only exist on the Mina blockchain in the form of a verifier V. The source code does not live on-chain, but if a validator has access to the source code, then most forms of front-running and back-running MEV become available. Even though the input data and internal logic of a zkApp transaction are shielded by a zk-SNARK, changes to on-chain state are public, and thus enable MEV like:
Sandwich attacks: This form of MEV typically happens on a decentralized exchange (DEX) when a large swap order enters the mempool. A validator would notice the changes in the token reserves, stored in public on-chain, as part of the SNARK submitted by the zkApp. They could thus insert front-running and back-running swap orders to “sandwich” this large swap order, profiting from the increased slippage now incurred by the swap order.
Back-running: This form of MEV occurs when a zkApp transaction appears in the mempool that would alter the on-chain state of a zkApp to allow for a profitable transaction to occur. This transaction could be the opening of a free NFT mint, after which transactions minting those NFTs could be profitable. This transaction could also be the oracle price update for a lending protocol, after which some outstanding loan would be under-collateralized, allowing for a keeper to trigger the liquidation of that loan for a small profit. A validator would notice the change to on-chain state as part of the SNARK submitted, and thus back-run this transaction by inserting their own transaction immediately after it but before all the other transactions aiming to profit from the same opportunity.
Front- and back-running without source code
If a validator does not have access to the source code for a zkApp, it may still be possible to reverse-engineer some aspects of the zkApp, such as whether it is a token swap pool, or perhaps if an incoming transaction is an important oracle update. However, it is now impossible for the validator to insert their own transactions to take advantage of any MEV opportunities, because they cannot produce a valid SNARK of that zkApp transaction without the source code in hand. In this way, Mina uniquely enables a zkApp to be (weakly) exclusive in building its audience without giving it the ability to censor transactions.
Generalized front-running with source code
Generalized front-running is a form of MEV where a validator:
Receives a transaction in its mempool.
Detects during the execution of that transaction that it is profitable for the sender of the transaction.
Recognizes that the transaction could be copied to make a profit for the validator.
Copies the transaction and inserts it immediately before the original transaction.
On Mina, steps (3) and (4) are very difficult to achieve because the input data and logic of the original transaction are shielding behind a zk-SNARK, so methods like simulating the transaction or symbolically executing the transaction do not work. In this respect, zkApps on Mina mitigate a form of MEV that is common on L1s like Ethereum.
Conclusion
There are some clear differences in the MEV present on Mina Protocol compared to other L1 blockchains. Overall, the SNARK technology introduces one new form of MEV (DoS by SNARK workers), but prevents one form of MEV (generalized front-running), which is arguably a net improvement upon the MEV forms allowed by most other blockchains.
Equally important is a note of all the potential forms of MEV that could come with a new, complicated technology like SNARKs which Mina has averted. The design of the SNARK marketplace and separation of validator from SNARK worker both effectively eliminate possible MEV vectors for SNARK workers other than a DoS attack, as they have no control over transaction ordering or inclusion. In addition, the design prevents validators from developing perverse incentives based on the ease of SNARK compilation for some transactions over others.
As the zkApps rollout continues for Mina Protocol, it is important to continue monitoring and analyzing the MEV landscape on Mina Protocol to mitigate new forms of MEV that may emerge.