This article introduces the current and future situation of blockchain bridging

Source | 1kxnetwork

Author | Dmitriy Berenzon

After years of research and development, we have finally formed a multi-chain market structure. There are currently over 100 active public blockchains, many of which have their own unique applications, users, geographical distribution, security models, and design tradeoffs. Regardless of what individual communities believe, the reality is that the universe tends to increase entropy, and the number of these networks will likely continue to increase in the future.

image description

In this article, I will:

In this article, I will:

• Explain why bridging is important

• An overview of various bridge designs and their advantages and disadvantages

• Overview of current bridging in general

• first level title

Interoperability unlocks innovative possibilities

secondary title

▲ Improve the productivity and utility of existing encrypted assets

Bridging allows existing crypto assets to be transferred to new platforms to do new things. like:

• Send DAI to Terra to buy synthetic assets on Mirror, or earn yield on Anchor

• Send TopShot from Flow to Ethereum as collateral for NFTfi

• secondary title

▲ Expand product functions of existing protocols

Bridging expands the design space that a protocol can implement. For example:

• Liquidity mining with Yearn vaults on Solana and Avalanche

• NFT cross-chain shared order book on Ethereum and Flow on Rarible Protocol

• secondary title

▲ Unlock new functional use cases for users and developers

Bridging gives users and developers more options. like:

• Arbitrage the price of SUSHI across DEXs on Optimism, Arbitrum and Polygon

• Pay for Arweave storage with Bitcoin

• first level title

Bridging 101

At an abstract level, a bridge can be defined as: a system for transferring information between two or more blockchains. And "information" can refer to assets, contract calls, proofs, or state. Most bridge designs consist of the following parts:

• monitor:Messaging/Relay:

• Messaging/Relay:consensus:

• consensus:sign:

• sign:Participants need to cryptographically sign the information sent to the target chain, either as a single signature or as part of a threshold signature scheme.

There are broadly four types of bridging schemes, each with its pros and cons:

• Asset-specific:The sole purpose of this bridge type is to provide access to external chain-specific assets. These assets are typically "wrapped" assets (assets that are fully collateralized by the underlying assets, either in custodial or non-custodial fashion). Bitcoin is the most common asset bridged to other chains, with seven different bridges on Ethereum alone. This kind of bridging is the easiest to implement and derives huge liquidity from it. But its functionality is limited and needs to be re-implemented on each target chain. Examples are wBTC and wrapped Arweave.

• Chain-specific:A bridge between two chains, typically supporting locking and unlocking tokens on the source chain and minting arbitrary encapsulated assets on the target chain. Due to the limited complexity of these bridges, they are often faster to market, but also not easily scalable into the wider ecosystem. Use cases are Polygon's PoS bridge, which allows users to transfer assets from Ethereum into Polygon and vice versa, but only for these two chains.

• Application-specific (Application-specific):An application that provides access to two or more blockchains, but only within that application. The benefit of the application itself is that the code base is smaller; instead of having a separate instance of the entire application on each blockchain, there are often more lightweight, modular The "adapter". A blockchain that implements an "adapter" has access to all other blockchains it is connected to, thus having a network effect. Their downside is that it is difficult to extend that functionality into other applications (for example, from a lending application to a trading application). Specific use cases include Compound Chain and Thorchain, which respectively build independent blockchains dedicated to cross-chain lending and transactions.

• Generalized:image description

As of September 14, 2021

In addition, according to the mechanism used to verify cross-chain transactions, there are roughly three types of bridge designs:

▲ Type 1: External validators & Federations

image description

Simplified illustration of external validators and federated systems

▲ Type 2: Light clients & Relays

image description

Abstract illustration of a light client/relay system

▲ Type 3: Liquidity networks

image description

Abstract illustration of a fluid network

image description

As of September 14, 2021

It is important to note that any given bridge above is a two-way communication channel. There may be separate models in each channel, so this classification does not accurately represent hybrid models such as Gravity, Interlay, and tBTC. Because they both have light clients in one direction and validator nodes in the other.

safety:

• safety:speed:

• speed:Latency for transaction completion, and finality guarantees. There is usually a trade-off between speed and security.

• Connectivity:Capital efficiency:

• Capital efficiency:Statefulness:

• Statefulness:The ability to transfer specific assets, more complex state, and/or perform cross-chain contract calls.

To sum up, the trade-offs of these three design mechanisms can be evaluated from the perspective of the following figure:

Furthermore, security is a scope, which we can roughly divide into the following categories:

• Trust-less:The security of a bridge is tied to the underlying blockchain it bridges. Users' funds cannot be lost or stolen unless the underlying blockchain suffers a consensus-level attack. That said, it's not completely trustless, as the economic, engineering, and cryptographic components of all these systems contain trust assumptions (eg, that the code is free from vulnerabilities).

• Insured:Attackers are able to steal user funds, but it may not be profitable for them to do so. Because they need to provide collateral first to participate in the network, and will be confiscated when there are wrong behaviors and malicious behaviors. If user funds are lost, the protocol compensates the user by forfeiting the attacker's collateral.

• Bonded :Similar to the insurance model (eg, the economic interests of the participants are closely related to their behavior), except that the user's collateral is confiscated due to mistakes and malicious behaviors. The type of collateral is important for both the insurance and the collateral model; endogenous collateral (protocol tokens used as collateral) is riskier because if the bridge fails, then the value of the token is likely to collapse as well, which further reduces the Security guarantees for bridging.

• Trusted:image description

As of September 14, 2021

first level title

Summarize the trade-offs of the design mechanism

"External validators and federation" are generally better for state and connectivity, as they can trigger transactions, store data, and allow interaction with data on any number of target chains. However, this comes at the cost of security, since users, by definition, rely on the security of the bridge rather than the source or destination chains. While most external validator mechanisms today are trust-based models, some require collateralized assets, a subset of which is used to insure end users. Unfortunately, their insurance mechanisms are often reflexive. If the protocol token is used as collateral, it is assumed that the value of the token is sufficient to compensate the user for losses. In addition, if the mortgage asset is different from the insurance asset, it also needs to rely on the price flow of the oracle machine, so the security of the bridge is also degraded to the security of the oracle machine. And without a trust model, these bridges are also the least capital efficient, as they facilitate economic throughput while requiring a proportional increase in the size of the collateral.

"Light clients and relays" are also better at being stateful, since the block header relay system is able to transmit any type of data. Although there is a liveness assumption due to the need for relays to transmit information, they are also very secure because they do not require additional trust assumptions. At the same time, they are the most capital efficient bridges as no assets need to be locked up. However, these advantages come at the expense of connectivity. Every time a pair of chains are connected, the developer must deploy a new light client smart contract on the source chain and the target chain. The complexity of the contract is between O(LogN) and O(N) (the reason is between this range, because it is relatively easy to add chain support using the same consensus algorithm). There is also a significant speed flaw in optimistic models that rely on fraud proofs, which can increase latency up to 4 hours.

"Liquid networks" are stronger in terms of security and speed because they are locally validated systems (i.e. do not require global consensus). They are also more capital efficient than the external validator mechanism of the staking/insurance mechanism, because capital efficiency is related to transaction flow/value rather than security. For example, given a built-in rebalancing mechanism, liquidity networks can facilitate arbitrarily large economic throughputs, assuming equal transaction flow for both chains.

unresolved issues

unresolved issues

Building robust cross-chain bridges is a difficult problem in distributed systems. Although there have been many attempts in this field, there are still some unresolved problems:

• Finality & rollbacks:In a chain with probabilistic finality, how does the bridge deal with block reorganization and time thief attacks? For example, what would happen to a user sending themselves from Polkadot to Ethereum if either chain experienced a state rollback?

• NFT transfers & provenance (NFT transfers & provenance):How does the bridge trace the origin of NFT across multiple chains? For example, if there is an NFT that has been traded on multiple markets in Ethereum, Flow, and Solana, how are all these transactions and owners recorded?

• Stress testing:first level title

The future of blockchain bridging

Although bridging unlocks more innovation possibilities for the blockchain ecosystem, if the team takes shortcuts in research and development, it may also bring great risks. The Poly Network cross-chain attack incident has shown us the potential scale of the vulnerability and the attack's economic loss, and I expect larger attacks in the future. Although for bridge builders, the current network is highly fragmented and competition is fierce. But teams should be highly disciplined and prioritize security over release speed.

While the ultimate ideal is to build an "isomorphic bridge" common to everything, the reality is that there is likely no single "best" bridge design. Different types of bridges will be suitable for different specific applications (such as asset transfers, contract calls, token minting, etc.).

Furthermore, the best bridge should be the most secure, connectable, fast, capital-efficient, cost-effective, and censorship-resistant. If we want to realize the vision of "Blockchain Internet", these attributes need to be maximized.

So far, we haven't built an optimal bridge. And all bridge types have several interesting development directions:

• Reduce the cost of block header verification:Fixing the costly header validation of light clients will bring us closer to fully universal and trustless interoperability. An interesting design is to bridge to L2 to reduce these costs. For example, implementing a Tendermint light client on top of zkSync.

• Moving from a trust-based model to a staking model:While staking validators is much less capital efficient, the “social contract” is not secure enough to keep billions of dollars in user funds safe. Furthermore, fancy threshold signing mechanisms do not reduce trust; the group of signers still belongs to trusted third parties. In the absence of collateral, users are effectively handing over their assets to an external custodian.

• Shifting from a mortgage model to an insured model:Losing assets is the last thing users want to happen. Although validators and relayers of mortgaged assets can prevent malicious behavior to a certain extent, the protocol should go further and directly compensate users with forfeited funds.

• Expanding the liquidity of the liquidity network:The "liquidity network" is arguably the fastest bridge for asset transfers, and there are some interesting design tradeoffs between trust and liquidity. For example, a liquidity network might leverage a staked validator model to outsource capital supply, where routing could also be a threshold multisig with staked liquidity.

• Bridge aggregation:While the use of bridges may follow exponential laws for specific assets, aggregators like Li Finance can improve the experience for developers and end users alike.