Crossing The Bridge

With an increase in the amount of different Layer 1 (L1) and Layer 2 (L2) chains available to DeFi users, the demand to move assets between these different chains has increased proportionally. Since these other chains operate independently of one another, interoperability is a problem that needed solving and this is where bridges come in. Bridges are protocols that are assembled to solve the interoperability between different blockchains and allow messages and hence, assets, to be ‘sent’ from one chain and ‘received’ by another. At a high level, this concept seems great and actually works fairly well. However, as crypto has taught us, nothing comes easy and bridges have proven to be an extremely lucrative vector for bad actors to attack. It is estimated that over $2.6 billion have been stolen in cross-chain bridge hacks since the beginning of 2022 and unfortunately, this does not seem to be the end of it.

This post will dive into the details of what bridges actually are, how they work, the different types of bridges that exist, and their associated security risks.

Credit to https://www.crosschainbridge.org/

Bridges - Why, Where, and Who?

Why do we need bridges?

Blockchains are developed in isolated environments, having different rules and consensus mechanisms. Different protocols are built on and support different chains and in order to interact with them, users must control assets on a chain that the protocol supports. If the user does not have assets on the required chain, they will need to move their assets from one chain (source chain) to another (target chain). Bridges provide a solution to move assets between chains by providing a connection between these isolated ecosystems and allowing for cross-chain interoperability.

Where do we need to use bridges?

If you are in a situation where you need to move assets from one chain to another and would like to do so without a centralized intermediary facilitating the process (such as a centralized exchange), then bridges provide you with a fully on-chain solution. The ‘chains’ that you would need to move assets between can be categorized generally as either Layer 1 (L1) or Layer 2 (L2). Therefore, the main use cases of bridges would be to move funds as follows:

• Between two L1s (e.g. Wormhole bridge between Ethereum and Solana)

• Between an L1 and an L2 (e.g. Stargate or Celer)

• Between two L2s (e.g. Hop protocol or Orbiter finance)

Who controls and maintains the security of the bridge?

When it comes to controlling and governance, bridges come in two flavors; trusted and trustless. The ‘trust’ of a bridge refers to the reliance, or lack thereof, that a bridge has on an entity to maintain its functionality and security.

Trusted bridges rely on centralized entities in order to operate - examples of these are the Ronin bridge and the Binance bridge. Trustless bridges, on the other hand, operate in a more decentralized way and rely on immutable code within smart contracts to keep them up and running - examples are Hop protocol and Connext. It is, however, worth mentioning that these trust models can be combined and a bridge could have both trusted and trustless components, which can be built out in different ways depending on the protocols’ design decisions.

Types of bridges

Web3 and DeFi are emerging ecosystems that have forced creative innovation around bridging mechanisms. As of now, there is no de-facto standard outlining how a bridge should be built and how it should operate. All mechanisms being used to build bridges today offer their own advantages but do come with limitations. A decision on how a bridge should be implemented depends on many factors and trade-offs need to be made by developers in order to create the solution that best serves their needs and the needs of their users. Let’s dive into some of the leading bridge solutions being used today.

Pool-based bridge

Fundamentally, this works by having ‘pools’ (i.e. smart contracts that hold funds) that reside on each chain and facilitate the transfer of tokens that are natively deployed on both chains. Let’s say a user wants to move USDC (an ERC-20 token native to Ethereum) from the Ethereum mainnet (an L1) to Avalanche C-Chain (another L1). First, the user deposits their USDC into a pool on Ethereum and in doing so, defines the address to which the corresponding funds on Avalanche should be sent. The bridge operator (i.e. a cross-chain messaging protocol) relays the message and transfers USDC (which also exists as a native token on Avalanche) from a pool on Avalanche to the specified address. By having a pool on each blockchain, the bridge can easily maintain “book management” and communication between the blockchains.

Credit to Amber group - https://medium.com/amber-group/bridges-designs-trade-offs-and-opportunities-2196b8754e70

Advantages:

• No need to rely on pool security after receiving tokens on the new chain, as this bridging mechanism relies on natively deployed tokens, meaning their value is not derived on collateral stored on the source chain (i.e. the deposit pool on Ethereum).

Limitations:

• If the pool on the target chain is empty, the deposited asset could get stuck until another user requests the reverse transfer (i.e. until extra liquidity is provided to the ‘empty’ pool on the target chain).

• Cross-chain asset transfers are limited to tokens that exist natively on both chains.

Lock & Mint Bridges

These types of bridges rely on an asset being ‘locked’ in a contract on the source chain and then a ‘wrapped’ (i.e. synthetic) representation of that token being ‘minted’ (i.e. created) on the target chain. For example, let’s say a user wants to bridge their USDT tokens from Ethereum to Avalanche using a lock & mint bridge. They will need to send their USDT tokens (which are native tokens on Ethereum) to be locked in a designated smart contract owned by the bridge, while once again specifying the address to where they would like to receive the tokens on Avalanche. The bridge’s messaging protocol then sends a message to a contract on the Avalanche chain instructing it to mint the corresponding amount of tokens that the user locked up and send it to the specified address. In this example, the minted token would be ‘USDT.e’, which is the synthetic version of USDT that exists on Avalanche.

Unlike in the pool-based bridge example, USDT.e is not a native token and has no intrinsic value. The value of this token is derived from the corresponding native token that is locked on the source chain (i.e. USDT on Ethereum) and therefore holds the same value as it since it is backed one-to-one and can always be redeemed for the equivalent amount of native tokens. In order to redeem (i.e. bridge back to the source chain), a user will send their USDT.e to a contract on Avalanche which will then burn the token (i.e. destroy it) and then ‘release’ the corresponding amount of previously locked USDT tokens on the Ethereum chain.

Credit to Quailaudits - https://quillaudits.medium.com/bridge-security-in-blockchain-quillaudits-f4710d1d61d

Advantages:

• Unlike pool-based bridges, the ability for these bridges to operate is not dependant on the liquidity in a pool and can always allow for the transfer of assets between the source and target chain.

Limitations:

• In the case of the pool on the source chain being exploited and drained of the underlying assets, the bridged tokens (i.e. the wrapped/synthetic tokens) become worthless since they are no longer backed one-to-one with a native asset on the source chain.

Native Swap Bridge

This type of bridge is used to facilitate the swapping of native coins from one chain to another. A native coin is the inherent digital currency of a particular blockchain, for example, Ethereum’s native coin is ETH, Polygon’s native coin is Matic, Avalanche's native coin is Avax, etc. Because a native coin, by definition, can only exist in its native state on a specific blockchain, this bridging mechanism operates by swapping a native coin on a specific blockchain for the equivalent value of another native coin on another blockchain.

For this example, let’s take a user that wants to swap BTC on Bitcoin for ETH on Ethereum. The bridge is comprised of two vaults, one on each blockchain, and an additional intermediary chain used to facilitate the swap. The user sends BTC to the bridge’s BTC vault along with the recipient’s address on Ethereum. The BTC vault is controlled and monitored by nodes on the Bitcoin blockchain that update the state on the bridge. The intermediary chain then calculates the amount of ETH that the recipient should receive and sends the information to the Ethereum vault. Once confirmed, the nodes then send a message to the Ethereum vault to send ETH to the recipient’s address.

https://docs.thorchain.org/how-it-works/technology

Advantages:

• Higher level of decentralization and censorship resistance.

• None of the risks associated with wrapped assets.

Limitations:

• Architecture is highly complex and is difficult to design and implement securely.

• Requires the bridge to run multiple full nodes on all blockchains that are serviced.

• Liquidity providers are still vulnerable to hacks and exploits on the vaults.

Native Swap Bridge via stablecoins

This bridge is an implementation that combines elements of both pool-based bridges and native swap bridges. In this example, we will take a user that wants to bridge SOL from Solana Network to BNB on Binance Smart Chain (BSC). First, the user sends SOL to a bridge contract on Solana and triggers the contract to swap the SOL to a native stablecoin on Solana (e.g. USDC). After the swap is executed, the contract sends the data to the bridge's intermediary actor, who then transfers this data to the bridge’s USDC pool on BSC. This then triggers the pool on BSC to perform a swap from USDC to BNB and this is then sent to the recipient’s address on BSC.

Advantages:

• None of the risks associated with wrapped assets.

• Better price execution due to the utilizaztion of stablecoins in place of price oracles.

Limitations:

• Risk of receiving an unfavorable price depending on the available liquidity of each AMM.

• Same liquidity risks associated with pool-based bridges.

Bridge Risks

Anecdotally, there has been a lot of evidence pointing towards bridges being insecure and vulnerable to a whole host of different attacks. A huge amount of funds have been stolen through exploiting different elements in the supply chain of a bridge. Some of the main, high-level risks associated with bridges are listed below:

• Fake events: If an attacker can generate a fake deposit event on one blockchain, then they can withdraw assets from the bridge on the corresponding target chain (BSC bridge hack).

• Data integrity: When a malicious actor successfully attacks the underlying verification method used by the bridge (Nomad bridge hack).

• Validator takeover: Some bridges have validators that vote whether or not to approve a transfer. If the attacker controls a majority of these validators, they can approve malicious transfers (Ronin hack, harmony bridge hack).

• Liquidity: If a bridge doesn’t have asset pools with sufficient liquidity on both the source and target chains, the user will be unable to execute the action.

• Censorship: If a “trusted” (i.e. centralized) custodian refuses to mint and/or burn tokens in alignment with the bridging requirements, funds could remain locked or essentially get ‘lost’.

• Admin private keys: Once the private keys of an entity with admin privileges on relevant contracts get exposed, the funds held or controlled by these contracts are at risk.

Closing thoughts

Although there is an increasingly high demand for bridges and the blockchain use cases they enable, there is a lack of standardization in the design and implementation of bridging mechanisms and their associated security requirements. For those of us that plan to continue using bridges, we recommend the following three tips to mitigate their inherent risks:

1. Only use bridges that have been audited by multiple, reputable third parties.

2. Ensure the bridge’s governing entity has a sizeable bug bounty program.

3. Where possible, obtain the most comprehensive insurance available.

Appendix: Notable hacks

<br/>

| Bridge | Date | Type | Exploit | $ | | ----------------------------------------------------------------------------- | --------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---- | | Ronin Network | Mar 23, 2022 | POA sidechain | Root of trust: attacker gained access as a validator and signed a transaction on their behalf | 624M | | BNB Bridge | Oct 06, 2022 | Lock & Mint | Smart contract exploit: The attacker could forge false proof of deposit on the old beacon chain by using a specific block and specific data to manipulate the root hash of the IAVL tree. | 586M | | Wormhole | Feb 3, 2022 | Lock & Mint | Smart contract exploit: flaw allowed the hacker to mint 120,000 wETH on Solana without depositing ETH | 326M | | Nomad | Aug 1, 2022 | Home & Replica | Smart contract exploit: a bug enabled the attacker to pass any message through validation (i.e. bypass validation) and get it executed. | 190M | | Harmony | Jun 24, 2022 | Lock & Mint | The attacker took control of the bridge by compromising two private keys. | 100M | | THORChain | Jul 16+26, 2022 | Native Swap | Smart contract exploit: flaw allowed the attacker to wrap the router with their own contract and create fake deposits | 13M | | Multichain | Jan 18, 2022 | Pool-Based / Lock & Mint | Smart contract exploit: flaw allowed an attacker to steal tokens from users who had previously created approvals for them | 3M |

<br/> <br/> <br/>

Materials used when researching this topic:

1. https://medium.com/amber-group/bridges-designs-trade-offs-and-opportunities-2196b8754e70

2. https://hackernoon.com/how-are-cross-chain-bridges-hacked

3. https://ethereum.org/en/bridges/#types-of-bridge

4. https://quillaudits.medium.com/bridge-security-in-blockchain-quillaudits-f4710d1d61d

5. https://telegra.ph/Cross-chain-bridge-attacks-A-Z-05-07?ref=hackernoon.com

6. https://rekt.news/

7. https://debridges.com/

8. https://defillama.com/bridges