Home About John Resume/CV References Writing Research

Crosschain Bridge Analysis - An Introduction

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

Type Design Code UI Note
ZKP zkBridge TBD TBD By Berkeley researcehrs (Twitter)
ZKP Telepathy Telepathy Demo By Succint Labs
Native Horizon Horizon TBD Inactive. By Harmony
Native IBC (Intro) ibc-go Various / Explorer Within Cosmos Network
Native Gravity Gravity Gravity Ethereum <-> Cosmos
Native AWM (Intro) Wrap / XSVM TBD / Explorer Within Avalanche Subnets
Native Snowbridge snowbridge TBD  
LCP Datachain LCP LCP / Demo TBD Relies on TEE enclave
LCP Avalanche TBD / Audit core.app Relies on TEE enclave (Intel SGX)

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.

Design Code UI Note
Rainbow rainbow-bridge rainbowbridge.app By NEAR
Nomad (Intro) monorepo app.nomad.xyz Hacked $200M (engineering flaw)
Darwinia (Paper) darwinia TBD / Explorer  

Committee Based

Sub Category Type Design/Docs Implementation Frontend
Protocol Validators   Cosmos Gravity Bridge gravity-bridge https://bridge.blockscape.network/ https://emeris.com/ (ON HOLD)
Proof of Stake Chain   Axelar docs axelar-core TBD
Proof of Stake Chain   Celer cBridge Celer Network Whitepaper cBridge-node, cBridge-contracts, cBridge-cowa https://cbridge.celer.network/
External Networks Multisig Horizon 1.0 github OBSOLETE
External Networks Multisig Wormhole wormhole network ecosystem
External Networks Decentralized Oracle Network (DON) Chainlink (CCIP), web Chainlink Whitepaper ccip-read N/A
External Networks Decentralized Oracle Network (DON) LayerZero, docs LayerZero https://theaptosbridge.com/bridge https://bitcoinbridge.network/bridge https://bridge.harmony.one/one
External Networks Multi-Party Communication (MPC) Multichain bridge Cross-Chain-Bridge https://bsc.anyswap.exchange/
External Networks Multi-Party Communication (MPC) Synapse Protocol, docs synapsecns https://synapseprotocol.com/

Others

Sub Category Type Design/Docs Implementation Frontend
rollup-to-rollup   Hop Protocol, docs contracts https://app.hop.exchange/
mesh-network   Router Protocol, docs Router Protocol https://app.thevoyager.io/swap
Bridge Components   Parity Bridges Common parity-bridges-common TBD

Miscellaneous

Bridging Components

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

Cross Chain Communication Protocols

Bridge Attack Vectors and Hacks

Following is an overview of some common bridge attack vectors.

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

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.

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.

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.

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.

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.

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 $190,740,000 to $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

Bridge Implementation References