ZKP: Building Secure, Efficient Cross-chain Bridges

Background
Since Bitcoin’s birth in 2009, blockchain technology has made great strides. While Bitcoin and Ethereum continue to dominate the market, many different blockchain networks with unique functions and applications have emerged. Blockchains cannot interact with each other because they are built with varying architectures. As blockchain ecosystems, especially DeFi, keep on growing, bridging the gap between different blockchains has become a key problem.

Cross-chain bridges have emerged as a solution to that very problem. These applications allow different assets to move across multiple blockchains. In some cases, cross-chain bridges even make information interoperability a reality. Similar to a bridge spanning two sides of a river, cross-chain bridges seamlessly transfer assets from one chain to another, enabling users to leverage the unique features of different blockchain networks. Moreover, they allow applications to transfer data and information between different chains. Despite their merits, cross-chain bridges also face challenges, especially in terms of security. For instance, in 2021, Poly Network was hacked, resulting in a loss of over $600 million worth of cryptocurrency. In 2022, about the same amount of crypto was stolen from Ronin Network, Axie Infinity’s cross-chain bridge. These cases are evidence that cross-chain bridges need more comprehensive security measures to safeguard users’ assets and data.

In recent years, zero-knowledge proofs (ZKPs) have made significant progress in their applications. ZKP is a powerful cryptographic tool that protects users’ data privacy and proves the effectiveness of Rollup scaling solutions. In addition, ZKP also plays a vital and unique role in the design of cross-chain bridges. With these concise proofs, the target chain can efficiently verify the state transition of the source chain, which mitigates third-party risks unrelated to the target chain and the source chain and improves the security of cross-chain bridges. Today, we will go through a number of common cross-chain bridges and explain how ZKP technology is applied to cross-chain bridges by studying several ZKP-based cross-chain bridges.

Types of Cross-chain Bridges
Crypto researcher 0xjim once divided cross-chain bridges into four categories: Team Human, Team Economics, Team Security, and Team Game Theory, according to their design and mechanisms. In particular, Team Human chains are more centralized. For example, Ronin Network consists of nine full nodes run by publicly known entities. They prove the validity of a transaction via multi-signature verification, and after a threshold is passed, the transaction is considered verified. Under normal circumstances, these validators will not do evil, but with this centralized approach, they might be attacked and become the biggest loophole, and it could be disastrous if the private keys are not properly managed.

The next is Team Economics, including Celer, Axelar, and Thorchain. These are similar to multisigs, but with tokenomics. To prevent evil doing, chains in Team Economics require nodes (validators) to stake tokens. In the case of a breach, the validator’s stake will be slashed. So, from a financial perspective, they should verify the validity of transactions with honesty.

The third type is called Team Security, which covers chains that utilize TEE or MPC to make cross-chain transfers more secure. For instance, all nodes would perform encrypted off-chain light client verification in a TEE like Intel SGX to maintain the privacy and integrity of private key management.

Finally, there is Team Game Theory, which covers LayerZero, Nomad, and Synapse. These protocols break up bridging into two separate jobs and disincentivize coordination between the two job doers. In the case of LayerZero, oracles pass block headers, and relayers pass transaction proofs. Together, the two perform the duties of an on-chain light client.

All four types of bridges rely on off-chain verification and multi-factor authentication. In particular, the first three essentially use their own PoS chain/network as a witness to transmit information between any two public chains. This faster, cheaper, and more scalable approach makes it easier for these bridges to connect to more chains, but the price they must pay is that users and liquidity providers have to fully trust the funds or data of the external validators. In other words, they rely on the security of the bridge, rather than the source chain or the target chain.

ZKP
In recent years, we have seen frequent cross-chain bridge accidents, resulting in significant financial losses. This highlights the vulnerabilities that additional trust assumptions bring to cross-chain bridges. As such, the safest design for a cross-chain bridge is minimum trust, i.e., the bridge only inherits the security attributes of the two connected chains without trusting any third party. On-chain verification is an effective way to minimize trust in cross-chain bridges. To be more specific, the target chain validates the consensus of the source chain and confirms whether the specified transaction is included in the source chain. For example, validators of the target chain can run a light client of the source chain to check the Merkle root submitted and verify that the transaction has obtained valid signatures from validators on the source chain. However, this approach has been difficult to adopt because on-chain verification is quite expensive. Validators on the target chain may find it challenging to run a light client for different source chains, and some target chains may not support the signature scheme adopted by the source chain. For instance, the validators in Ethereum PoS consensus use BLS signatures and the EVM does not have the precompile for the BLS12–381 curve used in these signatures, which renders a Solidity implementation of such a light client prohibitively expensive.

The recent progress in ZKP systems has made verifiable computation more succinct. In addition, ZKP plays a unique and vital role in the design of cross-chain bridges, just like how zk-SNARKs fuel the scaling of zkEVM projects. Verifiable computation can also generate validity proofs for chain states, and these validity proofs validate consensus for light clients with efficiency and low costs, enabling trust-minimized interoperability. In fact, cross-chain bridges utilize the succinctness of ZKPs, instead of their zero-knowledge property. In this sense, for cross-chain bridges, ZKPs are similar to the validity proof of Rollup scaling solutions.

Succinct Labs
Succinct Labs and Gnosis have co-launched a SNARK-based cross-chain bridge that allows for trust-minimized interoperability between any two Ethereum PoS chains, such as Ethereum and Gnosis Chain. This is achieved by deploying a light client in the form of a Solidity smart contract on the chain that generates proof of validity for the state of the source chain via succinct ZKPs. This approach enables efficient light client verification, which facilitates cross-chain communications between Ethereum and Gnosis Chain, thereby enabling trust-minimized interoperability. The light client tracks Ethereum block headers on Gnosis, and vice versa, without the need for additional trust assumptions. Meanwhile, a sync committee of 512 Ethereum validators randomly chosen every 27 hours confirms whether the state of Ethereum is valid. Once two thirds or more validators sign the block header, the state of Ethereum is considered valid. As such, the scheme is essentially a PoS bridge.

Succinct Labs generates zk-SNARKs via a light client using the Circom programming language and Groth16 proving system, which reduces the cost of on-chain verification. Instead of verifying an aggregated BLS signature, the light client verifies a single Groth16 zkSNARK. Apart from that, the light client must also track validators of the sync committee. Every time the sync committee reselects new validators, the current validators sign a block header containing the SSZ hash of the next committee’s public key. As the SSZ hash uses SHA-256, it is not SNARK-friendly, and a large number of constraints need to be computed. To resolve the issue, Succinct Labs created a circuit that maps the SSZ hash of the next validator set to a SNARK-friendly Poseidon commitment, which is then stored on the chain and used as an input to the BLS signature verification SNARK to ensure that the signature being verified is indeed from the sync committee validators.

The technology is still in the development stage, and the token bridge on the testnet has been launched for demonstration between Ethereum and Gnosis but has not yet been used to protect real assets. Additionally, it should be noted that the security level of the technology has not yet reached that of the Ethereum consensus.

Electron Labs
Electron Labs is a cross-chain protocol that protects cross-blockchain communication through ZK light clients. It aims to connect Ethereum with the Cosmos ecosystem (as well as other EVM chains) using IBC protocols and zk-SNARK technology. Projects similar to Electron Labs include Polymer and Gerege.

Normally, Cosmos IBC deploys light clients in the form of smart contracts on the source and target chains to verify cross-chain transactions. Similarly, to connect IBC to Ethereum, developers need to run the Tendermint light client on Ethereum as a Solidity smart contract. However, this turns out to be an extremely gas-expensive operation since it requires the verification of hundreds of Ed25519 signatures in solidity, and Ed25519 precompiles are not available on Ethereum. Therefore, rather than verifying the Ed25519 signatures directly on Ethereum, Electron Labs uses an alternative solution: it constructs a ZKP of signature validity off the chain and verifies the proof on the chain.

The on-chain light client modules on the Ethereum side will include a ZK-Proof verifier instead of an Ed25519 signatures verifier. The relayer, rather than submitting the full light client header, will just submit the proof of validity for the same. At Electron Labs, Electron Labs has built a Circom-based library that generates a zk-SNARK proof for a batch of Ed25519 signatures, making it cheaper to verify those signatures on Ethereum.

Positron is Electron’s first bridge, which went live between the Goerli testnet and the NEAR testnets. The bridge is used to demonstrate the implementation of ZKPs and on-chain light clients. During the public testing, the speed limits of RPC nodes caused latency in processing transactions on Positron, backlogging hundreds of transactions for several hours. The issue has since been resolved.

zkBridge
zkBridge is a trustless, permissionless, extensible, universal, and efficient cross-chain bridge. Any node can freely join the network to relay the block headers, generate proofs, and claim the rewards. To be more specific, zkBridge consists of a block header relay network and an updater contract. In the block header relay network, relayers retrieve the block headers from the source chain, generate proofs of validity of the block headers, and send the headers along with the proofs to the updater contract which is set up on the target chain. For the updater contract, the corresponding block headers of the source chain are stored once the associated proofs pass the verification. Furthermore, the updater contract also maintains a light-client state. Once a new block header is added, the contract renews the light-client state just like other light clients on the source chain. The updater contract also exposes a function to applications, through which an application on the target chain can obtain the block header of a given height on the source chain. After getting the block header information, the application can do more verification and build its own functions.

For fast proof generation and low on-chain proof verification cost, zkBridge uses a 2-layer recursive proof system. In the first layer, the bridge taps into deVirgo, a distributed version of the Virgo proof system. deVirgo combines distributed sumcheck and distributed polynomial commitment to achieve optimal parallelism, and is able to accelerate the proof generation by orders of magnitude when running on distributed machines. In the second layer, zkBridge uses Groth16 to prove that the previously generated proof by deVirgo indeed proves the corresponding block headers.

Conclusion
Today, we have gone through several projects that build cross-chain bridges with ZKP technology. All these projects are exploring how to use ZKPs to generate validity proofs to achieve efficient and low-cost light-client consensus verification, thereby enabling trust-minimized interoperability. Although they remain in a nascent stage and are often confined to certain chains, the projects offer an innovative solution to the interoperability issue facing blockchains. We believe that as ZKP technology keeps advancing, the blockchain industry will witness the emergence of more cross-chain solutions with sound security performance.