Smart Contracts Coming to Mina
zkApps will enable privacy-centered applications on Mina Protocol
Programming note: This is the second 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 its current state, Mina Protocol is already powerful, using zk-SNARK technology to represent an entire blockchain (1000 GB for Ethereum as of Q3 2022) in one single SNARK (100 MB). However, its functionality still resembles that of Bitcoin: primarily useful for payments but limited in other respects.
The zkApps update will bring smart contracts to Mina and boost its functionality to become equivalent to Ethereum rather than Bitcoin. In addition, these zkApps will use zk-SNARKs to shield user data and make smart contract transactions (somewhat) private, something Ethereum cannot do. The zkApps update is currently live on the Berkeley testnet and set for launch on the mainnet in early 2023. In this post, we dissect how zkApps fit into Mina.
Overview
We can start reasoning about zkApps by first reviewing Ethereum smart contracts.
A smart contract may start out as a program written in Solidity, which is then compiled into EVM bytecode.
Each smart contract is then deployed to an address where its EVM bytecode lives on-chain.
Each smart contract has persistent memory, called “storage”, available to it on-chain which transactions may modify.
A user can interact with this smart contract by creating a transaction specifying the address, function and input data.
The user then propagates this transaction across the mempools of nodes in the P2P network for inclusion in the blockchain.
Each node will execute the smart contract transaction using the input data to check that the transaction is valid.
If the execution of this transaction runs into a problem (e.g. it reverts or runs out of gas), the node throws it out. Otherwise, it will attempt to include the transaction in its next block.
The basic premise of zkApps follows this logic, but differences exist which allow zkApps to preserve user privacy and integrate into Mina’s SNARK-based blockchain:
On Mina, a zkApp can be written in the SnarkyJS language, which is then compiled into a zk-SNARK circuit C with corresponding prover P and verifier V. This circuit has public information X and private witness W as input, such that the prover wants to show the verifier that they know W such that C(X, W) = 0 through a SNARK proof (I may sometimes just say SNARK for brevity). *
* This is technically the framework for the Groth ‘16 SNARK, a much simpler system than Mina’s SNARKs, but sufficient for abstractly reasoning about zkApps.The source code of a zkApp does not live on chain. Instead, the verifier V is deployed to an address. The source code is distributed off-chain to the desired users of the zkApp, which can be the general public or a select few individuals.
Each zkApp can have only a small amount of persistent memory, or on-chain state, which must be part of the public information X of any zk-SNARK, since each node must store a copy of it.
A user can interact with this zkApp by taking on the role of the prover P.
First, specify the address, function, and input data. In this case, the input data includes some input data the user wants to be public (X), and some input data the user wants to be private (W).
The zkApp’s previous on-chain state and updated on-chain state after this transaction also belong in X.
Then, compile a zk-SNARK showing that the function call to the zkApp at this address with this input data (X, W) results in a valid updated on-chain state.
Note that, without the source code of this zkApp, the user cannot create a valid zk-SNARK. Thus, a zkApp can attempt to hide its source code from parties it does not want to interact with it, like MEV searchers.
The user then propagates this transaction, now a zk-SNARK, across the mempools of nodes in the P2P network for inclusion in the blockchain.
Each node will take on the role of the verifier V to check that the zkApp transaction zk-SNARK is valid.
If the verifier V rejects this zk-SNARK, the node throws it out. Otherwise, it will attempt to include the transaction in its next block. This also means updating its on-chain state for this zkApp.
What part of this zkApp is private?
Mina’s zkApps offer some, but not complete, privacy.
Persistent memory (on-chain state): Not private, as each node records this on-chain state in its raw form, not as a zk-SNARK.
Input data: Private, because the user can choose to place it in the witness W. However, the resulting changes to on-chain state are public, which may betray the nature of the input data.
Source code: Private, because it is not stored on-chain. However, users of a zkApp can share it with anyone and thus gradually make the source code public.
While the privacy of zkApps is not as all encompassing as that of, say, Zcash, this degree of privacy is already very powerful. For example, if there is a zkApp that issues loans to users with a high enough credit score, each user does not have to make their credit score public to the blockchain in order to take out a loan. Instead, only a zk-SNARK proving the user’s credit score is high enough for this loan will be propagated to the blockchain, while the user’s raw credit score remains hidden as the witness W portion of the input data.
What is the vision for zkApps?
Currently, zkApp functionality is available to developers on the Berkeley testnet (here is a guide to getting started). There are endless use cases for zkApps, most of which have not been thought of yet, but I will share one very cool use case here.
Imagine you are a decentralized exchange on, say, Ethereum, and you want to introduce some KYC (know your customer) on-boarding procedures so US-based users can compliantly interact with your protocol. If you were to build this off-chain, that would require centralization. If you were to build it on-chain, anyone who goes through the KYC process would have their personal documents (e.g. passport, driver’s license) broadcast onto the entire Ethereum network!
An alternative method would use Mina to do the KYC portion of on-boarding:
Bridge the on-boarding process to Mina Protocol, where you have a zkApp that does KYC procedures.
The user sends their personal documents as private input data (X) to the zkApp, and the resulting zk-SNARK proof is propagated as a transaction on the Mina blockchain.
Bridge the on-boarding process off of Mina Protocol with this zk-SNARK proof showing that KYC was successful.
This use case leverages composability of different blockchains so that Mina Protocol is used where it shines brightest: handling privacy-sensitive logic for any application. In fact, the Nil Foundation has already built a bridge for current Mina to Ethereum, so it will only be a matter of time before a bridge for zkApp Mina to Ethereum is up!
With this introduction to zkApps on Mina, we finally have all the context required to analyze the forms of MEV present on Mina, compared to other blockchains.