Blockchain Bridge Ecosystem: Building a Network of Cryptographic Networks
Connext is an interoperability protocol that enables fast, non-custodial cross-chain transfers and contract calls between EVM-compatible blockchains.Author: Dmitriy Berenzon
Source: Wilderness Rebirth
After years of research and development, we have finally entered a multi-chain market structure. There are over 100 active public blockchains, many of which have their own unique applications, users, geographic locations, security models, and design trade-offs. While individual communities may believe otherwise, the reality is that the universe tends toward increasing entropy, and the number of these networks may continue to grow in the future.
This type of market structure requires interoperability between these different networks. Many developers have recognized this, and we witnessed explosive growth in blockchain bridges last year, which aim to unify the increasingly fragmented blockchains. As of this writing, there are over 40 different bridge projects.
As of September 8, 2021; illustrative/not comprehensive
In this article, I will:
Explain why bridges are important
Outline various bridge designs and their pros and cons
Provide an overview of the current bridge ecosystem
Describe what the future of bridges might look like
Interoperability Unlocks Innovation
As various ecosystems develop, they will cultivate their own unique advantages, such as higher security, faster throughput, cheaper transactions, better privacy, specific resource supplies (e.g., storage, computation, bandwidth), and regional developer and user communities. Bridges are important because they enable users to access new platforms, allow protocols to interoperate, and facilitate developers to collaborate on building new products. More specifically, they can:
Enhance the productivity and utility of existing crypto assets
Bridges allow existing crypto assets to go to new places and do new things. For example:
Sending DAI to Terra to purchase synthetic assets on Mirror or earn yield on Anchor
Sending TopShot from Flow to Ethereum to use as collateral for NFTfi
Using DOT and ATOM as collateral to obtain DAI loans on Maker
More robust product features applicable to existing protocols, bridging expands the design space that protocols can achieve. For example:
Eager to engage in high-yield farming on Solana and Avalanche
Cross-chain shared order books for NFTs on Ethereum and the Flow of the Rarible protocol
Proof-of-stake index from Index Coop
Unlock New Features and Use Cases for Users and Developers
Bridges provide users and developers with more choices. For example:
Arbitraging SUSHI prices across DEXs on Optimism, Arbitrum, and Polygon
Paying for storage on Arweave using Bitcoin
Joining PartyBid for NFTs on Tezos
Bridges 101
At an abstract level, bridges can be defined as systems that transfer information between two or more blockchains. In this context, "information" can refer to assets, contract calls, proofs, or states. Most bridge designs have several components:
Monitoring: Typically, there is a participant, "oracle," "validator," or "relayer," responsible for monitoring the state on the source chain.
Messaging/Relaying: After an actor receives an event, it needs to transfer information from the source chain to the target chain.
Consensus: In certain models, consensus must be reached among participants monitoring the source chain to relay that information to the target chain.
Signing: Participants need to cryptographically sign the information sent to the target chain, either individually or as part of a threshold signing scheme.
There are roughly four types of bridges, each with its own advantages and disadvantages:
Asset-Specific: A bridge whose sole purpose is to provide access to specific assets from an external chain. These assets are often "wrapped" assets, fully collateralized by the underlying asset in a custodial or non-custodial manner. Bitcoin is the most common asset bridged to other chains, with seven different bridges on Ethereum alone. These bridges are the easiest to implement and enjoy liquidity flywheels, but their functionality is limited and requires re-implementation on each destination chain. Examples include wBTC and wrapped Arweave.
Chain-Specific: A bridge between two blockchains that typically supports simple operations around locking and unlocking tokens on the source chain and minting any wrapped assets on the target chain. Due to the limited complexity of these bridges, they can often be brought to market faster but are not easily scalable to broader ecosystems.
An example is Polygon's PoS bridge, which allows users to transfer assets from Ethereum to Polygon and vice versa, but only between these two chains.
Application-Specific: An application that provides access to two or more blockchains but is only for use within that application. The application itself benefits from a smaller codebase; there is not a separate instance of the entire application on each blockchain, but rather lighter, modular "adapters" on each blockchain.
Blockchains implementing adapters can access all other blockchains they are connected to, creating network effects. The downside is that it is difficult to extend that functionality to other applications (e.g., from lending to swapping). Examples include Compound Chain and Thorchain, which have built independent blockchains specifically for cross-chain lending and trading.
General-Purpose: A protocol designed for transmitting information across multiple blockchains. Due to O(1) complexity, this design enjoys strong network effects—the single integration of a project allows access to the entire ecosystem within the bridge.
The downside is that some designs often trade off security and decentralization for this scalability effect, which can have complex unintended consequences for the ecosystem. An example is IBC, which is used to send messages between two heterogeneous chains (with finality guarantees).
Additionally, bridge designs can be broadly categorized into three types based on the mechanisms used to validate cross-chain transactions:
External Validators and Consortiums
Typically, there is a set of validators monitoring a "mailbox" address on the source chain and executing operations on the target chain based on consensus. Asset transfers are usually completed by locking assets in the mailbox and minting an equivalent amount of assets on the target chain. These are often bonded validators, using a separate token as a security model.
High-level illustration of external validator or consortium systems
Light Clients and Relayers
Participants monitor events on the source chain and generate cryptographic proofs of past events recorded on that chain. These proofs are then forwarded along with block headers to a contract on the target chain (i.e., "light client"), which verifies whether a certain event was recorded and executes actions after that verification. Certain participants need to "relay" block headers and proofs.
While users can "self-relay" transactions, there is indeed an active assumption that relayers will continue to forward data. This is a relatively secure bridge design because it guarantees effective delivery without trusting intermediary entities.
High-level illustration of light client and/or relayer systems
Liquidity Networks
This is similar to a peer-to-peer network, where each node acts as a "router," holding a "ledger" of assets from both the source and target chains. These networks typically leverage the security of the underlying blockchain; by using locking and dispute mechanisms, they ensure that users are not robbed of their funds by routers.
Thus, for users transferring large amounts of value, liquidity networks like Connext may be a safer choice. Additionally, this type of bridge may be best suited for cross-chain asset transfers, as the assets provided by routers are native assets of the target chain rather than derivative assets, which cannot be fully interchangeable.
High-level illustration of liquidity networks
The current bridge ecosystem can also be viewed from this perspective:
As of September 8, 2021
It is important to note that any given bridge is a bi-directional communication channel, and there may be separate models within each channel. This categorization cannot accurately represent hybrid models like Gravity, Interlay, and tBTC, as they all have light client directions and validators in another.
Furthermore, bridge designs can be roughly assessed based on the following factors:
Security: Trust and activity assumptions, tolerance for malicious actors, safety of user funds, and reflexivity.
Speed: Latency in completing transactions and finality guarantees. There is often a trade-off between speed and security.
Connectivity: Choices of target chains for users and developers, and varying levels of difficulty in integrating additional target chains.
Capital Efficiency: The economics surrounding the capital required to secure the system and the transaction costs of transferring assets.
Statefulness: The ability to transfer specific assets, more complex states, and/or execute cross-chain contract calls.
Taken together, the trade-offs of these three designs can be viewed as follows:
Additionally, security can be roughly categorized along a spectrum:
Trustless: The security of the bridge is equivalent to the security of the underlying blockchains it bridges. User funds will not be lost or stolen except in the case of consensus-level attacks on the underlying blockchains. In other words, there is really nothing that is trustless, as all these systems have security and liveness assumptions in their economics, engineering, and cryptographic components.
Insured: Malicious actors can steal user funds, but doing so may not be profitable, as they need to provide collateral and will be slashed in the event of errors or misconduct. If user funds are lost, they will be compensated through slashing of collateral.
Custodial: Similar to an insurance model (i.e., actors have economic incentives in the game), except that users cannot recover funds in the event of errors or misconduct because the slashed collateral may be burned. The type of collateral is important for both custodial and insurance models; endogenous collateral (i.e., collateral is the protocol token itself) carries more risk because if the bridge fails, the value of the token may collapse, further diminishing the security guarantees of the bridge.
Credible: Participants do not post collateral, and users will not recover funds in the event of system failure or malicious activity, so users primarily rely on the reputation of the bridge operator.
As of September 8, 2021. In future upgrades, several projects will move out of the "trusted" category.
Design Trade-offs Summary
External validators and consortiums typically excel in statefulness and connectivity because they can trigger transactions, store data, and allow interaction with that data across an arbitrary number of target chains. However, this comes at the cost of security, as users are, by definition, relying on the security of the bridge rather than the source or target chains.
While most external validators today are trusted models, some are collateralized, with a subset used to provide insurance for end users. Unfortunately, their insurance mechanisms are often reflexive. If the protocol token is used as collateral, it is assumed that the dollar value of that token is sufficient to make users whole.
Additionally, if the collateralized asset is different from the insured asset, it also relies on oracle price feeds, so the security of the bridge may degrade to the security of the oracle. If not trustless, these bridges also have the lowest capital efficiency, as they need to scale collateral in proportion to the economic throughput they facilitate.
Light clients and relayers are also strong in statefulness because header relaying systems can pass any type of data. They are also strong in security because they do not require additional trust assumptions, although there is an activity assumption since relayers are still needed to transmit information. These are also the most capital-efficient bridges because they do not require any capital lock-up. These advantages come at the cost of connectivity.
For each chain pair, developers must deploy a new light client smart contract on both the source and target chains, with complexity ranging between O(LogN) and O(N) (between this range because adding support for chains with the same consensus algorithm is relatively easy). This can lead to transaction confirmation delays of up to 4 hours.
Liquidity networks excel in speed and security because they are locally validated systems (i.e., global consensus is not required). They are also more capital efficient than custodial/insurance external validators because capital efficiency is related to transaction flow/volume rather than security.
For example, if the flow between two chains is somewhat equal and there is a built-in rebalancing mechanism, liquidity networks can facilitate any amount of economic throughput. The trade-off is statefulness, as while they can pass calldata, their functionality is limited. For instance, they can interact with data across chains where the receiver has the right to interact based on the provided data.
Open Questions
Building robust cross-chain bridges in distributed systems is a very challenging problem. While there is a lot of activity in the space, several questions remain unresolved:
Finality and Rollbacks: How do bridges interpret block reorganizations and time-bandit attacks in chains with probabilistic finality? For example, what happens to users sending funds from Polkadot to Ethereum if either chain experiences a state rollback?
NFT Transfer and Provenance: How do bridges retain provenance for NFTs bridged across multiple chains? For example, if an NFT is bought and sold on markets in Ethereum, Flow, and Solana, how do ownership records account for all these transactions and owners?
Stress Testing: How will various bridge designs perform under chain congestion or protocol and 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 in development. The recent network hacks have demonstrated the potential economic scale of vulnerabilities and attacks, and I expect this to get worse before it gets better. While this is a highly decentralized and competitive landscape for bridge builders, teams should remain disciplined and prioritize security over time to market.
While the ideal state would be homomorphic bridges for everything, it is likely that there will not be a single "best" bridge design, as different types of bridges are best suited for specific applications (e.g., asset transfers, contract calls, minting tokens).
Moreover, the best bridges will be the most secure, interconnected, fast, capital-efficient, cost-effective, and censorship-resistant. If we want to realize the vision of a "blockchain internet," these are the attributes that need to be maximized.
It is still early days, and the best designs may not yet be discovered. All types of bridges have several interesting research and development directions:
Reducing the Cost of Header Verification: The cost of block header verification for light clients is high, and finding ways to reduce these costs could bring us closer to fully general and trustless interoperability. An interesting design might be bridging to L2 to reduce these costs. For example, implementing a Tendermint light client on zkSync.
Transitioning from Trusted Models to Bonded Models: While bonded validators have much lower capital efficiency, the "social contract" is a dangerous mechanism to ensure the safety of billions of dollars of user funds.
Additionally, fancy threshold signing schemes do not significantly reduce trust in these systems; just because it is a group of signers does not eliminate the fact that it is still a trusted third party. Without collateral, users are essentially handing their assets over to an external custodian.
Transitioning from Custodial Models to Insurance Models: Losing money is a terrible user experience. While bonded validators and relayers can mitigate malicious behavior, protocols should go further and directly use slashed funds to compensate users.
Scaling the Liquidity of Liquidity Networks: These can arguably be the fastest bridges for asset transfers, and there are interesting design trade-offs between trust and liquidity. For example, it may be possible to enable liquidity networks to outsource capital supply using a bonded validator-style model, where routers could also be threshold multi-signatures with bonded liquidity.
If you are building cross-chain bridges, please get in touch!
Special thanks to Aidan Musnitzsky, Arjun Bhuptani, James Prestwich, and Pranay Mohan for their feedback on this article.
