After years of research and development, we finally entered a multi-chain market structure. There are more than 100 active public blockchains, many of which have their own unique applications, users, geography, security models, and design trade-offs. Although individual communities believe, the reality is that the universe tends to increase in entropy, and the number of these networks may continue to increase in the future.
This type of market structure requires interoperability between these different networks. Many developers have realized this, and we witnessed the explosive growth of blockchain bridges in the last year, which are trying to unify the increasingly decentralized blockchain. At the time of writing, there are more than 40 different chain bridge projects .
As of September 8, 2021; illustrative/incomplete
In this article, I will:
- Explain why chain bridges are important
- Overview of various chain bridge designs and their advantages and disadvantages
- Provide an overview of the current chain bridge ecology
- Describe what the future of Chain Bridge might look like
Interoperability opens up innovation
As each ecosystem develops, they will develop their own unique advantages, such as higher security, faster throughput, cheaper transactions, better privacy, and specific resource supply (such as storage, computing, bandwidth ) And regional developer and user communities. Chain bridges are important because they enable users to access new platforms, protocol interoperability, and developers to collaborate to build new products. More specifically, they can:
Improve the productivity and utility of existing crypto assets
Chain bridges enable existing crypto assets to travel to new places and do new things. E.g:
Send DAI to Terra to buy synthetic assets on Mirror or earn revenue on Anchor
Flow from the Ethernet Square transmitting TopShot to serve as collateral NFTfi
Use DOT and ATOM as collateral to obtain DAI loans on Maker
More powerful product features applicable to existing protocols
Bridging expands the design space that the protocol can implement. E.g:
Desire for high-yield agriculture on Solana and Avalanche
Cross-chain shared order book of NFT on Ethereum and Flow of Rarible protocol
Index Coop’s proof of equity index
Unlock new features and use cases for users and developers
Chain Bridge provides more choices for users and developers. E.g:
Optimism, Arbitrum and Polygon arbitrage SUSHI price across DEX
Use Bitcoin to pay for storage on Arweave
Join PartyBid for NFT on Tezos
Chain Bridge 101
At an abstract level, one can define a bridge as a system that transmits information between two or more blockchains. In this case, “information” can refer to assets, contract calls, proofs, or status. Most chain bridge designs have several components:
Monitoring: There is usually a participant, “oracle”, “validator” or “relayer”, who is responsible for monitoring the status of the source chain.
Message delivery/relay: After the actor receives the event, it needs to transfer the information from the source chain to the target chain.
Consensus: In some models, consensus needs to be reached between participants monitoring the source chain in order to relay this information to the target chain.
Signature: Participants need to cryptographically sign the information sent to the target chain either alone or as part of a threshold signature scheme.
There are about four types of chain bridges, each with its own advantages and disadvantages:
Specific assets : A chain bridge whose sole purpose is to provide access to specific assets from external chains. These assets are usually “packaged” assets, which are fully mortgaged by the underlying assets in custody or non-custody. Bitcoin is the most common asset bridged to other chains, and there are seven different bridges on Ethereum alone. These chain bridges are the easiest to implement and enjoy mobility flywheels, but their functions are limited and need to be re-implemented on each destination chain. Examples include wBTC and packaged Arweave.
Specific chain : A chain bridge between two blockchains, usually supporting simple operations around locking and unlocking tokens on the source chain and minting any packaged assets on the target chain. Due to the limited complexity of these chain bridges, they can usually be marketed faster, but they are not easy to expand to a wider ecosystem. An example is Polygon’s PoS bridge, which allows users to transfer assets from Ethereum to Polygon and vice versa, but only on these two chains.
Specific application : An application that provides access to two or more blockchains, but only for use in that application. The application itself benefits from a smaller code base; instead of having a separate instance of the entire application on each blockchain, it usually has a lighter, modular “adapter” on each blockchain. The blockchain that implements the adapter can access all other blockchains it is connected to, so there is a network effect. The disadvantage is that it is difficult to extend this function to other applications (for example, from lending to exchange). Examples include Compound Chain and Thorchain, which build independent blockchains dedicated to cross-chain lending and transactions.
Universal : A protocol designed to transmit information across multiple blockchains. Due to O(1) complexity, this design enjoys a strong network effect-a single integration of the project allows access to the entire ecosystem within the bridge. The disadvantage is that some designs usually weigh security and decentralization to obtain this expansion effect, which may have complex and unexpected consequences for the ecosystem. An example is IBC, which is used to send messages between two heterogeneous chains (with guarantees of finality).
In addition, bridging design is roughly divided into three types, which can be classified according to the mechanism used to verify cross-chain transactions:
External validators and alliances
There is usually a set of validators that monitor the “mailbox” addresses on the source chain and perform operations on the target chain based on consensus. Asset transfer is usually done by locking the assets in the mailbox and casting the same amount of assets on the target chain. These are usually binding validators, using a separate token as a security model.
High-level instructions for external validators or federated systems
Light client and relay
Participants monitor events on the source chain and generate cryptographic proof of inclusion about past events recorded on that chain. Then forward these proofs together with the block header to the contract on the target chain (ie, “light client”), and then verify whether an event is recorded and perform operations after the verification. Some participants need to “relay” block headers and proofs. Although users can “self-relay” transactions, there is indeed an active assumption that the repeater will continue to forward data. This is a relatively secure bridge design, because it guarantees effective delivery without trust, without trusting intermediary entities,
High-level illustration of light client and/or relay system
This is similar to a peer-to-peer network, where each node acts as a “router”, holding a “list” of assets in the source chain and target chain. These networks usually take advantage of the security of the underlying blockchain; through the use of locking and dispute mechanisms, it is ensured that users will not be taken away by routers. Therefore, for users who transfer large amounts of value, a liquid network like Connext may be a safer choice. In addition, this type of bridge may be most suitable for cross-chain asset transfer, because the assets provided by the router are the original assets of the target chain, not derivative assets, and they cannot be completely interchanged.
High-level description of the liquidity network
You can also look at the current chain bridge ecology from this perspective:
As of September 8, 2021
It is important to note that any given bridge is a two-way communication channel, each channel may have a separate model, and this classification cannot accurately represent mixed models, such as Gravity, Interlay, and tBTC, because they all have Light client direction and authenticator are on the other.
In addition, the chain bridge design can be roughly evaluated based on the following factors:
Security: Trust and liveness assumptions, tolerance for malicious actors, security and reflexivity of user funds.
Speed: The delay in completing the transaction, and the guarantee of finality. There is usually a trade-off between speed and safety.
Connectivity: Choose target chains for users and developers, and different difficulty levels for integrating additional target chains.
Capital efficiency: The economics surrounding the capital required to ensure the security of the system and the transaction costs of transferring assets.
Statefulness: 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 from the following perspectives:
In addition, security is within a range, which can be roughly classified as:
Trustless : The security of the bridge is equal to the security of the underlying blockchain it bridges. Except for consensus-level attacks on the underlying blockchain, user funds will not be lost or stolen. In other words, there is actually nothing to distrust, because all these systems have security and liveness assumptions in their economic, engineering, and encryption components.
Insuring : Malicious actors can steal user funds, but they may be unprofitable in doing so because they need to provide collateral and be cut in the event of error or misconduct. If users lose their funds, they will compensate by reducing their collateral.
Bonded : Similar to the insurance model (that is, the actor has a financial interest in the game), except that the user cannot recover the funds in the event of a mistake or improper behavior, because the reduced collateral may be burned. The type of collateral is important for both bonded and insurance models; endogenous collateral (that is, the collateral is the protocol token itself) is more risky, because if the bridge fails, the value of the token may collapse, which further reduces the bridge Security guarantee.
Can the letter : the participants not to release collateral, users will not recover the funds in case of system failure or malicious activity, so the user depends on the Chain Bridge operator’s reputation.
As of September 8, 2021. In future upgrades, several items will be moved out of the “trusted” category.
Summary of design trade-offs
External validators and alliances generally excel in statefulness and connectivity because they can trigger transactions, store data, and allow interaction with that data on any number of target chains. However, this comes at the cost of security, because by definition, users rely on the security of the bridge, not the source or target chain. Although most external validators today are trusted models, some are collateralized, and a subset of them is used to provide insurance to end users. Unfortunately, their insurance mechanisms are usually reflexive. If the protocol token is used as collateral, it is assumed that the dollar value of the token is sufficient to make the user complete. In addition, if the mortgaged asset is different from the insured asset, it also depends on the oracle price feed, so the security of the bridge may be downgraded to that of the oracle. If untrusted, the capital efficiency of these chain bridges is also the lowest, because they need to expand the collateral in proportion to the economic throughput they promote.
Light clients and relays are also very powerful in terms of statefulness, because the head relay system can transmit any type of data. They are also very strong in terms of security because they do not require additional trust assumptions, despite the existence of liveness assumptions, because repeaters are still needed to transmit information. These are also the most capital efficient chain bridges because they do not require any capital locking. These advantages come at the cost of connectivity. For each chain pair, the developer must deploy a new light client smart contract on the source chain and the target chain, the complexity of which is between O(LogN) and O(N) (between this range, Because it is relatively easy to add support for having the same chain) consensus algorithm). This can delay the confirmation of transactions by up to 4 hours.
Liquidity networks are known for speed and security because they are locally verified systems (that is, global consensus is not required). They are also more capital efficient than bonded/insurance external validators, because capital efficiency is related to transaction flow/volume rather than security. For example, assuming that the traffic between the two chains is somewhat equal, and there is a built-in rebalancing mechanism, the liquidity network can promote arbitrarily large amounts of economic throughput. The trade-offs are stateful, because although they can pass calldata, their functionality is limited. For example, they can interact with data across chains, where the receiver has the right to interact based on the provided data (for example
In a distributed system, building a robust cross-chain bridge is a very difficult problem. Although there are many activities in this area, there are still several unresolved issues:
Finality and rollback : How does the bridge explain the block reorganization and time bandit attacks in the chain with probabilistic finality? For example, if any chain encounters a state rollback, what will happen to users who send funds from Polkadot to Ethereum?
NFT transmission and provenance : How does the bridge reserve provenance for NFTs bridged across multiple chains? For example, if an NFT is bought and sold on the Ethereum, Flow, and Solana markets, how does the ownership record account for all these transactions and owners?
Stress testing : In the case of chain congestion or protocol and network-level attacks, how will various bridge designs be performed?
The future of blockchain bridges
Although chain bridges have opened up innovation for the blockchain ecosystem, if the team takes shortcuts in research and development, they will also bring serious risks. The hacking of the poly network has demonstrated the potential economic scale of vulnerabilities and attacks, and I expect this to get worse before it gets better. Although this is a highly fragmented and highly competitive landscape for chain bridge builders, the team should maintain discipline and prioritize the safety of time to market.
Although the ideal state should be a homogeneous chain bridge for all things, there is probably no single “best” chain bridge design, and different types of chain bridges are most suitable for specific applications (such as asset transfer, contract invocation, token coining).
In addition, the best chain bridge will be the most secure, interconnected, fast, capital efficient, cost-effective and anti-censorship chain bridge. If we want to realize the vision of “blockchain internet”, these are the attributes that need to be maximized.
It is still too early, and the best design may not have been discovered yet. There are several interesting research and development directions for all chain bridge types:
Reducing the cost of header verification : The cost of block header verification for light clients is high, and finding ways to reduce these costs can bring us closer to fully universal and trustless interoperability. An interesting design might be to bridge to L2 to reduce these costs. For example, implement the Tendermint light client on zkSync.
Shift from a trusted model to a binding model : Although the capital efficiency of binding validators is much lower, the “social contract” is a dangerous mechanism that can ensure the safety of billions of dollars in user funds. In addition, fancy threshold signature schemes will not significantly reduce trust in these systems; just because it is a group of singers does not eliminate the fact that it is still a trusted third party. Without collateral, users actually hand over their assets to an external custodian.
Change from a bonded model to an insurance model : Losing money is a bad user experience. Although the bound validators and repeaters can suppress malicious behavior, the protocol should go one step further and directly use the reduced funds to compensate users.
Extend the liquidity of the liquidity network : These are arguably the fastest chain bridges for asset transfer, and there are interesting design trade-offs between trust and liquidity. For example, it is possible to enable a liquidity network to use a bound validator style model to outsource capital supply, where the router can also be a threshold multi-signature with bound liquidity.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/blockchain-chain-bridge-ecology-building-a-network-of-encrypted-networks/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.