Blockchain bridges

Dmitriy Berenzon, Sep 2021

After years of research & development, we are finally in a multi-chain market structure. There are over 100 active public blockchains, many of which have their own unique applications, users, geographies, security models, and design trade-offs. Despite what individual communities believe, the reality is that the universe tends towards entropy, and the number of these networks will likely continue to increase into the future.

This type of market structure necessitates the need for interoperability between these distinct networks. Many developers have realized this, and the last year has seen an explosion in blockchain bridges that attempt to unify an increasingly fragmented landscape. As of this writing, there are over 40 different bridge projects.

As of September 8, 2021; Illustrative / Not fully comprehensive

In this piece, I will:

• Explain why bridges are important

• Outline the various bridge designs and their strengths & weaknesses

• Provide an overview of the current bridge landscape

• Describe what the future of bridges might look like

Interoperability unlocks innovation

As individual ecosystems grow, they develop their own unique strengths, such as greater security, faster throughput, cheaper transactions, better privacy, specific resource provisioning (e.g. storage, compute, bandwidth), and regional developer & user communities. Bridges are important because they enable users to access new platforms, protocols to interoperate with each other, and developers to collaborate on building new products. More specifically, they enable:

Greater productivity and utility for existing cryptoassets

Bridges enable existing cryptoassets to travel to new places and do new things. For example:

• Sending DAI to Terra to buy a synthetic asset on Mirror or earn yield on Anchor

• Sending a TopShot from Flow to Ethereum to use as collateral on NFTfi

• Using DOT and ATOM as collateral to take out a DAI loan on Maker

Greater product capabilities for existing protocols

Bridges expand the design space for what protocols could achieve. For example:

• Yearn vaults for yield farming on Solana and Avalanche

• Cross-chain shared order books for NFTs on Ethereum and Flow for Rarible Protocol

• Proof-of-Stake indices for Index Coop

Unlocking new features and use cases for users and developers

Bridges give users and developers more choice. For example:

• Arbitrage SUSHI prices across DEXs on Optimism, Arbitrum, and Polygon

• Pay for storage on Arweave using Bitcoin

• Join a PartyBid for an NFT on Tezos

Bridges 101

At an abstract level, one could define a bridge as a system that transfers information between two or more blockchains. In this context, “information” could refer to assets, contract calls, proofs, or state. There are several components to most bridge designs:

• Monitoring: There is usually an actor, either an “oracle”, “validator”, or “relayer”, that monitors state on the source chain.

• Message passing/Relaying: After an actor picks up an event, it needs to transmit information from the source chain to the destination chain.

• Consensus: In some models, consensus is required between the actors monitoring the source chain in order to relay that information to the destination chain.

• Signing: Actors need to cryptographically sign, either individually or as part of a threshold signature scheme, information sent to the destination chain.

There are roughly four types of bridges, each with its own benefits and drawbacks:

• Asset-specific: A bridge with the sole purpose of providing access to a specific asset from a foreign chain. These assets are often “wrapped” assets that are fully collateralized by the underlying, either in a custodial or non-custodial manner. Bitcoin is the most common asset that is bridged to other chains, with seven different bridges on Ethereum alone. These bridges are the most simple to implement and enjoy a liquidity flywheel but have limited functionality and need to be re-implemented on each destination chain. Examples include wBTC and wrapped Arweave.

• Chain-specific: A bridge between two blockchains which usually supports simple operations around locking & unlocking tokens on the source chain and minting any wrapped asset on the destination chain. These bridges usually enjoy a faster time-to-market because of their limited complexity but are also not as easily scalable to the broader ecosystem. One example is Polygon’s PoS bridge, which allows users to transfer assets from Ethereum to Polygon and vice versa, but is limited to those two chains.

• Application-specific: An application that provides access to two or more blockchains, but solely for use within that application. The application itself benefits from a smaller codebase; instead of having separate instances of the entire application on each blockchain, it usually has lighter, modular “adapters” on each of those blockchains. A blockchain that implements an adapter gets access to all other ones it is connected to, so a network effect exists. The downside is that it is hard to extend that functionality to other applications (e.g. from lending to exchange). Examples include Compound Chain and Thorchain, which are building separate blockchains specifically for cross-chain lending and exchange, respectively.

• Generalized: a protocol specifically designed for transferring information across multiple blockchains. This design enjoys strong network effects because of O(1) complexity — a single integration for a project gives it access to the entire ecosystem within the bridge. The drawback is that some designs usually trade off security and decentralization to get this scaling effect, which could have complex unintended consequences for the ecosystem. One example is IBC, which is used to send messages between two heterogeneous chains (that have finality guarantees).

As of September 14, 2021

Furthermore, there are roughly three types of bridge designs, which can be categorized based on the mechanism that is used to validate the cross-chain transactions:

External validators & Federations

There is usually a group of validators that monitor a “mailbox” address on the source chain and, upon consensus, perform an action on the destination chain. An asset transfer is typically done by locking up the asset in the mailbox and minting the equivalent amount of that asset on the destination chain. These are often bonded validators with a separate token as a security model.

A high-level illustration of an external validator or federated system

Light clients & Relays

Actors monitor events on the source chain and generate cryptographic inclusion proofs about past events that were recorded on that chain. These proofs are then forwarded, along with the block headers, to contracts (i.e. the “light client”) on the destination chain, which then verifies that a certain event was recorded and executes an action after that verification. There is a requirement for some actor to “relay” the block headers and proofs. While it is possible for a user to “self-relay” transactions, there does exist a liveness assumption that relayers will continuously forward data. This is a relatively safe bridge design because it guarantees trustless valid delivery without placing trust in intermediary entities, but it is also resource-intensive because developers must build a new smart contract on each new destination chain that parses state proofs from the source chain, and the validation itself is gas-intensive.

A high-level illustration of a light client and/or relay system

Liquidity networks

This is akin to a peer-to-peer network where each node acts as a “router” that holds an “inventory” of assets of both the source and destination chain. These networks usually leverage the security of the underlying blockchain; through the use of locking and dispute mechanisms, users are guaranteed that routers cannot run away with user funds. Because of this, liquidity networks like Connext are likely a safer option for users who are transferring large amounts of value. Furthermore, this type of bridge is likely best suited for cross-chain asset transfer because the assets provided by routers are native to the destination chain rather than derivative assets, which are not fully fungible with each other.

A high-level illustration of a liquidity network

One could view the current bridge landscape from this perspective as well:

As of September 14, 2021

It is important to note that any given bridge is a two-way communication channel that may have separate models in each channel and that this categorization doesn’t accurately represent hybrid models like Gravity, Interlay, and tBTC since they all have light clients in one direction and validators in another.

In addition, one could roughly evaluate a bridge design according to the following factors:

• Security: Trust & liveness assumptions, tolerance for malicious actors, the safety of user funds, and reflexivity.

• Speed: Latency to complete a transaction, as well as finality guarantees. There is often a tradeoff between speed and security.

• Connectivity: Selections of destination chains for both users and developers, as well as different levels of difficulty for integrating an additional destination chain.

• Capital efficiency: Economics around capital required to secure the system and transaction costs to transfer assets.

• Statefulness: Ability to transfer specific assets, more complex state, and /or execute cross-chain contract calls.

Taken together, one could view the trade-offs of these three designs from the following perspective:

Furthermore, security is on a spectrum and one could roughly categorize it as:

• Trust-less: The bridge’s security is equal to that of the underlying blockchain(s) it is bridging. Outside of consensus-level attacks on the underlying blockchain, user funds cannot be lost or stolen. That said, nothing is actually trust-less because all of these systems have trust assumptions across their economic, engineering, and cryptographic components (e.g. no code bugs).

• Insured: Malicious actors are able to steal user funds, but it is likely unprofitable for them to do so because they are required to post collateral and get slashed in the case of error or misbehavior. If user funds are lost, they will be reimbursed through slashed collateral.

• Bonded: Similar to the insured model (i.e. actors have economic skin-in-the-game), except that users do not recover funds in case of error or misbehavior because the slashed collateral is likely burned. The collateral type matters for both the bonded and insured models; endogenous collateral (i.e. the collateral is the protocol token itself) is riskier because the token value will likely crash if the bridge is failing, which further reduces the security guarantees of the bridge.

• Trusted: Actors do not post collateral and users do not recover funds in case of system failure or malicious activity, so users are mainly relying on the reputation of the bridge operator.

As of September 14, 2021. Several projects will move out of the “Trusted” category in future upgrades.

Summarizing the design tradeoffs

External validators & federations generally excel with statefulness and connectivity because they could trigger transactions, store data, and allow interactions with that data on an arbitrary number of destination chains. This comes at the cost of security, however, since users are, by definition, relying on the security of the bridge rather than the source or destination chains. While most external validators today are trusted models, some are collateralized, of which a subset is used to insure end-users. Unfortunately, their insurance mechanisms are often reflexive; if a protocol token is used as collateral, there is an assumption that the dollar value of that token will be high enough to make users whole. Furthermore, if the collateral asset is different from the insured asset, there is also a dependency on an oracle price feed, so the security of the bridge could degrade to the security of the oracle. If not trusted, these bridges are also the least capital efficient because they need to scale collateral proportional with the economic throughput they are facilitating.

Light clients & relays are also strong with statefulness because header relay systems could pass around any kind of data. They are also strong with security because they do not require additional trust assumptions, although there is a liveness assumption because a relayer is still required to transmit the information. These are also the most capital-efficient bridges because they do not require any capital lockup whatsoever. These strengths come at the cost of connectivity. For each chain pair, developers must deploy a new light client smart contract on both the source and destination chain, which is somewhere between O(LogN) and O(N) complexity (it is between this range because adding support with chains with the same consensus algorithm is relatively easy). There are also significant speed drawbacks in optimistic models that rely on fraud proofs, which could increase latency up to 4 hours.

Liquidity networks shine with speed and security because they are locally verified systems (i.e. do not require global consensus). They are also more capital efficient than bonded/insured external validators because capital efficiency is tied to transaction flow/volume rather than security. For example, given somewhat equal flows between two chains and a built-in rebalancing mechanism, liquidity networks could facilitate an arbitrarily large amount of economic throughput. The trade-off is with statefulness because while they can pass around calldata, they are limited in functionality. For example, they could interact with data across chains where the receiver has the permission to do the interaction based on the data provided (e.g. call a contract with a signed message from the sender) but does not help with passing around data that does not have an “owner” or is part of generalized state (e.g. minting representation tokens).

Open issues

Building robust cross-chain bridges is an incredibly difficult problem in distributed systems. While there is a lot of activity in the space, there are still several unanswered questions:

• Finality & rollbacks: How do bridges account for block reorgs and time bandit attacks in chains with probabilistic finality? For example, what happens to a user who sent funds from Polkadot to Ethereum if either chain experiences a state rollback?

• NFT transfers & provenance: How do bridges preserve provenance for NFTs that are bridged across multiple chains? For example, if there is an NFT that is bought & sold across marketplaces on Ethereum, Flow, and Solana, how does the record of ownership account for all of those transactions and owners?

• Stress testing: How will the various bridge designs perform under times of chain congestion or protocol- & network-level attacks?

The future of blockchain bridges

While bridges unlock innovation for the blockchain ecosystem, they also pose serious risks if teams cut corners with research & development. The Poly Network hack has demonstrated the potential economic magnitude of vulnerabilities & attacks, and I expect this to get worse before it gets better. While it is a highly fragmented and competitive landscape for bridge builders, teams should remain disciplined in prioritizing security over time-to-market.

While an ideal state would have been one homogeneous bridge for everything, it is likely that there is no single “best” bridge design and that different types of bridges will be best fit for specific applications (e.g. asset transfer, contract calls, minting tokens).

Furthermore, the best bridges will be the most secure, interconnected, fast, capital-efficient, cost-effective, and censorship-resistant. These are the properties that need to be maximized if we want to realize the vision of an “internet of blockchains”.

It is still early days and the optimal designs have likely not yet been discovered. There are several interesting directions for research & development across all bridge types:

• Decreasing costs of header verification: Block header verification for light clients is expensive and finding ways to decrease those costs could bring us closer to fully generalized and trustless interoperability. One interesting design could be to bridge to an L2 to decrease those costs. For example, implementing a Tendermint light client on zkSync.

• Moving from trusted to bonded models: While bonded validators are much less capital efficient, “social contracts” are a dangerous mechanism to secure billions of dollars of user funds. Additionally, fancy threshold signature schemes don’t meaningfully reduce trust in these systems; just because it’s a group of signers doesn’t remove the fact that it is still a trusted third party. Without collateralization, users are effectively handing over their assets to external custodians.

• Moving from bonded to insured models: Losing money is bad UX. While bonded validators & relayers disincentivize malicious behavior, protocols should take it one step further and reimburse users directly using slashed funds.

• Scaling liquidity for liquidity networks: These are arguably the fastest bridges for asset transfer, and there are interesting design trade-offs between trust and liquidity. For example, it is possible to enable liquidity networks to outsource capital provisioning with a bonded validator style model where the router can also be a threshold multisig with bonded liquidity.

• Bridge aggregation: While bridge usage will likely follow a power law for specific assets and corridors, aggregators like Li Finance could improve UX for both developers and end-users.