Intro 

ZK tech has been widely used for privacy and scaling purposes. Still, a new wave of projects is using characteristics of this cryptographic solution to solve one of the most compelling problems of the blockchain industry: Cross-chain bridging.

One of the reasons why the adoption of ZK for bridging is gaining traction is its trustless cryptographic nature, which solves one of the weak spots of centralised bridging solutions that were the epicentre of massive hacks in 2022.

The problem with bridges

Current cross-chain bridges face two important issues; scalability and security. Since bridges need to keep track of the state of two chains, they require significant computing power and storage capability. To avoid this overhead, many bridges have moved to a committee-based approach, where a small set of validators (or even just multisig holders) sign off on state transfers, becoming vulnerable to attacks.

During 2022, over $1.6B in assets were lost due to bridge exploits. But this figure can be interpreted 2 ways. On the one hand, the volume moved through bridges indicates an increasing market demand for interoperability. On the other hand, such an important piece of the puzzle represents one of the weakest points in the larger blockchain ecosystem. The three main areas of security issues were bugs in the code, blindspots in the architecture (such as missing fail safes) and committee/validator takeovers.

This has led builders to start exploring alternative solutions – specifically those that rely on cryptography. The use of properties inherent in zk-SNARKs remove the need for the committee model while still scaling the network.

How does ZK come to 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 full nodes to interact with the blockchain.

This allows you to verify the consensus of the source chain in the execution environment of the target chain without the need for additional trust assumptions beyond those required for the consensus of each chain. And the target chain will then have some information about the source chain baked into its own consensus.

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

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

Succinct Labs

Succinct Labs has developed a system that allows for a trust-minimised 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 chosen every 27 hours and is responsible for signing every block header during that period. If at least 2/3 of the validators sign a given block header, the state of the Ethereum network is considered valid. The process of verifying the validity of the network state involves storing and checking the 512 BLS public keys of the validators, as well as demonstrating their signatures and Merkle proofs of the headers and validators.

This process is computationally expensive, so the light client uses SNARKs to create a constant-size proof that can be efficiently verified on the Gnosis chain. The evidence is created using off-chain computation, which includes constructing circuits to verify the validators and their signatures and then generating the SNARK proof. The proof and block headers 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 the EVM and so may need to be more readily generalisable to be used on other chains.

zkIBC by Electron Labs

Electron Labs is trying to create a connection between the Cosmos SDK ecosystem, which is a framework for building specific blockchain applications, and Ethereum. Specifically, zkIBC is looking to emulate the trustless communication protocol used by Cosmos sovereign chains named Inter Blockchain Communication Protocol (IBC) and expand this to be usable with Ethereum.

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

This method allows for the efficient and cheap verification of Ed25519 signatures from 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 high block production rate of the Cosmos SDK. Electron Labs plans to address this by using multiple machines to generate the proofs in parallel and combining them into a single zkSNARK proof.

zkBridge by BerkleyRDI

zkBridge is a framework that allows for the creation of applications that can communicate between different blockchain networks. It uses a system of relay nodes and smart contracts to facilitate communication.. The main difference between zkBridge and other industry-led approaches is that it only requires the existence of one honest node in the relay network and the assumption that the zkSNARK is sound.

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

=nil; foundation trustless data accessibility.

Critical data management, such as in the case of bridges, often requires a full replica of the data in a trusted environment under complete control. But when this is not possible, or very expensive to provide,, organisations may turn to trusted data providers, such as AWS or Infura, to access their needed data.

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

This is where =nil; ‘s trustless data management solution comes in. By using state and query proofs based on the “DROP DATABASE *” system, this solution allows for trustless bridging. In this case, protocols can use data retrieved from a protocol and a SNARK correctness proof to transfer data from different protocol databases to each other.

Conclusion

Since the ZK bridging space is still in its infancy, we expect exponential growth in research breakthroughs, clever implementations and adoption by cross-chain applications in the coming years. Since we know the appetite for interoperability is growing we can expect more development of secure and scalable bridging technologies, which in turn will likely further boost the development of ZK technologies.