Thanks for signing up.
We'll see you soon 👋
We'll see you soon 👋
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:
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:
Bridges enable existing cryptoassets to travel to new places and do new things. For example:
Bridges expand the design space for what protocols could achieve. For example:
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:
There are roughly four types of bridges, each with its own benefits and drawbacks:
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:
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
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
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:
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:
As of September 14, 2021. Several projects will move out of the “Trusted” category in future upgrades.
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).
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:
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:
If you are building a cross-chain bridge, please reach out!
Many thanks to Aidan Musnitzsky, Arjun Bhuptani, James Prestwich, and Pranay Mohan for their feedback on this piece.
You could follow me on Twitter here
Originally published on medium.com
Engineers who find a new job through Blockchain Works average a 15% increase in salary.Start with GitHubStart with TwitterStart with Stack OverflowStart with Email