Understand the design types, ecology and future development direction of chain Bridges

Original title:Collection! Learn about cross - chainBridge design type and project distribution"

Ye Zewei, The Way of DeFi

After years of research and development, we are finally entering a multi-chain market. There are over 100 active on the market right nowThe male chain, many of which have their own unique apps, users, geographic distribution,securityModel and design tradeoffs. Despite individual communities' reluctance to believe it, the universe is entropy increasing and the number of these networks is likely to continue to increase in the future.

This type of market structure requires interoperability between different networks. Many developers have realized this, and blockchain cross-chain Bridges have seen explosive growth in the past year. At the time of writing, there are currently over 40 different cross-chain bridge projects.

As of September 8, 2021; Not all items are included

This paper will focus on four aspects:

· Explain why cross-chain Bridges are so important

· An overview of the different chain bridge designs and their advantages and disadvantages

· Overview of the current cross-chain bridge ecology

· Looking into the future development direction of cross-chain Bridges

1 Interoperability unleashes innovation

As each ecosystem grows, it develops its own unique advantages, such as higher security, faster throughput, cheaper transactions, better privacy, provision of specific resources (such as storage, computing, bandwidth), and regional developer and user communities. Cross-chain Bridges are important because they give users access to new platforms and protocols for interaction, enabling developers to collaborate on building new products. More specifically, they can:

Improve the productivity and availability of existing crypto assets

Cross-chain Bridges allow existing crypto assets to go to new places and do new things. Such as:

·将 DAI 发送到 Terra，从而 在 Mirror 上购买合成资产或在 Anchor 上赚取收益 ；

, fromFlowSend TopShot to Ethereum for use asNFTfiCollateral;

· Get DAI loans on Maker using DOT and ATOM as collateral

Make existing protocols more powerful products

Cross-chain Bridges expand the design space that protocols can implement. Such as:

In,SolanaandAvalancheonYFIFlow mining; Cross-chain shared order book for Flow over NFT and Rarible protocols on Ethereum

· Launch Index CoopPoSindex

Unlock new features and use cases for users and developers

Cross-chain Bridges provide more options for users and developers. Such as:

In,OptimismArbitrum and Polygon crossDEXCarry trade (e.g., Sushi)

· Use Bitcoin to pay for storage on ARweave

In,TezosJoin PartyBid's NFT crowdfunding groupon

2 Cross chain bridge popular science

At an abstract level, one can define a cross-chain bridge as a system that transfers information between two or more blockchains. In this case, "information" can refer to an asset, a contract call, a certificate, or a state. Most chain-bridge designs have several components:

· Monitoring: There is usually an Actor, "predictor", "validator" or "repeater" that monitors the state on the chain.

· Messaging/relay: After receiving the event, the Actor 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: Actor needs to cryptographically sign the information sent to the target chain individually or as part of a threshold signature scheme.

Overall, there are about 4 types of chain Bridges:

Asset-specific = asset-specific:Its sole purpose is to provide access to a particular asset from an external chain. These are usually "Wrapped" assets, fully pledged by the underlying assets in custody or uncustody. Bitcoin is the most common asset that Bridges to other chains (XBTCS of all kinds), with seven different Bridges on Ethereum alone. These cross-chain Bridges are the easiest to implement and have good mobility, but have limited functionality and need to be re-implemented on each destination chain.

Chain-specific (specific to a particular Chain):The main operation of a cross-chain bridge between two blockchains is to lock and unlock tokens on the source chain and cast encapsulated assets on the target chain. Because of their limited complexity, these cross-chain Bridges can often be brought to market more quickly, but they are also not easily scaled up 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 only on those two chains.

Application-specific:An application that provides access between two or more blockchains, but only for use within that application. The application itself benefits from a smaller code base; It doesn't have a full application on every blockchain, but instead typically has lighter, modular "adapters" on each blockchain. A blockchain with an adapter deployed can access all other blockchains to which the application is connected, so there are network effects. The downside, however, is that it is difficult to extend this functionality to other applications (from lending to trading, for example). Specific examples includeCompoundChain and Thorchain, which have built separate blockchains dedicated to cross-chain lending and trading, respectively.

A Generalized (general):A protocol designed to transfer information across multiple blockchains. Due to the O(1) complexity (the time spent is fixed regardless of the amount of data in the data set), this design enjoys strong network effects and a single integration of a project gives it access to the entire ecosystem within the bridge. The downside is that some designs often trade off security and decentralization to achieve this scaling effect, which can have complex unintended consequences for the ecosystem. One example is IBC, which is used to send messages between two heterogeneous chains with final validation guarantees.

In addition, cross-chain bridge designs can be classified according to the mechanisms used to verify cross-chain transactions, which can be broadly classified into three types:

External validators and federation

Typically, a set of validators monitors the "mailbox" addresses on the source chain and performs actions on the target chain based on consensus. Asset transfer is usually accomplished by locking assets on the source chain and casting an equal number of assets on the target chain. These are usually bonded validators that use a separate token as a security model.

External validators or federated systems

Light client and relay

Actors monitor events on the source chain and generate encrypted proofs of past events recorded on that chain. These proofs are forwarded along with the block header to a contract on the target chain (that is, the "light client"), which then verifies that an event has been recorded and performs an action after verification. Some actors require "relay" block headers and proofs. Users can "self-relay" transactions, however, there does exist a survival assumption that the repeater will continuously forward data. This is a relatively safe cross-chain bridge design because it ensures efficient delivery without trust without trusting the intermediary entity, but it is also resource-intensive because the developer must build a new one on top of each new target chainIntelligent contractParse the state proof from the source chain, and the validation itself will consume a lot of gas.

Light client and relay system

Flow network

A liquid network is similar to a point-to-point network, in which each node acts as a "router" holding an "inventory" of assets in both the source and target chains. These networks typically take advantage of the security of the underlying blockchain; By using lock and dispute mechanisms, ensure that the router does not take money away from users. Therefore, a mobile network like Connext may be a safer option for users who transfer a lot of value. In addition, this type of cross-chain bridge may be best suited for cross-chain asset transfer, as the assets provided by the router are native to the target chain rather than derivative assets.

Flow network

The following figure is a classification and listing of various projects:

Note that any given cross-chain bridge is a two-way communication channel, there may be separate models in each channel, and that this classification does not accurately represent mixed models such as Gravity, Interlay, and tBTC, because one direction is the light client direction and the other direction is the validator.

We can make a rough evaluation of the cross-chain bridge design based on the following factors:

· Security: trust and active vacation facilities, tolerance to malicious actors, security of user funds, and reflexivity.

· Speed: Delays in closing transactions and guarantees of finality. There is often a trade-off between speed and safety.

· Connectivity: for users anddevelopersSelect target chains and integrate additional target chains at different difficulty levels.

· Capital efficiency: the capital required to ensure system security and transaction costs of transferring assets.

· Stateful: Ability to move specific assets, more complex states, and/or perform cross-chain contract calls.

Taken together, these three design trade-offs can be viewed from the following perspectives:

In addition, security falls within a range that can be roughly classified as:

Trustless:A cross-chain bridge is as secure as the underlying blockchain it Bridges. Aside from attacks on the underlying blockchain consensus layer, user funds are not lost or stolen. That is, virtually nothing is untrusting, as all of these systems have security and survivability assumptions in their economic, engineering, and cryptography components.

Insured.:Malicious actors can steal user funds, but they may not be profitable to do so because they are required to post collateral and be fined in the event of error or misconduct. If users lose their money, they will compensate by forfeiting part of their collateral.

Bonded:Similar to the insurance model, but the user will not recover the money in the event of error or misconduct, as the penalty collateral may be destroyed. The type of collateral is important for both ballies and insurance models; Endogenous collateral (that is, the collateral is the token itself) is riskier because if the bridge fails, the token value may collapse, further reducing the security guarantee of the bridge.

Trusted:Actors don't post collateral and users don't get their money back in the event of a system failure or malicious activity, so users rely primarily on the reputation of the bridge operator.

Summarize the design trade-offs

External validators and federations typically excel at state 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 expense of security, because the user relies on the security of the cross-chain bridge, not the source or destination chain. While most external validators today are trusted models, some are secured, and a subset of them are used to provide insurance for end users. Unfortunately, their insurance mechanisms are often reflexive. If a protocol token is used as collateral, assume that the dollar value of the token is sufficient to protect the user. In addition, if the mortgaged asset is different from the insured asset, it is dependent on the price flow of the predictor, so the safety of the cross-chain bridge may be downgraded to that of the predictor. If untrusted, these cross-chain Bridges are also the least capital efficient, since they require collateral to expand proportionately according to economic throughput.

Light clients and relays are also powerful in terms of stateful, because blockhead relaying systems can pass any type of data. They are also highly secure because they do not require an additional assumption of trust, although there is a survival assumption (since Repeaters are still needed to transmit information). These are also the most capital-efficient cross-chain Bridges, as they do not require any capital lock-in. These advantages come at the cost of connectivity. For every two chains, the developer must deploy a new light client smart contract between O(LogN) and O(N) on the source and target chains. Optimistic models that rely on proof of fraud also have a significant speed deficit, which can add up to four hours of delay.

Mobile networks perform well in terms of speed and security because they are local validation systems (i.e., no global consensus is required). They are also more capital efficient than Bonded/Insured external validators as capital efficiency is related to transaction flow/volume rather than security. For example, given that traffic flows between two chains are roughly equal and there is a built-in rebalancing mechanism, a liquidity network can facilitate arbitrarily large economic throughput. The tradeoff with this pattern is stateful, because while they can pass call data, their capabilities are limited. For example, a mobile network can interact with data across the chain, where the receiver has the right to interact based on the data provided (for example, invoking a contract with a signed message from the sender), but it cannot help deliver data that has no "owner" or is just part of the general state.

3 What other problems do cross-chain Bridges need to solve?

Building robust cross-chain Bridges is a very difficult problem in distributed systems. While there are many developments in the field, several unanswered questions remain:

Finality and rollback: How do cross-chain Bridges consider block recombination and time robber attacks in probabilistic finality chains? For example, what if a user sends money to Ethereum from Boca and one of the chains rolls back?

NFT transfer and provenance: How do cross-chain Bridges preserve provenance for NFT that Bridges across multiple chains? For example, if there is an NFT buying and selling on the markets of Ethereum, Flow, and Solana, how does the ownership record take into account all those transactions and owners?

Stress test: How will various cross-chain bridge designs perform under chain congestion or protocol - and network-level attacks?

The future of blockchain bridge

While cross-chain Bridges unleash innovation into the blockchain ecosystem, they also pose serious risks if teams take shortcuts in research and development. The Poly Network hack has demonstrated just how risky it can be. While this is a highly fragmented and competitive landscape for cross-chain bridge builders, the team should remain disciplined and think about safety first before bringing the product to market.

While the ideal would be a homogeneous bridge that does everything, there is probably no "best" design, and different types of bridge are suitable for different purposes (e.g. asset transfer, contract invocation, token minting).

In addition, the best cross-chain Bridges will be the safest, interconnected, fast, capital efficient, cost effective and resistant to censorship. These are the attributes that need to be maximized if we want to realize our vision of a "blockchain Internet."

It's still early days for chain Bridges, and the best design may not yet be discovered. There are several interesting research and development directions:

Reduce the cost of header validation: Header validation for light clients is expensive, and finding ways to reduce these costs can bring us closer to fully universal and trust-free interoperability. An interesting design might be to bridge to L2 to reduce these costs. For example, implement the Tendermint light client on zkSync.

Switching from a Trusted model to a binding model: While binding validators are much less capital efficient, the "social contract" is a dangerous mechanism for ensuring the safety of billions of dollars of user funds. In addition, fancy threshold signature schemes do not significantly reduce trust in these systems; Although it is a group of people, there is no denying that it is still a trusted third party. In the absence of collateral, users are effectively handing over their assets to an external custodian.

Switching from Bonded mode to Insured mode: Loss of property is a really bad user experience. Although bound validators and Repeaters can suppress malicious behavior, the protocol should go a step further and directly compensate users with forfeited funds.

Liquidity in extended liquidity networks: These are arguably the fastest cross-chain Bridges for asset transfer, and there are interesting design trade-offs between trust and liquidity.

The original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia