Crosschain Bridge Analysis - An Introduction

• date: 2023-02-04
• last updated: 2023-02-04

Here we present a survey of existing bridge designs, historical security incidents, and a brief discussion of common components and where ZKP may be used.

Bridge Taxonomy

Bridge designs evolved as DeFi and multi-chain paradigm gained popularity. Our summary is inspired by prior taxonomy work by Ganesha Upadhyaya in A Classification of Various Bridging Technologies, Dmitriy Berenzon in Blockchain Bridges: Building Networks of Cryptonetworks, and by multiple researchers from Jump Crypto in Security Stack-Up: How Bridges Compare

At a very high level, there are two types of bridging solutions: 1) proof-based and 2) committee-based. The proof-based solutions entail cryptographic proving of the validity of any transaction of one chain in the other, whereas the committee-based solution relies on the social consensus of the bridge validators to attest for the transaction validity, which often involves no cryptographic proving.

• Ganesha Upadhyaya in "A Classification of Various Bridging Technologies"

Proof Based

Validity Proofs

Validity-proof based bridges prioritize security, trustlessness, permissionlessness, and delay minimization

Fraud Proofs

Fraud-proof based bridges assume all participants are truthful unless someone presents a proof showing otherwise. As a result, they must leave a wide fraud-proof time window and carefully design economic incentives for such. This limitation inevitably incurs much higher delay, but makes implementation substantially easier and costs significantly less to operate and maintain. Fraud-proof based bridges face more security risks due to reliance on fraud-prover and economic incentives, but still far less risky than committee-based bridges.

Committee Based

Others

Miscellaneous

• TVL of bridges can be found on DeFi Llama
• Some tools and queries are already prepared on Dune Analytics for analysis of bridge volume. See for example: https://dune.com/queries/511393.

Bridging Components

Following are the main components for Cross-Chain Bridges we review

• Approach : The design approach for the bridge
• Proving Mechanisms: How do we ensure transactions are valid
  • Transaction Proofs: How do we ensure a transacion was included in a valid block
  • Block Proofs: How do we ensure a block was included in the canonical chain
• Relayer Mechanisms
  • Relaying: How do we relay messages (blocks and transactions) between chains
• Light Clients: What Light client approaches can we leverage
• Token Lockers: How do we safely store bridged assets in a trustless cost effective way
• Multi-chain support: What chains are supported and what is the proces to add additional chains.
• Economics: What are the costs for bridging between chains and how do we secure and incentivize validators and relayers.

Cross Chain Communication Protocols

• INTER‑BLOCKCHAINCOMMUNICATION PROTOCOL
• Cosmos IBC: Interchain Standards
• IBC Update— The Internet of Blockchains Is Growing Fast
• Polkadot Cross-Consensus Message (XCM) Format
• XCMP Design
• HRMP Channels
• The Path of a Parachain Block
• Parity Bridges Common

Bridge Attack Vectors and Hacks

Following is an overview of some common bridge attack vectors.

• Vitalik; security limits of bridges

Now, imagine what happens if you move 100 ETH onto a bridge on Solana to get 100 Solana-WETH, and then Ethereum gets 51% attacked. The attacker deposited a bunch of their own ETH into Solana-WETH and then reverted that transaction on the Ethereum side as soon as the Solana side confirmed it. The Solana-WETH contract is now no longer fully backed, and perhaps your 100 Solana-WETH is now only worth 60 ETH. Even if there's a perfect ZK-SNARK-based bridge that fully validates consensus, it's still vulnerable to theft through 51% attacks like this.

It's always safer to hold Ethereum-native assets on Ethereum or Solana-native assets on Solana than it is to hold Ethereum-native assets on Solana or Solana-native assets on Ethereum. And in this context, "Ethereum" refers not just to the base chain, but also any proper L2 that is built on it. If Ethereum gets 51% attacked and reverts, Arbitrum and Optimism revert too, and so "cross-rollup" applications that hold state on Arbitrum and Optimism are guaranteed to remain consistent even if Ethereum gets 51% attacked. And if Ethereum does not get 51% attacked, there's no way to 51% attack Arbitrum and Optimism separately. Hence, holding assets issued on Optimism wrapped on Arbitrum is still perfectly safe.

Why a rollup can't just "go use another data layer". If a rollup stores its data on Celestia or BCH or whatever else but deals with assets on Ethereum, if that layer gets 51% attacked you're screwed. The DAS on Celestia providing 51% attack resistance doesn't actually help you because the Ethereum network isn't reading that DAS; it would be reading a bridge, which would be vulnerable to 51% attacks. To be a rollup that provides security to applications using Ethereum-native assets, you have to use the Ethereum data layer (and likewise for any other ecosystem).

Here are some sample hacks

• Vulnerabilities in Cross-chain Bridge Protocols Emerge as Top Security Risk

Following last night’s exploit of the Nomad Bridge, Chainalysis estimates that $2 billion in cryptocurrency has been stolen across 13 separate cross-chain bridge hacks, the majority of which was stolen this year. Attacks on bridges account for 69% of total funds stolen in 2022 so far.

• EXPLAINED: THE QUBIT HACK (JANUARY 2022)

The exploited contract used a modified safeTransferFrom() function which instead of making use of functionCall() to verify that the target address contained contract code, used the call() function directly. As the 0 address has no code at all, no code is run, and the call is completed successfully without reverting. As a result, the deposit function executed successfully but no real tokens were deposited.

The Ethereum QBridge caught the Deposit event and interpreted it as a valid deposit of ETH. As a result, qXETH tokens were minted for the attacker on BSC.

• EXPLAINED: THE WORMHOLE HACK (FEBRUARY 2022)

The actual extraction of 120k ETH from the Wormhole bridge came at the end of a series of events. The actual flow of the attack was:

1. The attacker creates a validator action approval (VAA) with a call to post_vaa
2. This VAA was used in a call to complete_wrapped to mint the 120,000 ETH extracted in the attack
3. The attacker “legitimately” extracted the minted tokens from the bridge

The vulnerability that made the attack possible was a failure to perform proper signature verification in the VAA creation process. The role of signature verification is delegated several times from post_vaa to verify_signatures to Secp256k1.

• EXPLAINED: THE RONIN HACK (MARCH 2022)

The Ronin Network attack was extremely stealthy. In fact, the hack wasn’t noticed until six days after it occurred when the project team was notified by a user that they couldn’t withdraw about 5k ETH from the project’s bridge. Further investigation discovered the largest hack in DeFi history to date.

The Ronin Network hack was made possible by compromised private keys. The Ronin Network uses a set of nine validator nodes to approve transactions on the bridge, and a deposit or withdrawal requires approval by a majority of five of these nodes. The attacker gained control of four validators controlled by Sky Mavis and a third-party Axie DAO validator that signed their malicious transactions.

• EXPLAINED: THE HARMONY HORIZON BRIDGE HACK

Like most cross-chain bridges, the Harmony Horizon Bridge has a validation process for approving transactions being transferred over the bridge. In this case, the approvals process uses a multi-signature scheme with five validators.

However, the bridge only used a 2 of 5 validation scheme. This means that only two blockchain accounts needed to be compromised for an attacker to approve any malicious transaction that they wished.

The Harmony Horizon bridge was exploited via the theft of two private keys. These private keys were encrypted with both a passphrase and a key management service, and no system had access to multiple plaintext keys. However, the attacker managed to access and decrypt multiple keys.

With access to two of the bridge’s private keys, the attacker could create a transaction extracting $100 million from the bridge and confirm it using two accounts under their control.

• THE NOMAD BRIDGE HACK: A DEEPER DIVE

On August 1, DeFi bridge Nomad was hacked for over $190M.

After a frenzied hack from hundreds of wallets, the bridge’s TVL dropped from 1,794 in mere hours. The hack involved a total of 960 transactions with 1,175 individual withdrawals from the bridge. According to Nomad’s post-mortem, an implementation bug in a June 21 smart contract upgrade caused the Replica contract to fail to authenticate messages properly. This issue meant that any message could be forged as long as it had not already been processed.

As a result, contracts relying on the Replica for authentication of inbound messages suffered security failures. From there, this authentication failure resulted in fraudulent messages being passed to the Nomad BridgeRouter contract.

References

Background and Overview

• Harmony’s Cross-Chain Future
• Awesome Interoperability: A curated list of awesome interoperability resources, libraries, tools and more.
• Vitalik: why the future will be multi-chain, but it will not be cross-chain
• Vitalik’s Annotated Ethereum 2.0 Spec

Background and Overview (Zero Knowledge Related)

• Bridging the Multichain Universe with Zero Knowledge Proofs
• awesome-zkml

Mathematical Theory

• Elliptic Curve Cryptography: a gentle introduction
• Exploring Elliptic Curve Pairings

Mathematical Theory (Zero Knowledge Related)

• KZG polynomial commitments

Research Papers

• Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. Light clients, also known as Simple Payment Verification (SPV) clients, are nodes which only download a small portion of the data in a blockchain, and use indirect means to verify that a given chain is valid.

Research Articles

• Paths toward single-slot finality: A look at how to improve Ethereum’s LMD GHOST + Casper FFG consensus.

Research Papers (Zero Knowledge Related)

• zkBridge: Trustless Cross-chain Bridges Made Practical
• zkPoS: End-to-End Trustless: HyperOracle article on how zkPoS provides the ability of proving the consensus with ZK.
• Caulk: Lookup Arguments in Sublinear Time
• HyperPlonk: Plonk with Linear-Time Prover and High-Degree Custom Gates

Research Articles (Zero Knowledge Related)

• SLONK—a simple universal SNARK: a simplification to PLONK called SLONK. We replace the permutation argument (the “P” in PLONK) in favour of a shift argument (the “S” in SLONK). We get a universal SNARK with the smallest known proof size and verification time.
• Kate commitments from the Lagrange basis without FFTs: how to commit, evaluate and open polynomials in the Lagrange basis without FFTs. This is the first part in a series (see part 1, part 2, part 3) showing how to do PLONK-style universal SNARKs without FFTs
• Hadamard checks from the Lagrange basis without FFTs: how to prove Hadamard relations between polynomials in the Lagrange basis without FFTs. This is the second part (see part 1, part 2, part 3) in a series showing how to do PLONK-style universal SNARKs without FFTs.
• PLONK-style SNARKs without FFTs: how to do PLONK-style universal SNARKs without FFTs. This is part 3 in a series (part 1, part 2, part 3).

Implementation Articles

• zkBridge: Trustless Cross-chain Bridges Made Practical
• Succinct Towards the endgame of blockchain interoperability with proof of consensus

Implementations

• Wormhole ethereum contracts Implementaion.sol
• bls verification contract

Documentation

• ETHEREUM DEVELOPMENT DOCUMENTATION
• MINA docs

Additional References

• nil-Foundation ETH-Mina bridge live on Ethereum testnet Ropsten

Bridge Implementation References

• Harmony Horizon Bridge: Detailed code review
  • Horizon: javascript, solidity
• Near Rainbow Bridge: Codebases
  • Near Rainbow Bridge: rust, go, solidity, javascript
  • Near Rainbow Token Connector: soldity
  • SDK
    • Near Rainbow Bridge Client: typescript
  • Frontend
    • NEAR Rainbow Bridge Frontend
• Nomad monprepo: Nomad is a cross-chain communication protocol. This repo contains the following: Smart contracts for the core Nomad protocol, Smart contracts for the Nomad token bridge SDKs for Nomad's core protocol, bridge, and governance systems, Tooling for local environment simulation and Smart contract deployment tooling.
  • Nomad rust: Nomad is a cross-chain communication standard that supports passing messages between blockchains easily and inexpensively. Like IBC light clients and similar systems, Nomad establishes message-passing channels between chains. Once a channel is established, any application on that chain can use it to send messages to others chains.
  • Nomad gelato-sdk: This crate reimplements Gelato's Relay SDK in Rust. It simply wraps Gelato Relay requests and responses to/from Gelato endpoints with Rust types and methods.
• Succinct labs: Deep dive on Succinct labs Proof of Consensus for Ethreum.
  • Proof of Consensus for Ethereum: contains both the zkSNARK circuits as well as the smart contracts needed for our succinct light client implementation, as well as prototype message passing contracts and bridge contracts.
• Datachain lcpA proxy for light client verification executed in TEE.
• Cosmos ibc-go: allows blockchains to talk to each other. This end-to-end, connection-oriented, stateful protocol provides reliable, ordered, and authenticated communication between heterogeneous blockchains.
  • Cosmos ibc: ibc specification
• Cosmos gravity bridge: Cosmos and Ethereum bridge designed to run on the Cosmos Hub focused on maximum design simplicity and efficiency.
• Axelar: based on the Cosmos SDK is the main application of the axelar network. whitepaper docs
• Celer cBridge-node: Celer cBridge relay node implementation in Golang. (docs)
  • Celer cBridge-contracts: Contracts for cBridge, cross-chain liquidity solution powered by Hashed-Timelock Transfers
  • Celer cBridge-cowa: CosmWasm Rust smart contracts for cbridge
• Wormhole: the reference implementation of the Wormhole protocol. (docs)
• LayerZero Labs LayerZero: contains the smart contracts for LayerZero Endpoints. (docs)
• Multichain CrossChain-Bridge: Cross-Chain bridge based on Anyswap MPC network. (docs)
• Synapse Protocol: a universal interoperability protocol that enables secure cross-chain communication.( docs)
  • synapse-contracts: smart contracts for Synapse Protocol.
• Hop Protocol contracts: Hop is a scalable rollup-to-rollup general token bridge. Heare are the smart contracts that power the Hop Exchange. (whitepaper, docs).
• Router Protocol: (whitepaper, docs)
• Parity Bridges Common: a collection of components for building bridges.
• Snowfork snowbridge: A trustless bridge between Polkadot and Ethereum. (docs)