Why blockchain interoperability needs trustless bridges

In this blog we provide an overview of trustless bridges and the important role they play for interoperability and the future of cross-chain communication.

A recent report by Chainalysis estimates the total amount lost in bridge-related hacks at over $2 billion. More so, the top three spots on the Rekt leaderboard are held by bridges: Ronin Network ($624 million), Poly Network ($611 million), and BNB Bridge ($586 million).

As noted by key players in the industry, poor bridge security weakens consumer confidence in crypto, fuels negative perceptions in the mainstream media, and may even lead to excessive regulation. Many proposals have been made to improve the security of cross-chain communication, but none have held much promise as the introduction of trustless bridges.

Unlike current bridge designs, trustless bridges remove the need to trust a small set of participants to relay honest information about cross-chain events. Although previous research suggests the impossibility of cross-chain communication without a trusted party, trustless bridges attempt to reduce trust by validating relayed information with zero-knowledge proofs.

Bridge security is certainly complex, with multiple attack vectors to consider, but most agree trust assumptions inherent in bridge designs have contributed to many attacks. Which is why the use of zero-knowledge technology to facilitate trustless cross-chain communication may be a game-changer for the blockchain interoperability space.

ELI5: What is a trustless bridge?

A trustless bridge is a cross-chain bridge that uses cryptographic primitives—for example, zero-knowledge proofs—to validate information passed between blockchains instead of relying on economic incentives or honesty assumptions for security. To understand the role of cryptoeconomic incentives and honesty assumptions in bridges today, let’s evaluate a common use case for bridges today: asset movement.

Suppose a user (which we call Alice) wants to move a token from chain A to chain B. The usual method (although other means exist) is to lock Alice's tokens on the source chain (chain A) and issue a derivative asset on the target chain (chain B).

For cross-chain bridges, the critical part of the operation is getting chain B to accept that an event (i.e., locking tokens) happened on chain A. But this is difficult to implement since chain A and chain B cannot interpret and validate each other’s state, especially if they have different consensus mechanisms, validator sets, and security properties.

One solution is to run a light client on the target chain which stores block headers from the source chain. The target chain could then verify the existence of certain transactions by verifying transaction Merkle proofs against state roots contained in block headers. The drawback is that this approach can be compute-intensive and requires investing significant costs in gas fees.

Most bridges attempt to work around this problem by replacing light client verification with validation of on-chain events by third parties. Under this arrangement, someone watches both chains for specific transactions (e.g., token deposits and burns) and approves withdrawals and deposits to the bridged blockchains.

If Alice uses a centralized bridge, the “someone” could be a centralized bridge operator or the member of a permissioned committee. In this case, the relayer would be trusted to relay correct information about on-chain events to the bridge protocol.

A decentralized bridge would allow anyone to relay cross-chain messages, but requires participants to stake some capital first. Since this stake can be slashed if another participant detects fraud, relayers are economically incentivized to act honestly. Still, this approach requires users to trust that at least one honest actor exists to challenge invalid messages via fraud proofs.

Unlike the aforementioned bridge designs, a trustless bridge removes the need to trust parties relaying messages between different blockchains. Specifically, trustless bridges combine light client verification of state updates on a chain and zero-knowledge proofs to provide a robust mechanism for secure cross-chain communication.

We should note that trustless bridges described in this article don’t refer to canonical rollup bridges (e.g., Arbitrum Bridge), which are also trust-minimized by design. Instead, we describe a type of trustless bridge connecting any two blockchains that also validates relayed messages with validity proofs.

The architecture of trustless bridges

Light clients

A light client synchronizing block headers of the source chain is implemented as a smart contract on the target chain. This ensures the target chain can verify information about the state of the source chain without relying on an external party. Moreover, it allows anyone to prove the existence of certain transactions on the source chain in the context of the target chain (using Merkle proofs).

Relayers

The task of relaying block headers from the source chain to the target chain may be handled by a single operator, a federation, or a set of incentivized parties. While the exact nature of a trustless bridge (permissioned or permissionless) doesn't affect its soundness, it can affect things like liveness and censorship resistance.

Validity proofs

Parties tasked with relaying the latest block headers are required to generate a zero-knowledge proof confirming the validity of relayed block headers to the light client contract. Note that this proof attests to the validity of the blockchain's state (represented in the block headers) according to the consensus protocol.

To be specific, the validity proof only checks that the latest block on a specific chain was approved by a majority of the chain's validators. It cannot, however, prove that the block itself is valid according to the protocol's rules. Hence, the validity proof is described as a “proof-of-consensus” and not a “proof-of-validity” (h/t to Succinct Labs for the inspiration).

The validity proof generated for a new block header verifies that:

i. The latest finalized block was signed by the majority of the validator set. A block is considered finalized if it cannot be reverted without a large portion of validators losing their stake. Currently, Proof of Stake networks such as Ethereum and Cosmos require > ⅔ of validator signatures to finalize blocks.

ii. The signatures on the latest block are valid and correspond to a publicly available set of public keys associated with the current validator set.

Besides ensuring validity of messages, validity proofs also help reduce the cost of running a trustless bridge. For context, earlier attempts to implement light client verification of cross-chain events ran into problems due to the complexity and high cost of verifying validator signatures on-chain.

Trustless bridges solve the problem of verification costs by taking advantage of the succinctness of zero-knowledge proofs. By succinctness, we mean that validity proofs remain constant in size regardless of how much time is spent on computing the original witness. As Vitalik Buterin puts it:

“A zkSNARK allows you to generate a proof that some computation has some particular output, in such a way that the proof can be verified extremely quickly even if the underlying computation takes a very long time to run.”

The succinctness of ZK proofs makes it possible to cheaply verify signatures off-chain and compute a proof attesting to the validity of the signatures. As proofs are constant-size, the cost of verifying them is orders of magnitude lower than verifying signatures from multiple validators on-chain.

Bridge contracts

Like traditional cross-chain bridges, trustless bridges will have contracts deployed on bridged blockchains to process deposits and withdrawals. Typically, a deposit or withdrawal is approved only if the bridge contract has received a signed message from a relayer that the user’s request is valid.

Trustless bridges are different in that they only acknowledge withdrawals or deposits after receiving a header from the light client contract proving the existence of a deposit or withdrawal transaction. This would require users to simply provide a Merkle proof that shows the inclusion of the transaction in whatever chain they’re bridging from. The infographic below shows how this might work in practice:

Possible workflow for a trustless bridge protocol. (source)

Why blockchain interoperability needs trustless bridges

As explained, trustless bridges reduce the need to trust external actors involved in cross-chain communication to act honestly. More importantly, the combination of light client verification and validity proofs reduces the likelihood of bridge contracts acting on incorrect or false information.

This doesn't imply trustless bridges can totally eliminate the need for trust (“trust-minimized bridges” may be a more accurate term for this reason) in cross-chain communication. Users still need to trust that a blockchain is economically secure such that any coordinated attempt to create invalid blocks results in heavy losses for would-be attackers.

For example, an attack on a bridge may work if a majority of validators (⅔) sign an invalid block and go offline to avoid slashing. However, this is not feasible since offline validators are subject to heavy penalties in PoS networks like Ethereum or Cosmos.

Besides improving the validation of cross-chain information, trust-minimized bridges can also remedy two issues that plague current bridge designs: centralization and operational inefficiencies. Both problems are intertwined and form part of the blockchain interoperability trilemma.

Centralized bridges improve efficiency by using a central operator or a small set of approved entities to verify cross-chain messages. However, this opens up several attack vectors, including censorship of users and the possibility of bridge operators getting compromised.

Decentralized bridges are permissionless—allowing a diverse group of incentivized parties to act as oracles providing information about events happening on other chains. To ensure safety of the bridge, relayers may be required to stake capital that can be slashed in the event of fraud. This system, however, promotes capital inefficiency as it forces participants to lock up capital that could be used elsewhere.

Besides, the dispute arbitration mechanism works only if honest parties have enough time to detect malicious activity among relayers and initiate challenges. As such, optimistic bridges may force users to wait for a specific period before withdrawing funds.

By using non-interactive validity proofs to verify operations on bridged blockchains, trust-minimized bridges solve the problems described above. For example, even if control of a bridge is centralized, it is impossible for those involved to relay invalid or non-existent state updates. (This assumes that the underlying cryptographic protocol for generating proofs is sound such that it is infeasible to generate false proofs.)

Moreover, without the need to rely on dispute arbitration to defend against invalid operation, bridges can reduce latency for users to a negligible amount. In this scenario, the delay in withdrawing would correspond to the time it takes to generate a zero-knowledge proof for relayed block headers.

Trustless bridges in production

Building trustless bridges is difficult, which explains why you don't see such bridges in use today. Some of these reasons include the costs of verifying validity proofs on-chain and the compute-intensive nature of proof generation.

Fortunately, advances in proving technology (e.g., distributed proof computation and recursive proving) and increasing demand for interoperability (driven by the explosion of blockchain ecosystems) are fueling efforts to build trust-minimized bridges for blockchain users. We highlight some major projects working on trust-minimized solutions to the blockchain interoperability problem below:

Telepathy

Succinct Labs is dedicated to creating a decentralized and permissionless interoperability protocol for Ethereum. The team has already created a proof of concept of a ZK-enabled light client bridge between Gnosis Chain and Ethereum.

Telepathy, as Succinct calls its trustless bridge, relies on Ethereum’s light client protocol to track recent blocks finalized on Ethereum. The bridge consists of an off-chain component that generates proofs for relayed block headers and an on-chain component responsible for verifying proofs submitted by relayers.

ZK-Bridge

ZK-Bridge is an effort by academics affiliated with the Research and Development Institute (RDI) at the University of Berkeley. Like Telepathy, ZK-Bridge relies on a decentralized relay network to submit block headers and compute validity proofs.

The main innovation in ZK-Bridge is the use of a two-layer proof generation mechanism. Proofs are generated in parallel by relay network nodes using a modified version of the Virgo prover (called deVirgo) and aggregated into a single proof. These proofs are submitted to a Groth16 prover, which generates a constant-sized ZK-SNARK proof attesting to the correct execution of the Virgo protocol (and the validity of the proof).

This is important because, while Virgo significantly reduces proving time, the generated proofs are too large to verify on-chain. The Groth16 prover is slower, but generates smaller proofs and reduces verification costs. Thus, combining deVirgo and Groth16 allows ZK-Bridge to speed up proof generation and reduce costs (achieving efficiency and cost-effectiveness).

ZK-IBC

Electron Labs is working on a bridge between Cosmos and Ethereum that utilizes a light client protocol and ZK-SNARKs to prove state changes on Cosmos chains to Ethereum nodes. The bridge's name partly derives from IBC (Inter-Blockchain Communication), a protocol for passing messages between chains in the Cosmos ecosystem.

As noted in an introductory post on Etheresear.ch, the cost and latency of using the ZK-IBC bridge are subject to various factors. For instance, Cosmos chains have faster block times (~ 7 seconds). If proofs were generated for each new block, it is possible that, in a worst-case scenario, the cost of generating and verifying a proof would be borne by a single user.

Conversely, if bridge operators waited for deposits to accumulate, then users would experience some delay in bridging funds. Nonetheless, the ZK-IBC team plans to implement solutions such as generating proofs with parallel machines to reduce costs and latency.

Topos

Unlike the projects described previously, Topos is a full-fledged interoperability protocol that allows heterogeneous chains to trustlessly exchange information, assets, and arbitrary data. Readers may find this somewhat similar to what Cosmos and Polkadot aim to achieve with IBC and XCM (Cross-Consensus Message Format) respectively.

However, Topos differs from Polkadot and Cosmos because it enforces the correctness of consensus information transferred between chains (called Subnets) using validity proofs. Users on one Subnet can trigger operations on remote Subnets (e.g., token mints or contract calls), but only if a Subnet certificate (which references the latest header and pending cross-chain messages) and the accompanying validity proof have been accepted on the target chain.

The future of trustless blockchain interoperability

Trustless bridges are still far from practical and none of the projects highlighted have a production-ready implementation (yet). Nevertheless, trust-minimized bridging will likely become accessible in a couple of years.

Even so, it is important to note that a trust-minimized bridge won't automatically solve all problems associated with cross-chain transfers. Moving assets between blockchains is always going to involve risk, especially when bridging between two chains that don't share security.

Suppose there's an Ethereum-Solana bridge that (a) issues Wrapped Ether (WETH) to users on Solana after verifying ETH deposits on Ethereum and (b) releases deposited ETH after verifying proofs of WETH tokens being burned on Solana. In this scenario, an attacker might profit by conducting a 51% attack on either chain and reverting blocks:

First, the attacker would send the proof of burn receipt to the bridge contract on Ethereum (i.e., after burning WETH tokens on Solana) to withdraw the ETH deposit. The validity check would pass in this situation since the transaction is included in a verified block header.

But if a 51% attack on Solana is successful, it is easy to revert the block containing the burn transaction and make it appear as if the earlier withdrawal never happened. This would free the attacker to exchange WETH on Solana for other tokens or convert to fiat currencies using an exchange.

These types of attacks highlight inherent weaknesses in cross-chain communication. In fact, another variant of this attack is described by Vitalik Buterin below, with similar consequences for cross-chain bridge users:

A variant of the bridge-related 51% attack described by Vitalik Buterin

However, if bridge TVL statistics are anything to go by, the risk of hacks won't deter users looking to explore new ecosystems from using cross-chain bridges. Hence, developing solutions for secure interoperability—the likes promised by trustless bridges—is critical in order to achieve a multichain ecosystem.

At Infura we’re building a multichain future for web3 and support 10 networks including Ethereum, Polygon, Optimism, Starnet, and will continue to constantly add new chains. We’re seeing new L2s pop up everyday like Base, the new L2 built by Coinbase on the OP Stack, as well as the new zk-rollup ConsenSys is building. As new chains emerge we look forward to seeing how interoperability matures with the support for trustless bridges and will be there to provide the resilient infrastructure and data availability blockchain apps require to scale.