How will a Mina Protocol's bridge become bi-directional?
Written by Mikhail Komarov, Aleksey Sofronov
Special thanks to Luke Pearson for discussion, adjustments and comments. on 28 Jun 2022
This post covers one of the applications of a =nil; ‘DROP DATABASE *-based Trustless Data Accessibility protocol - trustless bridging. In particular, it covers an integration with Mina Protocol, for which we’ve already described, developed and demoed a one-directional bridge.
In the end of April 2022 Mina Protocol’s in-EVM state verification finally saw the light of the day https://verify.mina.nil.foundation. Meanwhile, =nil; Foundation wasn’t sitting idle and announced a =nil; Database Management System called =nil; ‘DROP DATABASE * and its replication protocol extension which is capable of providing trustless I/O to various databases through the DBMS’s query language unified for all the databases (Bitcoin, Ethereum, Solana, Mina, others).
=nil; provides users (no matter what kind of users - applications or protocols) with on-demand state and query proofs for three different use cases:
In this article, we’ll be describing the second use case applied to Mina.
Not so fast. What we’ve accomplished so far is a one-directional Mina-Ethereum bridge core (which is effectively an in-EVM Mina state transition verification).
Let’s briefly walk through the current design Since strainghtforward Kimchi proof verification on EVM is too expensive, we basically have to to wrap Kimchi proof verification algorithm in another proof (using =nil;’s Placeholder proof system), and create a ‘proof of a successful verification’ - this can then be cheaply verified within the EVM.
So the current step by step process is as follows:
- Mina’s native state proof gets retrieved
- Auxiliary proof in Placeholder proof system is being generated
- Auxiliary proof is being submitted to EVM for the verification to happen
Application examples of a currently existing single-directional in-EVM Kimchi proof verification are:
More detailed overview of a currently existing solution can be found in previous relevant blog posts: https://blog.nil.foundation/2021/11/01/mina-ethereum-bridge-design.html, https://blog.nil.foundation/2021/09/30/mina-ethereum-bridge.html.
The most important thing that the =nil; brings is the capability to fetch state and query proofs for various other protocols (like Ethereum, Solana or Avalance). And, since we can switch the proof system being used within =nil;, those query and state proofs can be bridged to any supported proof system. In Mina’s case specifically, we generate the proofs in Kimchi.
To be more presice we have a couple of options how to arrange this:
Reconstruct the query/state proof directly in Kimchi, which would look something like this: the user constructs a query (such as _db[“eth”].select(“accounts”).where(“key”).equals(“name”).and(“value”).equals(“100”)) and this would return a Kimchi proof, ready to be verified on Mina right away.
The downside of this approach is that proof generation will become much more expensive, because of the need to reconstruct the original proof in Kimchi - essentially incurring a linear double cost for each query.
Wrap’ the state/query proof (generated with the Placeholder proof system) by implementing the verification algorithm as a Kimchi circuit. This would also incur an additional proof generation for each query, but will generally be much cheaper as this circuit is constant-size, and avoids naively duplicating the original proof.
At a glance, the second option seems to be more viable.
This specification allows us to verify third-party protocol data proofs directly within Mina, which leads us to…
Let’s break this process down step-by-step.
Other protocols, supported by =nil; are also going to be available for Mina-compatible state/query proof generation and retrieval. For example, Solana’s integration is on its way.
Same process as for Ethereum from user story side:
Yes! It is a DBMS which supplies =nil; with data, remember?
So, in case a user wants to bridge Solana’s and Ethereum, the only adjustment to
the user story would be to retrieve a proof of a composite query from
=nil; with something
SELECT FROM SOLANA WHERE a EQUALS b; SELECT FROM ETHEREUM WHERE
c EQUALS d. Then =nil;
would return a proof of such a query generated in Placeholder proof system and
wrapped with Kimchi, which will be okay for Mina’s native verifier, so one can
safely use other protocols data in Mina.
According to our best estimates, we plan to introduce the first working prototype of Ethereum’s state/query proof generator compatible with Mina’s proof system in Q4 2022.
It will be published after moderation.
An error occured during adding your comment!