The Future of Cross-Chain Bridges: Full-Chain Interoperability Becomes Inevitable, Liquidity Bridges Will Decline

Introduction:

In the Web3 ecosystem, the cross-chain bridge is a very important part. It is a key facility to break down inter-chain silos and achieve multi-chain interconnection. In the past, people were very active in exploring and practicing cross-chain technology. The number of related cross-chain bridge products has reached hundreds. Some are committed to building a unified interoperability layer, while others are trying to open up the circulation of multi-chain assets. They have different visions and trade-offs in terms of technical solutions.

What this article wants to discuss is: What is the future of cross-chain bridges? What kind of cross-chain protocols are more promising? What cross-chain apps are more likely to gain mass adoption? How should developers build cross-chain apps? In the following, the author will discuss the development trend of cross-chain bridges and present three core arguments:

·A new generation of safe and high-performance cross-chain bridges will become mainstream

·Full-chain applications will become a new dApp paradigm

·Official bridges from asset issuers such as USDC will replace liquidity swap bridges

Text: Cross-chain technology can be understood as an extension of capacity expansion. When one chain is not enough to carry all transaction requests, let multiple chains carry them and use cross-chain bridges to connect them. To understand cross-chain bridges, we must first clarify what problems cross-chain bridges need to solve, so as to divide them into different levels.

Evolution of cross-chain bridges at the protocol layer

The core of the protocol layer is a security mechanism for cross-chain message transmission, that is, a method for verifying cross-chain messages. According to the different verification methods and the ideas of Vitalik and others, the industry has divided cross-chain bridges into three types: atomic exchange based on hash time locks, witness verification, and light client verification. Later, Connext founder Arjun Bhuptani summarized cross-chain bridges into three paradigms: local verification, external verification, and native verification.

Among them, local verification only applies to cross-chain assets, cannot support any message cross-chain, and the user experience is not friendly (requires two user actions to complete a transaction). Some of the first cross-chain bridges that adopted this scheme have changed course and abandoned this route. Native verification is the safest, but the cost is too high. On the one hand, the gas cost for users is too high, and even in some cases it is not economically viable at all. On the other hand, the coding cost for developers is too high. In order to connect to different blockchains, they need to separately develop corresponding light client verification programs. The amount of engineering is extremely large, and the scope of application is extremely limited. Finally, most cross-chain bridges still use external verification solutions. The user’s gas costs and development and implementation costs are relatively low, and support any message across the chain. However, what has been criticized most about external verification is security. Whether it’s Multichian, which experienced thunderstorms this year, or RoninBridge (Axie Infinity Official Bridge) and HorizenBridge (Harmony Chain Official Bridge), which previously had their keys stolen by hackers, they all tell us that a simple external verification solution cannot be the end of cross-chain bridges!

The security risks of cross-chain bridges hinder the development of cross-chain dApps. The application layer is very careful when designing corresponding services. First, it is necessary to avoid links related to cross-chain interoperability as much as possible, and secondly, well-known applications tend to build their own cross-chain bridges (this is the case with leading DeFi projects such as AAVE, Maker, and Compound). As you can imagine, in a city with very poor security, people would choose not to travel, and the rich would bring their own bodyguards when traveling.

What is encouraging, however, is that a new generation of safer cross-chain bridges is growing rapidly. Among them are double security layer bridges such as LayerZero and Chainlink CCIP; ZK bridges (representative projects: Polyhedra, MAP Protocol, Way Network) that combines ZK technology with light clients; optimistic verification bridges that use economic game mechanisms to protect cross-chain security (representative projects: Nomad, cBridge); and those that combine ZK and TEE technologies Bridge (representative project: Bool Network).

[If you want to know their specific mechanism, please refer to the author’s previous article “Multichain Has Fallen, How to Save the Cross-Chain Bridge?”]

In short, the next-generation cross-chain bridge infrastructure achieves higher security without sacrificing performance, providing a solid guarantee for the application layer in cross-chain interoperability related designs.

The paradigm shift of cross-chain interaction at the application layer

Initially, almost all dApps were deployed on Ethereum because there were no options. However, with the prosperity of the application layer ecosystem, Ethereum was overwhelmed. This gave other public chains an opportunity to develop. Various ETH killers, as well as sidechains and Layer 2, appeared one after another.

From the perspective of dApps, Ethereum is a megacity like Shanghai, which has a large population but tight resources and an inch of money. If my business scenario requires high throughput but doesn’t require high interoperability, then I can deploy it on a side chain that is not too crowded. For example, you don’t need to open a printing factory or plantation in Shanghai; you can choose a location in the suburbs. The story of dYdX leaving Ethereum is probably familiar to everyone.

At the same time, a dApp can be deployed on multiple chains to engage in “chain operations”, serve users in different chains, and expand scale and revenue. For example, Sushiswap, the first successful case of a vampire attack, was frantically deployed on 28 chains. As we can imagine, there are basically Sushiswap on the public chain of the name.

However, this multi-chain application ecosystem has brought users a very poor experience: in order to interact with apps on different chains, you also need to understand the differences between different chains, register addresses on multiple chains, recharge gas fees on each chain, and finally move assets back and forth between different chains — oh my gosh, it’s so tiring!

More importantly, many DeFi protocols involve the use of liquidity. If you deploy on multiple chains, you have to guide liquidity on multiple chains. This will cause the liquidity to be scattered across different chains and not shared in depth, and users will have a greater price impact when trading. In response, some people are concerned about the development of Ethereum L2, believing that L2 may break down Ethereum’s liquidity and make it lose its competitive advantage. There are also researchers who have proposed a unified liquidity solution such as SLAMM, but this solution creates more problems than it solves. It’s very lame, so I won’t go into the description here. Interested friends can check out the relevant materials.

The real core question is: how can resources and ecosystems on each chain be aggregated so that users don’t have to be aware of the existence of a “chain”? For example, I have 1 ETH, can I use it wherever I want, and hide the process of automatically exchanging and paying for gas in different chains? I want to use an app, can I use it on any chain without crossing assets? At the same time, the project party no longer has to stand in line to select a chain. Instead of repeatedly deploying on multiple chains, it can be deployed on the most suitable chain, and then people on different chains can use it?

The application layer requires a new paradigm to hide the “chain” layer. Some people imitated the concept of “account abstraction” and coined a new term called “chain abstraction”, which is what it means. Let’s take a look at how an LSD project works?

For example, Bifrost claims to be the pioneer of full-chain LSD, using a different architecture than other LSD products. Bifrost has its own chain, Bifrost Parachain, which is Polkadot’s parachain. Bifrost’s liquidity staking module is only deployed on Bifrost Parachain, and the liquidity of its LSD asset, vToken, is also all on Bifrost Parachain, but other chains can use Bifrost Parachain’s liquidity staking module and liquidity through remote calls. As a result:

• Users can mint vTokens on other chains;
• Users can redeem vTokens on other chains;
• Users can exchange vTokens on other chains, but what is behind this is the liquidity of the Bifrost chain;
• Users can provide liquidity to the vToken/Token pool on Bifrost Parachain on other chains and obtain LP tokens;
• Users can destroy LP tokens on other chains to redeem liquidity.

Users can’t feel the cross-chain delivery process behind these operations at all. Everything is as if it were done locally. Everyone can experience it through the Omni LSD dApp. The Omni LSD dApp currently supports remote minting/redeeming/exchanging vTokens on Ethereum, Moonbeam, Moonriver, and AStar.

Without the above features, if users want to cast vDOT on Moonbeam, they must manually operate three steps, which is very troublesome!

① Transfer DOT from Moonbeam cross-chain to Bifrost

② Get vDOT by staking DOT on the Bifrost chain

③ Transfer vDOT cross-chain back to MoonBeam

However, through the remote call function, the user’s assets appear to be able to complete the above three steps without leaving the Moonbeam chain, and directly convert DOT to vDOT on the Moonbeam chain. In other words, throughout the process, users experience the services on the Bifrost chain as if they were using the Moonbeam local app.

Sounds pretty cool! But how can this be achieved? Actually, it’s not complicated. Bifrost has deployed a remote module (remote modular) on other chains to receive user requests and pass them across chains to Bifrost Parachain. After the liquidity guarantee module processing is completed, the results are returned to the remote module across the chain. Users only need to make requests on the remote chain, and the subsequent process will be triggered and completed by relayers.

Bifrost refers to its architecture as a “full chain architecture”. The comparison with the multi-chain deployment strategies of other LSD protocols is shown below:

The reason to talk so strongly about Bifrost’s architecture is so that everyone can fully understand what Bifrost refers to as a “full chain architecture”. What Bifrost’s architecture actually represents is a new general paradigm.

In its blog post “Cross-Chain Smart Contract”, Chainlink once described this architecture as a “head store+branch” model. The main logic of the application is placed on one chain, like a “main store,” and then the other chains provide a remote access module to enable interaction with end users (obtain user input and output the desired results), just like “stores” one by one.

After the store obtains the user’s input, the input is passed across the chain to the main store, the main store inputs the results after processing, and then transmits the results across the chain to the store for output to the user. In some cases, the different modules of the main store may be split into different chains, and together they form a virtual main store. Under this architecture, the main logic of the program is in the main store, the application has a unified status record, and the problems of fragmented liquidity and user experience have all been solved. In addition, the application of this architecture also has better cross-chain composability, and applications on other chains can also remotely access the main store function like users on other chains.

Although Bifrost refers to this structure as a “full chain architecture,” the author personally doesn’t really like the term “full chain,” or Omni-Chain, because it’s a term with an unclear meaning. Initially, LayerZero invented the term to highlight its unparalleled scalability, but LayerZero never fully explained what “full chain” actually is. Is it “the whole chain”? Definitely not; no app runs on every chain. The author has a game project that says that they are making a full chain game. I only learned that “full chain” means “all code is on the chain”, which distinguishes only some Web3 games with asset data on the chain, which is not compatible with the “full chain” style described by LayerZero.

I think the more appropriate expression is “chain abstraction,” Chain-Abstraction, or Chain-Agnostic (unrelated to the chain); both can express a state where “users don’t need to care about the chain”.

The inevitable decline of the liquidity swap bridge

Finally, we want to talk about another important proposition in the cross-chain sector — liquidity. First, let’s figure out what level of problem it is. Liquidity does not belong to the protocol layer because it is not related to the safe and orderly transmission of cross-chain messages. It belongs to the application layer, and it is a special type of application - SwapBridge.

The largest category of cross-chain applications must be asset bridges. Asset bridges are also divided into WrapBridge and SwapBridge. The former helps users achieve asset transfer through lock-mint/burn-unlock logic, also known as an “asset transfer bridge,” while SwapBridge helps users achieve direct exchange of native assets by reserving liquidity on multiple chains, also known as “liquidity swap bridges.”

Among them, SwapBridge has the widest range of applications and many projects. Different SwapBridge projects essentially compete for liquidity efficiency. Who can provide users with maximum depth with minimal liquidity expenses. In other words, liquidity is the core of the service provided by SwaqBridge. Everyone is competing for who has the best cost advantage. This is the same logic as commercial competition in general. What everyone needs to understand here is that the cost advantage created by the subsidy strategy is unsustainable; you must have an advantage in terms of liquidity mechanism design.

Many projects on the SwapBridge circuit, including Stargate, Hashflow, Orbiter, Symbiosis, Synapse, Thorswap, etc., can be called the Eight Immortals have shown their abilities in improving liquidity efficiency, and have also produced many remarkable innovations. The author previously wrote an article to take stock of this: “Ten Thousand Words Report: Inventory of 25 Liquidity Interchange Cross-Chain Bridges and Their Liquidity Mechanisms”

But CCTP, launched by USDC issuer Circle, made many SwapBridge efforts meaningless; in other words, CCTP destroyed SwapBridge. It feels like the Three Body Civilization took hundreds of millions of years and more than 200 rounds of civilization to solve the Three Body Problem, but in the end Circle tells you: The Three Body Problem is unsolved! For example, in the cross-chain exchange of assets, USDC is the most widely used medium asset. In other words, when you need to exchange A assets on the X chain for B assets on the Y chain, you often need to exchange A for USDC on the X chain, then replace USDC on the X chain with USDC on the Y chain, and then exchange USDC for asset B on the Y chain.

Therefore, the main form of liquidity that SwapBridge reserves on various chains is USDC. CCTP can then support USDC on the X chain to be directly exchanged for native USDC on the Y chain through burn-mint logic without the need for liquidity reserves. In other words, CCTP has no liquidity costs at all, and the bridge fees experienced by the user side can be extremely low.

Maybe you’d say that in addition to USDC, isn’t there also USDT as a commonly used media asset? Not to mention in the DEX sector, the usage rate of USDT is far lower than that of USDC, so you’re not afraid to learn about Tether and Circle. Can you come up with this? So, what I want to tell you is that SwapBridge is dead, and the asset issuer’s official bridge will have an unchallengeable cost advantage in terms of cross-chain liquidity. As for some SwapBridges instead integrate CCTP, that is aggregator logic.

Summarize

The cross-chain bridge protocol layer is becoming more secure and reliable, and the era of multi-signature bridges is coming to an end. In the past, the impression that cross-chain was unsafe will disappear with the popularization of next-generation cross-chain infrastructure;

Cross-chain applications are greatly improving the user experience through paradigm iteration. “Chain abstraction” is no less significant than “account abstraction”, and is creating conditions for Web3 mass manipulation;

CCTP launched by Circle ended the Sengoku era of SwapBridge liquidity competition, and showed us the end of cross-chain asset exchange.

In short, the cross-chain sector is undergoing drastic changes! Only by understanding the way forward can we walk more confidently.

Simply put, a cross-chain bridge can be divided into a protocol layer and an application layer. The protocol layer is responsible for providing a secure and orderly platform for cross-chain messaging, while the application layer builds dApps based on this platform to target users and meet various needs in different scenarios.

Disclaimer：

1. This article is reprinted from [极客Web3]. All copyrights belong to the original author [0xmiddle，极客Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.