Bridging Toward A Multi-Chain Future
Cross-chain messaging, optimistic bridging, trustless bridging, IBC and light clients.
Key takeaways
With the future looking increasingly multi-chain, it is more important than ever to have reliable ways of bridging assets across chains.
Bridging remains one of the larger vectors for attack within decentralised networks, because transmitting information across blockchains involves relaying messages off-chain.
There are four main implementations of bridges, each with their own tradeoffs:
Pooling funds requires the bridge operator to manage the balance of funds and poses centralisation risks.
Locking / issuance is prone to the double wrapping problem and, like burning / minting, suffers from a lack of composability / bad UX.
Cross-chain AMMs like Stargate and ThorChain are interesting alternatives, but could be prone to the problem of illiquidity.
Most bridging solutions today are either centralised (e.g. wBTC) or optimistic (e.g. Nomad, Portal). Optimistic bridges work via a system of two parties: a transporter, who transfers the data, and a verifier, who verifies that the message has been delivered correctly (with only 1-of-M honest verifiers needed to secure the network).
Trustless bridges are an emerging class of solutions that work by running a light client natively (as a smart contract) to cryptographically verify the state of an opposing chain. By proving the canonical state of the network on-chain, it is possible to prove state, emitted events, account balances and so on.
Cosmos and IBC are furthest ahead in this field, although the principle of light clients is generalisable to other chains. To that end, Herodotus and Slush are building toward rollup-centric trustless bridging solutions for Ethereum.
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.
Types of bridges
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: users interacting with a regular web application aren’t required to know or care about what backend database provider is being used to run it. In the same way, web3 users should be agnostic to the specific blockchain on which dApps are deployed. To achieve this, applications must be fully composable across chains and assets freely bridgeable.
There are four main types / implementations of bridges today:
Pooled funds
Locking / issuance
Burning / minting
Cross-chain AMMs
1) Pooled funds
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.
2) Locking / issuance
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 unwrapping requires you to retrace your steps—wrapping there and wrapping back doesn’t give you back the same asset you started with.
3) Burning / minting
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.
4) Cross-chain AMMs
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.
Decentralising the messaging layer
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 bridging solutions today and lay out a path toward their decentralisation.
Centralised bridges: “The Bad”
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. Companies like Circle (the consortium behind USDC) have long acted as 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).
Optimistic bridges: “The Okay”
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 error with 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 for the end user. This introduces some risk of loss for the pool operator in respect of the pending and 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 is crowded with a large number of players. Here are some of the main ones:
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: “The Good”
Trustless bridges further improve upon optimistic bridges by implementing bridging at the consensus layer of the blockchain. As blockchain validators are responsible for process transactions into blocks, they serve as the canonical source of truth for the state of the blockchain, meaning they are the most secure way to implement a bridge.
Trustless bridging works by running a light client on a blockchain, encoded as a smart contract, which verifies cryptographically the state of an 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. By conducting the proof 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 bridge tokens across chains. It is focused on creating an SDK for spinning up composable L3 appchains.
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 that 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 head toward a multi-chain future, I am personally excited about the new innovation that will emerge in this critical infrastructure layer of the blockchain.
Hi, I’m Park!
Open Source Web is a blog to document my journey into the complex and fast-moving world of Web 3. In this blog, I share ideas, insights and key learnings from the latest developments in the crypto space.
If you enjoy Open Source Web, please consider subscribing and sharing it with your network to help build this community!