Introduction

Similar to the scalability trilemma, protocols engaging in interoperability can follow a maximum of 2/3 fundamental properties: trustlessness, extensibility, and generalizability.

Traditionally, interoperable protocol layers can be broken down into three types of bridges:

Natively verified
Externally verified
Locally verified

Today, our focus will be on natively verified bridges. Unlike in externally and locally verified bridges, in natively verified bridges (also known as light client-based bridges), the operators of the bridge are the validators of the underlying chains. Chains that interoperate run on-chain light clients for each other in their execution layers which verify the consensus of the counterparty chains.

The design only requires trust in the economic security of the consensus of each participating chain and eliminates the need for additional trust. For this reason, natively verified bridges like Rainbow and IBC are considered to be the closest to “trustless” across L1s. Natively verified bridges can be used to transfer any arbitrary data such as balances, storage, transactions, and events from the source chain to the target chain.

However, they have two main limitations: cost and extensibility. To verify each other’s consensus, the chains must continuously keep track of the active validator sets and verify their signatures (consensus votes). This can be computationally expensive, especially if the receiving chain does not natively support the necessary precompiles and curves related to the consensus mechanism of the sending chain. This hinders the extensibility of light client bridges across heterogenous chains.

So far, only IBC on Cosmos app-chains has successfully deployed on-chain light clients at significant scale. This has been achieved by substantial standardization, which requires all chains to conform to predetermined compatibility requirements.

ZK-Bridges – What Are They Good For?

Recently, there has been significant effort to use ZKP technology to build cheap light client-based bridges. At their core, these bridges leverage ZKPs (commonly ZK-SNARKs) to reduce the gas costs of on-chain verification.

ZK-SNARKs allow for two main functionalities:

ZK aspect: hide inputs into the function being proved
SNARK aspect: succinctness gives way to scalability

The key to this scaling is the succinctness property; instead of verification being done directly on-chain, consensus can be proven off-chain and cheaply verified on-chain via succinct ZK-proofs. As a side effect, ZK-bridges also stretch the extensibility of light client bridges, as chains no longer need to natively support each other’s signature schemes in order to cheaply interoperate.

ZK-Bridges vs. ZK-Rollups

For the sake of clarity, it’s important to distinguish between ZK-bridges and ZK-rollups. In ZK-rollups, ZKPs are used to validate every state transition, ensuring the rollup never makes an invalid transition. ZK-bridges, on the other hand, only prove consensus (with 2/3 validator signatures) and not individual state transitions (think transactions). This means that if the source chain’s validators collude, they could trick the destination chain into accepting an invalid state transition such as creating fake tokens. The on-chain light client on the destination chain wouldn’t be able