zkMonk Proposal for the interchain bridge

General
,
1

Proposal :
Based on our understanding of the MVP scope and considering the future scalability of this interchain solution between Aztec and other L2’s or L1’s, our proposal is based on the follow key elements of User experience and technical architecture

  1. Modular components
  2. Custom ZK-proof based proving of deposit and withdrawal by managing and synchronizing the state on all connected chains.
  3. Allow for message (proof) transmission.
  4. Assets on each chain managed by liquidity provisioning on those chains and balanced via 3rd party LP’s
  5. Integrate with an existing dumb message bridging solution, this is a faster solution for the MVP and also scalable.

Our overall solution consists of the following elements for executing a cross chain operation. These elements itself has its own features and dependencies

  1. Bridge Core : This is the main operational logic implemented as smart contracts.
  2. Merkle Trees : These trees represent methods to keep the records secure for the inter chain protocol. There will be two types of trees, one each for every chain ( let’s call it “chain tree’ which stores the state of every chain) and one “global tree” which contains the state ( root of chain tree) of every connected chain
  3. Interchain communication ( Keepers) : Operator of various off chain processes like roll-up / state synchronization etc. Keepers run the Interchain client process
  4. Messaging Bridge : Selection of message bridge is made keeping in considerations of Relayers, Validators, Gas Quotations, Customizability, Technical intricacy, number of supported networks and the trustless nature of the bridge itself.
  5. dApp : will allow users to interact with the bridge and person cross chain intents.
  6. RPC provider

Our Team consists of members from zkMonk enginnering community and members of the Panther Protocol team with deep expertise in architecting, building and executing scalable solutions.
Our contact : contact-- at–zkmonk–dot–org

Detailed Proposal:

  1. High level Architecture

This is a conceptual architecture of the Bridge that we propose. We can expect a few changes as we start the detailed design and implementation.

Theoretically, this is a privacy bridge but can be extended to make it a public bridge by exposing certain elements of the input data.

This is similar to IBC in the way that each chain stores some information about the state of the other chain but in our case the state of the interchain alone is recorded and updated in the Merkle tree.
Every deposit can be treated as creation of an UTXO and a withdrawal is spending of the UTXO.

ZK proof ensures that users who can prove their deposit in the origin chain are allowed to withdraw from the destination chain. After withdrawal, the state is updated to stop double spending of any deposit(s) on any connected chain. Also users generally specify the destination chain while making an interchain intent.

891×501 65.8 KB

  1. Bridge Type and why?

ZK bridge for private bridging of assets. Integration with an existing Message bridge allows for modularity and scalability.
Keepers are the off chain entity that runs the Interchain client which helps in reading and synchronizing the state of interchain deposits and withdrawal. In the future Keepers can fall part of the larger validator network either within the Aztec ecosystem or derive security by integrating to the Eigen layer etc. This can be the future enhancements.

  1. How the design meet the requirements

It is generic and can be used by individual users within Aztec or other L2’s or in the future, we can create endpoints for dApps within Aztec to seamlessly integrate.

The modular architecture supports any asset type and flexibility of making changes to different models without impacting the core functionality.

It is trustless, private and secured using zero knowledge.

It also fits well with Aztec private transactions using the PXE client side solution for dApps and also works well with the public transaction.

  1. Technical hurdles that need to be overcome

Integration with a 3rd party message bridging has dependency to have implementation available on Aztec and other L2’s but this can easily be mitigated and then scaled.

  1. User flow and journey

  2. Private bridging between Aztec and destination chain (L2)

  3. Private bridging from other L2’s to Aztec

MVP Grant Amount

MVP Duration : 3 months

Based on our high level estimation and resource planned for MVP will be USD 48,000 ( USD Forty Eight Thousand). This does not cover any third party implementation or integration cost or any changes on the Aztec side that may arise during the development phase.

Further details about our resource plan and roadmap for the future, please check out this document. ( the tool wont allow to add more images here)