In September 2021 , nil foundation was awarded a grant by Etherum & MINA foundation to build a verification for MINA’s zk-SNARK on EVM. They have done a fantastic job to rapidly bring the solution close to launching on mainnet.
While we are on the cusp of this moment, this article we will take a look at how this bridge works and what will it bring to dApps and zkApps.
A Primer on Bridges
L1 protocols work with a set of trust assumptions to guarantee security. ex: consensus algorithm mandates block time of 10 mins in bitcoin.
Due to some these assumptions , it is harder for two separate blockchains to communicate to each other. I.e if you wanted to read a users balance (or any other state) on solana blockchain in an ethereum smart contract , this is not possible as their assumptions (and networks) are not compatible.
Thus in order for two to communicate to each other , a software construct of bridge is used.
A bridge can be used to:
Transfer assets between networks
Ex: Avalanche — Ethereum Bridge. This is the most widely used functionality to take assets on one network and transfer them to another one. i.e send ETH from Ethereum network to Avalance. This ETH can further be used to trade on Avalance Dex.
Transfer messages between networks
Ex: Celer’s- Interchain message passing . This allows a more generalised used case ,to expand the previous example where instead of bridging assets and going to a dex manually, dApps can use a solution like IMP and both actions of can be done in a single UX transaction (and the software takes care of the rest in the background).
Bridges have a different models and trust assumptions based on who operates them and how. To summarise entities relevant to the discussion they can be:
[Trusted] External validators & Federations : There is usually a group of validators that monitor a “mailbox” address on the source chain and, upon consensus, perform an action on the destination chain.
[Trustless] Light clients & Relays : Actors monitor events on the source chain and generate cryptographic inclusion proofs about past events that were recorded on that chain.
Interoprability Trilemma
Similar to the Scalability Trilemma, there exists an Interoperability Trilemma in the Ethereum ecosystem. Interop protocols can only have two of the following three properties:
Trustlessness: having equivalent security to the underlying domains.
Extensibility: able to be supported on any domain.
Generalizeability: capable of handling arbitrary cross-domain data. [src]
nil Foundation’s MINA bridge.
nil Foundations bridge to MINA is Trustless and Generalizable.
MINA uses recursive zero knowledge proofs which allows its chain proof to be under 22kb, thus enabling users to quickly and directly access the current state from their smartphone and other blockchains.
nil Foundation’s bridge, enables the entire state verification of MINA protocol in Ethereum
A full Mina Protocol state in-EVM verification means it will be possible to bring everything that happens inside of the Mina chain to Ethereum, including financial applications, provable computations, and much more.[src]
It is fair to say this is not just a bridge, but almost a zero knowledge layer to Ethereum.
The bridge is currently only one way- i.e MINA state can be read on Ethereum , but not the other way around.
Recently , nil foundation released a demo on how the bridge works.
This is done in following steps:
- Retrieve MINA state proof and the verification key.
- Generate an Auxiliary proof for the state received
- Post the Auxiliary proof to Ethereum blockchain , where a a smart contract will update only if valid.
Due to very high gas costs regarding verifying the state proof in EVM, the currently solution , generates and posts and auxiliary proof (which is the proof of the successful validation of the proof.). This is proven to be as secure of the proof itself.
This auxiliary proof can be posted by any one and incorrect proofs will be rejected on ETH. There is no requirement to setup a infrastructure for this and eventually , all of this should be possible via a browser using MINA light client nodes.
For the curious this is a nice chat between Mikhail Komarov— nil & Evan Shapiro — Mina which discuss some intricacies of the solution; summarised below:
- The proof requires no trusted setup.
- The bridge will be extended to other L2 ZK based solutions like Starknet/zkSync (but will require tweaking as current transpilers do not generate the most gas efficient code)
- The bridge can be readily deployed to any other EVM based chain. ex: Avalanche/Polygon .Optimistic rollups which inherit EVM like Optimism/Arbitrum are also ready to integrate.
- Possibly in the future we could see this for non-EVM chains like Solana
- Creating bi-directional trustless bridges is a tricky (ETH-> MINA , Starknet->MINA) as the source chains need to have a verifiable proof which can be added to a zkApp to MINA. This is still under research.
Let’s take an end to end example of how wrapped MINA — asset transfer can be created on Ethereum using the bridge.
- [ETH] A Wrapped MINA contract on ETH will be created which will be the minter.This contract has a MINA address where a user will deposit funds into.
- [MINA] User deposits funds into address above on MINA blockchain
- [MINA] Deposit transaction gets committed
- [ETH] Auxiliary Proof of MINA state is submitted to ETH
- [ETH] MINA state proof is validated and confirmed
- [ETH] Wrapped MINA Contract is called which uses the proof & validates the balance & mints Wrapped MINA on Ethereum
Currently , the proof only has a copy of the MINA state hash. So any consumer on ETH will currently need to send the merkle path of the account to use against the state hash in the input. However , future updates are planned which will store the full state tree of MINA on ETH and will be optimised for access.
Pseudo code would resemble as follows :
function mintWMINA( merkle_path_of_mina_account) public {
// read proof status posted to verifier on eth contract
// validate against merkle path input
//Mint wMINA to caller
}
Let us try to tackle a more generalised example (teller finance)
- User has an account on a credit score checking site
- [MINA] A zkApp on mina verifies your credit score > 700 and publishes proof on MINA zkApp
- [MINA] credit score proof transaction gets confirmed.
- [ETH] Auxiliary Proof of the MINA state is sent to ETH.
- [ETH] MINA state proof is validated and confirmed
- [ETH] A dApp on ETH can disburse a loan to the user by checking you meet the credit score requirements.
MINA transactions are private by default , thus your data is never stored on MINA , but rather the proof of your credit score is. This data can now be consumed by any other dApps.
It is important to note here , the proof submitted to MINA brings the entire state of MINA network to ethereum, thus any other application/user can reap the benefits as well.
On Forks and Finality
Forks are a common occurrence in blockchains as they are distributed and decentralised networks. Chains thus have a notion of finality. I.e the transaction is only confirmed and set in stone after a few blocks have built on top.
Bitcoin has a finality of roughly 6 blocks ~ 1 hour.
Finality in MINA currently is as below with a recommendation of 15:
The current implementation of the bridge , does not take into account all forks on the MINA network, however this is planned in future upgrades and design phase is nearly completed.
This does raise an interesting question , as to when should the data be considered safe to be used on other side of the bridge. The answer is some where above. At-least 8 blocks need to pass before data can have confidence guarantee to be used in ETH.
Let us take another scenario into account which deals with Forks.
Assume a juicy opportunity exists at the end of Block#1. All the next three block producers could try to extract this for themselves by building directly on top of Block#1 and by-passing the competition. These forks eventually do get resolved , however , it poses an interesting question which of the forks from this data can used on the ETH side of the bridge? What fork/balance should the contract trust?
Answer —Finality.
Closing thoughts
This enables all ETH dApps to be able to use MINA to run computations out of bands but have it verified in the ethereum blockchain and/or leverage any zkApps which are deployed on MINA. Higher finality times on MINA does mean, at the moment , it will be well suited for data which does not mutate quick. Once the finality improves, it will open up interesting applications along with launch of MINA’s zkOracles.
For MINA , this enables a growing ecosystem, positioning itself to become the de-facto ZKP based layer of not only Ethereum , but for any EVM chain for a start and beyond.
Design paper for the bridge can be found here
Special thanks to Mikhail Komarov from nil foundation for technical clarifications!
Mina protocol ecosystem is growing rapidly ;to keep up to date please take a look at MinaCrypto & subscribe to the newsletter.
References:
