Mantle Network is a modular Ethereum layer-2 (L2) based on Optimism, built to satisfy the needs of Mantle Ecosystem. zkBridges and the closely related Storage Proofs are interoperability solutions of interest to Mantle for the following reasons:

• The multichain thesis requires low latency and trustless bridging between chains

• Mantle leans on this thesis creating a modular chain suited for gaming and DeFi yet requiring assets that may be living on other chains

• The optimistic rollup pattern security requires a lengthy challenge period for submission of fraud proofs

• Simple “fast liquidity” based solutions for fungible tokens exist but these have fees and drawbacks such as the fact they cannot be used for general messaging or standard non-fungible tokens

Background

Many interoperability solutions exist, all using a variety of technologies and architectures. However many of these have been subject to security vulnerabilities as documented here. The arrival of a new form of zkProof-based architecture is promising in resolving any issues with validity of state across chains. 

While zk-SNARKs are popular for their validity and compression (soundness and succinctness) properties in the L2 rollup space, they have also become a popular tool in the bridging/interoperability space, the primary design termed colloquially as “zkBridges” in the canonical paper.

With this bridge type SNARKS are typically used to verify the consensus of one chain's light client in a fully on-chain fashion at the destination chain, providing a “proof of consensus”. The inclusion of a transaction and its content/intent to a bridge address on the origin chain can then be trustlessly confirmed on the destination chain. 

zkBridges (ZKP validity proofs) fit into the bridging design space as such:

The high cost can be explained by the various bridge environmental constraints. Considerations include (but are not limited to):

• Signature Scheme: generating and verifying zkProof circuits for different signature schemes requires using different libraries and impacts both architecture and performance:

  • ecDSA over different curves

    • Ethereum/Most EVM’s secp256k1 

  • edDSA

    • Near/Cosmos (curve25519)

• Consensus Algorithm and Light Client Architecture

  • PoW: Simplified Payments Verification (SPV) - the original light client involves checking the included miner chosen nonce for sufficient difficulty and also contains a merkle root of all the transactions in that block. Inclusion in a block is then simply a merkle proof that resolves to that merkle root.

  • Ethereum PoS: Sync committee structure (a subset of 512 validators operating over a period of 27 hours). These validators are required to sign every block header during their period, and if more than 2/3 of the validators sign off every block header, the state of Ethereum is deemed a valid state. The validation process essentially consists of verification of:

    • Merkle proof of headers

    • Merkle proof of the validators in the sync committee

    • BLS signatures for correct rotation of the sync committee

• And concerns about this light client structure

  • Cosmos IBC: popular light client based bridging standard

  • zkProof Libraries

  • Gnark:  Gnark is written in Go, making it easy to integrate with Go projects and benefit from Go's performance and simplicity. Gnark supports multiple backend options, including R1CS (Rank-1 Constraint System) and Groth16. 

  • Circom: Circom is a custom domain-specific language (DSL) for defining circuits. Circom primarily targets R1CS and leverages the PLONK proving system, although it can also work with other backends like Groth16. Circom has a more extensive ecosystem, with integration into various projects and libraries such as snarkjs and websnark. 

  • Plonky2: Plonky2 is a recursive SNARK that is 100x faster than existing alternatives and natively compatible with Ethereum. It combines PLONK and FRI for the best of STARKs, with fast proofs and no trusted setup, and the best of SNARKs, with support for recursion and low verification cost on Ethereum.

• Proof Structure

• DeVirgo: A key innovation in this construction is the usage of a parallelized use of the zkSNARK: Virgo prover (deVirgo) which has succinct verification/proof size and does not require a trusted setup. The motivation is that a circuit for verifying N signatures essentially consists of N copies of identical sub-circuits, known as a data-parallel circuit, with each sub-circuit mutually exclusive from the rest. 

The core component of a Virgo prover is based on a zero knowledge extension of the GKR protocol which runs sum check arguments for each sub-circuit in the layered circuit and a polynomial commitment scheme. The deVirgo generalization essentially runs a Virgo prover on a set of relay nodes, and avoids the linear growth of the proof size by aggregating the proofs and polynomial commitments into a master node.

• Groth16: the classic SNARK implementation, popularized by zCash. Requires a trusted setup. Well established and battle tested, not as efficient as other structures and implementations. 

• Trust Assumptions

• Trusted Setup: a trusted setup to produce a structured reference string is required for most SNARK constructions. These setups typically have a 1-of-N trust assumption, which is you are trusting at least one party properly participated for the output to be safe. This has arguably become more commonplace and less problematic.

• Trustless Setup: Typically appears in a zkSTARK but can also happen in SNARK’s depending on the construction. Has not really appeared practical in the zkBridging space as of yet. 

• Source/Destination Chains

• Source: the chain the bridged information is coming from

• Destination: the chain the information is going to

• Directionality

• Uni-Directional: from source to destination

• Bi-Directional: from source to destination, and vice versa

• Application Functionality

• Token: ERC20 only. Smaller surface area, easier to design and optimize 

• General Message Passing: more interesting since we already have fast liquidity exit from bridge

zkBridge Performance 

Considerations:

• Proving Time

• How this affects latency: 

• If the proving time is greater than the deposit transaction confirmation period (currently on the order of minutes for optimistic rollups) then zk bridging is not particularly effective for deposits. 

• Withdrawals from optimistic rollups have a longer latency (but not particularly for Mantle with its fast MPC which has an economic security guarantee limited to the value staked by the signing binded validators)

• Constraints

• The number of constraints is an approximation to the complexity of the underlying zkProof circuit. 

• Some architectures are more constraint intensive than others resulting in a higher complexity and proving time

• Verification Cost

• Gas consumption is typically near constant for proof size - between 200 and 400k

Comparison

Mantle aims to maintain a living directory of zkBridges and their storage proof counterpart and their proliferation. A detailed comparison of zkBridges can be found here and storage proofs can be found here. This article also has an accompanying slide deck which was presented at Jump Capitals zkWeek. 

A bonus Dune Analytics dashboard of zkBridge usage is found here. If interested in contributing to this research please open a PR to these repos..

Conclusion

Mantle is interested in providing the best interoperability solutions for users and projects based on Mantle.

• zkBridges are a nascent but rapidly evolving technology. It is yet to be seen if their advantages (low trust model, low latency) outweigh their disadvantages (relatively high cost when non-amortized)

• A variety of constructions/architectures are devised, primarily driven from the constraints of the underlying blockchains. 

• Mantle is actively researching the zkBridging space in order to potentially provide users with a better experience.