zkBridges and Storage Proofs
07/20/237 min read
by Mantle
Developers
Web3
Mantle Network is a modular Ethereum layer2 (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 nonfungible 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 zkProofbased architecture is promising in resolving any issues with validity of state across chains.
While zkSNARKs 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 onchain 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 (Rank1 Constraint System) and Groth16.

Circom: Circom is a custom domainspecific 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 subcircuits, known as a dataparallel circuit, with each subcircuit 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 subcircuit 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 1ofN 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

UniDirectional: from source to destination

BiDirectional: 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 nonamortized)

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.