Bridging Mina to Ethereum via =nil; Proof Market

Introduction

As Mina’s state proof verification on Ethereum successfully (at least for now) passes the audit, it is time to start to prepare the production deployment.

=nil; Foundation can’t be more excited about it and we have at least three reasons that we love the upcoming zkBridge for:

• Enabling secure data exchange opens up Mina users the new ways and scenarios to benefit from their actives, thus, bringing new experiences in place
• Developers of zkApps have a chance to expand their presence to the Ethereum ecosystem building integrations that can create new value
• Every time one protocol can make a zk state proof available for verification by another, the whole industry gets more transparent and less fragmented while staying trustless.

This post introduces the roadmap to production for zkBridging Mina to Ethereum through =nil; Proof Market.

What would we need for that?

We have three steps which have to be taken for the bridge takeoff.

1. Proof Generation Mina’s zkBridge requires continuous auxiliary state proof generation. This means a set of incentivized proof generators has to be arranged. And such a set of proof generators have access to different protocol’s data (e.g. Ethereum). This means it has to be based on top of =nil; DROP DATABASE *. Such a set of proof generators is arranged with =nil; Proof Market.
2. Optimizations Proof generators have to provide a proper proof generation performance. This means a software they run has to be improved and adjusted according to the hardware they mostly use. This means a competitive environment like =nil; Proof Market is required for proof generators to be able to compare their results (and get incentivized) in a trustless manner. The fastest proof generator for an order wins! Isn’t it the best incentive to optimize?
3. Verifier Deployment Verifier and in-EVM state management part have to be deployed and tested out publicly. Possible gas consumption reductions have to be challenged publicly.

Each of these steps will be coordinated by =nil; Foundation in our Discord(#mina channel) and Telegram. For each of them we would appreciate Mina’s community help.

Proof generation. Let’s start with that.

An auxiliary proof we need to generate for a bridge is basically a proof of Mina’s Kimchi proof verification. This means it is quite a huge pile of computations - 34359738368 multi-scalar multiplications to be precise. This means an auxiliary proof is quite a piece of logic and a proof generation for it is a resource-consuming task requiring some servers. A more detailed description of how resource-consuming this task is can be found in our Mina bridge blog post.

Now, we got a choice:

1. To make each user to generate a proof themselves with no guarantees a user will fit into the timespan required (15 minutes) simply because each user’s hardware is different. This also induces issues with verification costs redundancy - each user can try to submit their own proof, paying the verification cost for the same state proof, other user has already submitted.
2. To coordinate proof generation to avoid redundancy and to ensure the verification cost is paid only once when needed. This would also guarantee that a required proof will be generated only once within timespan needed.

We obviously chose the second option. And this lead us to the…

Mina’s state proof on a Proof Market

What is a Proof Market? It is an open, competitive market for proof generators using open data as an input (e.g. Ethereum’s, Mina’s or Solana’s one) designed by =nil;. Something like a distributed proof generators market to facilitate zkOracles, zkBridges, Danksharding or anything what requires proofs of various kinds built on =nil; DROP DATABASE *. Anyone can join it by running =nil; node (high availability /decentralized ). Any proof request is supported (‘cause statements are being submitted in a proof system-agnostic manner). More details about the Proof Market are available in a relevant blog post

A competitive nature of such a protocol makes proof producers to optimize their proof generation software ‘cause the fastest proof generator providing the cheapest proof wins an order for a proof and, it means, wins the reward as well. This makes Proof Market perfect for the in-EVM verifiable Mina’s state proof to be generated with, considering it consists of heavy computations.

Bridge application will be a consumer of Mina’s state proof generated by a Proof Market so a workflow would look like this:

1. A user creates some Snapp/zkApp and submits its state to Mina.
2. A bridge application retrieves Mina’s state and puts an order for a proof generation on a Proof Market, using Mina’s state as an input.
3. Proof Market’s proof generators execute the order returning a newly generated proof to the bridge application.
4. A bridge application retrieves an address of a verifier from a Proof Market-based data accessibility application.
5. A bridge application submits a proof to the verifier.
6. All dependent logic can than be executed in the EVM dApp.

Mina’s state proof generation. How to participate?

To be able to participate a Proof Market as Mina’s state proof generator you need to:

1. Setup. Setup a proof generator.

   A proof generator which is used for Proof Market is a piece of software participants with hardware performant enough are supposed to run to supply proof market with proofs.

   The implementation is emplaced within the Proof Market toolchain repository

2. Proof Market Account Get a Proof Market account.

   To become capable of receiving and processing proof orders it is required to get an account on a Proof Market. A Proof Market account is a keypair to =nil; `DROP DATABASE *-based public cluster ran by a set of independent parties in a fault-tolerant manner.

   To receive an account it is required to visit the Proof Market’s registration page and to request credentials to access the Proof Market’s beta.

3. Order Bidding: The buyers of the proof (bridges,dApps etc) will place an order on the market which will have parameters such as the circuit id (on proof market) , public inputs (Mina state proof) and how much funny money you are willing to pay for this. If its more urgent , you pay more… like any marketplace. 
   The sellers of proof , will be monitoring the market for incoming best price orders and trying to get the best deal for themselves.Or they could just advertise spare capacity in advance. Their orders would be simpler carrying the circuit id & the money of-course. Once these orders are matched by the market, a proof producer has the green light to start generating the proof. (See step 1 above). Proofs generated are next pushed to the market. Successful validation of the proof on the market is when the order is “settled” - i.e. funny money goes from one hand to another. This proof can be used not only by the requester in their dApp but by any one else looking for the same proof. This scripts to carry out interaction is documented in the Proof Market toolchain and the lorem ipsum cli repositories.

Mina’s state proof generator optimizations. How to participate?

To be able to participate a Proof Market as circuit and proof generator optimizer you would need to:

1. Get familiar with Placeholder proof system.

   To ease out the understanding, it features PLONK-ish arithmetization and a hash-based commitment scheme.

2. Get familiar with proof generator implementation emplaced within the Proof Market toolchain repository.

   Since this is the primary piece of software which is used for Mina’s state proof generation, most of the optimization work will be done around it.

   This repository contains several libraries which are of an interest to a proof generation process:

   1. Proof systems library contains the Placeholder proof system implementation (in here particular).
   2. Circuits definition library, containing circuits relevant to Mina’s Kimchi proof verification. 
      
       
3. Start spamming Ilia Shirobokov and Alice_Cher with questions regarding contents of these in our Discord.

Verifier deployment. How to participate?

This part is less exciting, the verifier is simply required to be audited and deployed.

The audit part is under progress by ABDK folks.

The deployment part is as follows. The verifier is available within several EVM-supporting protocols.

Conclusion

We look forward to all exciting applications which will be built on this infrastructure. We welcome all developers, proof-seekers/providers,chain hoppers to join our community on Telegram and Discord for any technical support or to discuss collaborations.