Blockchain Bridges
We have now reached a multi-chain market structure after years of research and development. Over 100 public blockchains are currently in use, and many of them have special uses, users, geographic distributions, security methods, and architectural trade-offs. Contrary to what some communities may think, the cosmos actually has an entropy tendency, and as a result, there will probably be more of these networks in the future. This kind of market structure makes interoperability between these many networks necessary. As a result of this realization by many developers, the number of blockchain bridges that aim to integrate the more dispersed environment has exploded in the past year. There are more than 40 separate bridge projects underway as of this writing.
Interoperability unlocks innovation
As individual ecosystems grow, they design their own original strengths, for example, better security, faster throughput, less expensive transactions, greater privacy, particular resource provisioning (e . g . storage, compute, bandwidth), and territorial developer & user communities. Bridges are essential because they allow users to permission for new platforms, protocols to interoperate with one another, and developers to collaborate on creating new products. More specifically, they allow :
Unlocking new features and use cases for users and developers
- Bridges give users and developers more choices. 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
Greater productivity and utility for existing cryptoassets
Bridges enable existing crypto assets to travel to new places and do new things. For example:
- Sending DAI to Terra to buy a synthetic asset on Mirror or earn a 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
Bridges
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 the 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, the 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.
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.
Issues with Bridges
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.
From the article of Dmitriy Berenzon