With the launch of Aptos, Sui, numerous Layer 2s, and even talk of Layer 3s on the horizon, it is clear that the future will be multi-chain. But for these chains to sustainably co-exist, we must have reliable ways of bridging across them.
Bridges remain one of the main vectors for attack within decentralised networks, because transmitting information across blockchains involves relaying messages off-chain, which introduces elements of centralisation and exposes the system to exploits.
In the past year alone, we have seen multiple bridge hacks, amounting to >$2B in total value lost. For example:
In August 2022, Nomad was exploited for $190M due to a smart contract bug that resulted in all cross-chain messages being approved, allowing anyone to withdraw funds from the bridge.
In August 2021, PolyNetwork was exploited for $611M because the network centralised its point of failure to a single keeper. By requiring no consensus between validators on the network, the breach of one keeper was sufficient for an exploit.
A bridge, put simply, is a means of transporting an asset from one blockchain (the source chain) to another (the destination chain). Bridging assets can be useful for several reasons:
Extending functionality: for example, allowing users to benefit from applications available only at the destination chain. The Bitcoin network does not natively support smart contracts, but users can bridge their Bitcoin to Ethereum via Wrapped BTC (wBTC) to use it in trading, lending and other applications.
Relieving congestion: offloading transaction volume to a cheaper chain can help reduce gas costs. If the source chain becomes overly congested, it may be more efficient to bridge an asset to a different chain and swap the asset there instead.
Composability: when interacting with a regular web application, we don’t care what backend database provider is being used to run it, because that fact is abstracted away from the end user. In the same way, users in web3 should be agnostic to the blockchains on which dApps are deployed. To achieve this, applications must be fully composable across chains through seamless bridging.
There are four main types / implementations of bridges today:
Pooled funds
Locking / issuance
Burning / minting
Cross-chain AMMs
The pooled funds method requires a bridge operator to maintain a pool of assets on each of the source and destination chains, against which users can deposit and withdraw assets to “transfer” their assets across chains. This method is fast, but the downside is that the operator must maintain the pools of assets (i.e. if there is a net inbalance in the flow of funds across chains, one side of the pool will over time be drained). These setups are also often centralised, meaning they are not trustless for the end user.
This method involves the user locking a token into a smart contract on the source chain, then the bridge operator minting a wrapped version of the token on the destination chain. To unlock their deposited tokens, the user must carry out the same process in reverse—by burning the newly minted wrapped tokens through the smart contract on the destination chain, and unlocking their deposit at source.
While the balance of funds problem is now solved, the deposit mechanism creates a host of new issues. For example, what happens when you bridge from the destination blockchain to a third blockchain (a phenomenon known as double wrapping)? This creates an accounting nightmare because wrapping requires you to retrace your steps—wrapping there and wrapping back doesn’t give you back the asset you started with.
Burning / minting is similar to wrapping, but the token is burned at the origin chain. This creates more flexibility as it avoids the problem of double wrapping. However, each bridge operator continues to maintain its own ecosystem of wrapped tokens (renBTC, wBTC, tBTC, etc), none of which are interchangeable, which leads to a loss of composability and liquidity fragmentation.
It’s also pretty bad from a UX perspective. Ideally you want a single canonical version of the token on each chain, not multiple representations. Every time a user bridges their assets across chains, they need to carry out an additional swap to get back to that canonical asset.
Of course, locking / issuance and bridging / minting are both subject to smart contract and other technical and operational risks. This becomes heightened when the network of blockchains connected to the bridge grows.
Cross-chain AMMs are a more novel way to bridge assets across chains, popularised by ThorChain. It is similar to the pooled funds approach, but replaces the operator-managed pool with a decentralised liquidity pool. The core innovation here is that each side of the pool sits on a different chain. The operator relays price and TVL updates through a messaging protocol such as LayerZero (as in the case of Stargate), ensuring that the pool remains in balance.
Cross-chain AMMs are innovative but could suffer from illiquidity. The messaging layer may also be vulnerable to attack. For example, ThorChain was hacked twice in 2021 due to smart contract exploits.
Bridges vary in their design, but as a general matter, bridges that rely on a more decentralised messaging layer (the part where data is handled off-chain) are more robust than custodial ones, particularly where those points of failure reside with a handful of keepers.
Below, I discuss some of the major centralised, optimistic and trustless bridging solutions today in laying out a path toward decentralising the messaging layer.
Centralised bridges have been around for a long time now. Wrapped BTC (wBTC), the most liquid form of Bitcoin tokens on Ethereum today, is issued by BitGo in a semi-centralised manner. In a way, companies like Circle (the consortium behind USDC) are de facto bridges between fiat USD and USDC tokens.
Centralised bridges work, until they don’t. If web3 is meant to be about self-custody and permissionless access, it seems bizarre that we would risk censorship every time we move our assets across chains. Over the long term, I would expect centralised bridging solutions to be phased out, or continue to move toward decentralisation.
Most bridging solutions today are optimistic by design. This type of bridging generally involves two parties: a transporter, who transfers the data, and a verifier, who verifies that the message has been delivered correctly. If the verifier finds an error in the data, it can initiate a challenge within a given time window to revert the message. Because of the challenge period, bridge operators typically front users the money to allow for instant settlement from the end user’s perspective. This introduces some risk of loss over the pool of unconfirmed transactions.
Often, a network of verifiers is used for proving fraud (where only one honest verifier is required to revert a fraudulent message). In this type of setup, the messaging layer becomes exponentially more secure as the verifier network grows.
The optimistic messaging space has a large number of players.
Nomad is a cross-chain token bridge that uses a system of off-chain Updaters and Watchers to optimistically transport data between chains. It aims to be the TCP/IP layer of web3, and implements 1-of-N verification with a 30 minute challenge window.
Portal / Wormhole is another cross-chain token bridge with a slightly different setup. In this network, the role of transporter and verifier is combined into a single role known as the guardian. Guardians both observe messages and sign their payloads as a signature. Messages are transmitted only if consensus is achieved by the majority of the network.
Across is a optimistic bridging solution focused on bridging between EVM compatible chains (including Layer 2 chains). Like Portal, it relies on a group of relayers to transport messages.
Hop Protocol is another Layer 2 focused token bridge with a slightly different technical setup. It uses a system of specialised tokens (known as hTokens) which can be batched and moved across chains. These act as the accounting system for bridging: user assets are automatically swapped for hTokens, bridged to the destination chain, then swapped back. As with other optimistic solutions, the protocol provides liquidity to the end-user upfront for instant transfers.
Trustless bridges further improve upon optimistic bridges by implementing bridging at the consensus layer of the blockchain. As blockchain validators process transactions into blocks, they can serve as the canonical source of truth for the state of a network.
Trustless bridging works by running a light client of on a blockchain, encoded as a smart contract, which verifies cryptographically the state of the opposing chain. It does this by taking in the block hash and other information, and recomputing the merkle root. In other words, a light client acts as a sort of lightweight validator that proves state without storing any blocks. By proving the state of the network on-chain, it is possible to retrieve information about emitted events, account balances, and so on (everything you need to implement bridging).
Light client verification is most notably implemented by Cosmos and its Inter-Blockchain Communication (IBC) protocol. This is natively implemented for chains in the Cosmos ecosystem, and unlike competing solutions like XCMP on Polkadot, is generalisable for communication between heterogenous blockchains, including Ethereum.
To that end, Herodotus and Slush are building toward EVM-focused rollup-to-rollup trustless bridging solutions, though with slightly different architectures. Herodotus works by transmitting the block header from the source chain to the destination chain, before recursively iterating backward over the blockchain to prove information about any historical block. Slush combines the generalised light client solution with ZK proofs to trustlessly mint and burn tokens across chains.
While trustless bridging is promising, there are a number of problems that first need to be solved. For one, implementing light client logic on-chain is difficult and relies on precompiles which may not be available to developers. The cost of proving operations is also expensive, particularly where they involve hashing algorithms that have a high gas cost. Given these factors, it may be a while yet before we see light client solutions emerge on the market.
It’s safe to say though: the future of bridging looks optimistic … and also increasingly trustless. As we march toward a multi-chain future, I personally am excited about the new innovation that will emerge in this critical infrastructure layer of the blockchain.