How to solve the problem of cross-chain bridge? Introduction of 4 new ZK bridge projects

Author: zkvalidator; Compiler: Kate, Marsbit

ZK technology has been widely used for privacy and scaling purposes. Still, a new wave of projects are taking advantage of features of this cryptographic solution to solve one of the blockchain industry's most compelling problems: cross-chain bridges.

One of the reasons for adopting ZK for bridging is its trustless cryptographic nature, which addresses one of the weaknesses of centralized bridging solutions that are at the center of massive hacks in 2022.

Bridge Problems

**The current cross-chain bridge faces two important issues: scalability and security. **Since bridges need to keep track of the state of the two chains, they require significant computing power and storage capacity. To avoid this overhead, many bridges have moved to a committee-based approach, where a small set of validators (or even just multi-signature holders) sign state transfers and thus become vulnerable.

Over $1.6 billion in asset losses due to bridge attack vulnerabilities during 2022. But this number can be interpreted in two ways. On the one hand, the transit traffic over the bridge indicates that the market demand for interoperability is increasing. On the other hand, such an important piece of the puzzle represents one of the weakest links in the larger blockchain ecosystem. The three main areas of security concern are bugs in the code, blind spots in the architecture (such as lack of failsafes), and committee/validator takeovers.

! [ZK] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-4c6e40347b-dd1a6f-7649e1)

Massive hack in 2022 drives ZK bridge development

This has led developers to explore alternative solutions—especially those that rely on cryptography. Using properties inherent to zk-SNARKs removes the need for a committee model while still allowing the network to scale.

****How does ZK play? ****

To verify the state of one blockchain (the source chain) on another blockchain (the target chain) without shared security, you can use an on-chain light client for the source chain running on the target chain. A light client or light node is a piece of software that connects to a full node to interact with the blockchain.

This lets you verify the source chain's consensus within the target chain's execution environment without requiring additional trust assumptions beyond what is required for each chain's consensus. The target chain will then have some information about the source chain incorporated into its own consensus.

! [ZK] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-542bfc07ee-dd1a6f-7649e1)

Here is a simple explanation of how the ZK bridge works

By using zero-knowledge proof systems, specifically the "succinct" property of SNARKs, it is now possible to efficiently perform this verification process using on-chain light clients. It is also possible to verify state transitions and consensus on-chain for maximum security, similar to running a full node.

We identified at least four projects working on ZK bridge solutions in different ecosystems and stages of development.

Succinct Labs

! [ZK] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c859310236-dd1a6f-7649e1)

Succinct Labs has developed a system that allows for a trust-minimized connection between Gnosis and Ethereum 2.0, a proof-of-stake consensus blockchain. The system uses SNARKS to efficiently verify the validity of consensus proofs on the Gnosis chain.

The Ethereum 2.0 network has a committee of 512 validators, randomly selected every 27 hours, responsible for signing every block header during that time. The state of the Ethereum network is considered valid if at least 2/3 of the validators have signed a given block header. The process of verifying the validity of the network state involves storing and checking the verifier's 512 BLS public keys, and presenting their signatures and block headers and the verifier's Merkle proof.

This process is computationally expensive, so light clients use SNARKs to create a constant-size proof that can be efficiently verified on the Gnosis chain. Proofs are created using off-chain computation, which involves building circuits to verify validators and their signatures, and then generating SNARK proofs. The proof and block header are then submitted to a smart contract on the Gnosis Chain, which performs the verification. Using SNARKs helps reduce storage overhead and circuit complexity, and lowers trust assumptions. However, this approach is specific to the Ethereum 2.0 consensus protocol and EVM, so it may need to be easier to generalize to other chains.

zkIBC developed by Electron Labs

! [ZK] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-7fb0fa2f77-dd1a6f-7649e1)

Electron Labs is trying to create a connection between the Cosmos SDK ecosystem (a framework for building specific blockchain applications) and Ethereum. Specifically, zkIBC is seeking to emulate the trustless communication protocol used by the Cosmos sovereign chain, called the Inter-Blockchain Communication Protocol (IBC), and extend it to Ethereum.

However, using a light client of the Cosmos SDK on Ethereum poses some challenges. The Tendermint light client used in the Cosmos SDK runs on the Ed25519 curve, which is not natively supported by the Ethereum blockchain. This makes it expensive and inefficient to verify Ed25519 signatures on the Ethereum BN254 curve. Electron Labs plans to solve this problem by creating a zkSNARK-based system that can generate proofs of signature validity off-chain and only verify the proofs on the Ethereum chain.

This approach efficiently and cheaply verifies Ed25519 signatures of the Cosmos SDK on the Ethereum blockchain without introducing any new trust assumptions. One issue with this approach is latency, as the proof generation process needs to keep up with the Cosmos SDK's high block production rate. Electron Labs plans to solve this problem by using multiple machines to generate proofs in parallel and combining them into a single zkSNARK proof.

zkBridgeDesigned by BerkleyRDI

! [ZK] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-e2df0e1e8a-dd1a6f-7649e1)

zkBridge is a framework that allows the creation of applications that can communicate between different blockchain networks. It uses relay nodes and a smart contract system to facilitate communication. The main difference between zkBridge and other industry-led approaches is that it only requires the presence of one honest node in the relay network, and it assumes that zkSNARKs are reliable.

zkBridge uses deVirgo, a parallel version of Virgo's zkSNARK proof system, which has a smaller proof size and does not require a trusted setup. It relies on a protocol called GKR and a polynomial commitment scheme to generate proofs of circuits that verify multiple signatures. The deVirgo proof is then compressed using the Groth16 prover and verified by the update contract on the target blockchain. Overall, this combination of proof systems enables efficient cross-chain communication in zkBridge without external trust assumptions.

****=nil; Basic untrusted data accessibility ****

! [ZK] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c3a756c16c-dd1a6f-7649e1)

Critical data management, such as bridging, often requires full replication of data in a trusted environment under full control. But if that's not possible, or prohibitively expensive to provide, organizations may turn to trusted data providers, such as AWS or Infura, to access the data they need.

But as we mentioned in the introduction to this post, trusting data providers can lead to censorship or data breach issues.

Here=nil;'s trustless data management solution. This solution allows trustless bridging by using state and query proofs based on the "DROP DATABASE*" system. In this case, the protocol can use the data retrieved from the protocol and the SNARK proof of correctness to transfer data from different protocol databases to each other.

in conclusion

As the ZK bridging space is still in its infancy, we expect an exponential growth in research breakthroughs, smart implementations, and adoption of cross-chain applications in the coming years. Since we know that the need for interoperability is growing, we can expect the development of more secure and scalable bridging technologies, which in turn may further the development of ZK technology.