Original Title: "The Final Battle of Cross-Chain"

Original Text: @0xOar

Preface:

Before discussing the topic of this article, we need to state that the views expressed herein are solely those of the author. The analysis focuses on product and technology design without considerations of capital operations, marketing, or other directions. Therefore, this article is not investment advice nor a short report; the main issues discussed in this issue are more infrastructure-oriented. Such tracks often have atomicity; they either meet demand and take off quickly or go in the wrong direction and are ignored.

Thus, the projects mentioned in this article should not be considered as investment references provided by the author. This is purely industry research. I hope everyone can join the discussion. If you wish to discuss, you can follow my Twitter: @0xOar

1. Thoughts on Cross-Chain Information Triggered by Synthetix's L1 and L2 Data Compatibility

The impetus for this research report comes from the SIP-156 and SIP-165 proposals released in the Synthetix community in July and December of this year, respectively. Links are provided here:

https://sips.synthetix.io/sips/sip-156/

https://sips.synthetix.io/sips/sip-165/

Currently, these two proposals are still in the feasibility stage, which means that while they have not yet been implemented, their feasibility has been recognized to some extent. The main reason for these proposals is to address the data compatibility issues between Synthetix's Layer 2 and Layer 1. Users who have seen my synthetic asset research report from October should be aware of this.

As the most complex DeFi project in the Ethereum community, Synthetix was officially deployed on the Optimism Layer 2 solution this year.

However, the competitive landscape of multi-chain is gradually forming. Although cross-chain communication can be achieved to a certain extent between Layer 2 and Layer 1, this communication cannot yet be extended to other sidechains or even heterogeneous chains like Solana. This leads to the inability to synchronize the global debt adopted by Synthetix, resulting in significant "liquidity waste."

This "liquidity waste" is one of the biggest problems faced by various DApps in the current era of competing public chains. Especially for global debt projects like Synthetix (projects that share risks similar to pool 2 users will encounter the same issue). When deploying across multiple chains, it becomes necessary to sever the liquidity between chains and restart the incentive for liquidity generation from scratch.

For example, the frequently criticized "DeFi For All" fund introduced Aave, Curve, Sushi, and recently Uniswap through this plan. However, these leading projects still need to re-incentivize liquidity on Polygon and deposit funds.

You might say that for miners, the more new economic incentives, the better, but for users with actual needs, this can cause significant confusion. For instance, the types of collateral and deposits supported on Aave's other chain versions are far fewer than those on ETH, and the assets with good liquidity on Sushiswap on other chains are still far fewer than on Ethereum.

From the project side's perspective, if I want to deploy my unique collateral lending protocol on a well-experienced heterogeneous chain or an EVM sidechain like Polygon, I will face a significant issue: the lack of available collateral types, as there are not many assets on that chain with sufficient liquidity to support large-scale liquidations.

Moreover, currently, there are some mainstream token trading pairs in AMM pools across multiple chains, taking ETH as an example. At the time of writing, the total TVL of this asset on Uniswap V3 is 1.41B, while the TVL on Pancake V2 is about 0.3B.

When conducting the same ETH transaction, the slippage pressure on Pancake is nearly five times that of Uniswap V3's Ethereum version. The larger the amount, the greater the slippage difference. This is also why the adoption rate of trading aggregators is increasing, and even cross-chain trading aggregators are seeing higher adoption rates.

Another example is that users who use Aave on different chains face different interest rates due to the inability to interconnect data across chains. The contracts only adopt the native data of that chain when calculating interest rates. It may not seem like a big difference at first glance, but to put it another way, it’s like having a 4% interest rate at your local bank, only to find that in another major city, the deposit rate is 6%.

The same bank, the same currency—this situation is impossible in traditional financial markets. However, due to the data island problem in blockchain, similar situations are not uncommon.

This leads us to ponder:

Since the multi-chain game and the coexistence of compatible ecosystems have become a foregone conclusion, the future battlefield may become even more chaotic. Is inter-chain information communication the next track that is about to explode?

To this end, my team and I focused on researching various types of current solutions (mainly selecting some representative solutions; other more homogeneous solutions are not within the scope of this report). We hope to analyze the pros and cons of various solutions from different aspects.

The following content involves various technical primitives, and we will try to use simple language to help everyone understand. The infrastructure track sounds very "technical," but in essence, blockchain solutions are philosophical issues of organizational forms and production relationships. Understanding the basic processes and logic does not require understanding the code to grasp the significance of these infrastructures.

2. Existing Cross-Chain Communication Infrastructures

(1) Lightweight Plugin Communication Protocol - LayerZero

LayerZero is a cross-chain communication infrastructure that SeerLabs encountered in August of this year. It caught my attention at the time, but I later missed the opportunity to invest due to other matters (regrettably). Later, I saw this protocol receive investments from Binance, Multicoin, and Delphi Digital, and when I went back to inquire, they no longer responded to me.

1. Solution Overview

LayerZero promotes a lightweight communication-layer-based solution primarily targeting DApps on various chains. It helps them solve the inter-chain information communication problem.

The LayerZero white paper describes this solution as follows (I will try to translate):

The above image illustrates the steps involved in effectively transmitting a single LayerZero message, with each black-background number representing a step.

Step 1: The user application on Chain A (AppA) executes a series of actions as part of transaction t. We uniquely identify transaction T through the transaction identifier t, which may vary in format based on the type of Chain A.

One step included in transaction T is the effective transmission via LayerZero. For illustrative purposes, and without losing generality, we assume that in this scenario, AppA uses our template relayer. AppA sends a request to the LayerZero communicator containing the following information:

t: represents a unique event identifier

dst: represents a global identifier pointing to the smart contract on the chain

payload: represents any message data that the Chain A application wishes to send to the Chain B application

relayer_args: represents some parameters of the payment information submitted when the Chain A application wishes to use the template relayer (a customizable relayer provided by LayerZero) shown in the image.

Step 2: The communicator constructs a LayerZero packet containing dst and payload, referred to as the packet (dst, payload), and sends it along with t and relayer_args to the validator.

Step 3: The validator sends t and dst to the network. This step notifies the network that the block header of the current block on Chain A needs to be sent to Chain B.

Step 4: The validator forwards the packet (dst, payload), t, and relayer_args to the relayer, notifying the relayer that it needs to prefetch the transaction proof for T and ultimately send it to Chain B. This occurs simultaneously with Step 3.

Step 5: The network sends the block ID of the current transaction (curblkid) to the Oracle. This notifies the Oracle to fetch the current block header from Chain A and send it to Chain B. If multiple LayerZero transactions occur in the same block, Step 5 is executed only once.

Step 6: The Oracle reads the block header (blk_hdr) from Chain A.

Step 7: The relayer reads the transaction proof (proof(t)) associated with transaction T from Chain A and stores it off-chain. Steps 6 and 7 occur asynchronously.

Step 8: The Oracle confirms that the blkhdr corresponding to the block has been stably submitted on Chain A, and then sends blkhdr to the network on Chain B. The mechanism for determining when this occurs on each chain varies, but generally requires waiting for a certain number of block confirmations.

Step 9: The network sends the block hash designated as blkJhdrJhash to the validator.

Step 10: The validator forwards blkJhdrJhash to the relayer.

Step 11: Upon receiving blkhdrhash, the relayer sends a list of all packets (dst, payload), t, and proof(t) tuples that match the current block. If multiple users send messages between the same endpoints simultaneously, there may be multiple packets and associated transaction proofs within the same block.

Step 12: The validator uses the received transaction proof along with the block header stored in the network to verify whether the associated transaction T is valid and has been submitted. If the block header and transaction proof do not match, the message is discarded. If they match, the packet (dst, payload) is sent to the communicator.

Step 13: The communicator sends the packet (dst, payload) to AppB. If you are not a developer but can still understand this solution, please DM me on Twitter: @0xOar

2. The main advantages of this solution are:

(1) Lightweight and Low Cost

This solution does not require a node based on chains A and B to provide protocol communication like other solutions. Instead, it can be freely deployed by the project party, using templates provided by LayerZero or even allowing users to design their own relayers. Additionally, the white paper mentions a type of ultra-light node (ULN) that is lighter than light nodes, though I have not found particularly detailed implementations. However, from the description, this also reflects a manifestation of ultra-lightweight deployment.

(2) Communication Layer-Based Solution

This is a key selling point for the project. LayerZero believes its solution is a new communication protocol based on Layer 0. We do not agree with this; its level is not akin to communication protocols like TCP but is merely a data transmission protocol between chains. In terms of level settings, I would prefer to place it at the application layer, situated between Layer 2 and Layer 3.

(3) No Dependence on Third-Party Trust

The white paper mentions cross-chain protocols like Anyswap and THORChain, suggesting that the aforementioned two rely on an intermediate consensus layer, requiring users to trust the services provided by this intermediate consensus layer. In contrast, LayerZero is a peer-to-peer communication primitive that does not require reliance on this intermediate consensus layer.

(4) Summary

It sounds like the cross-chain mechanism described by LayerZero is quite interesting and indeed can solve many practical problems while being sufficiently lightweight. However, looking beyond the phenomenon to the essence, we can also identify some misleading issues that such very "technical" solutions may encounter.

3. Issues

(1) We do not agree that this is a communication layer-based solution

This project is not a communication protocol at Layer 0; the main tools it provides include endpoints and relayers, where endpoints are responsible for verifying communication, and relayers are responsible for transmitting messages. This is merely a data transmission protocol between chains, and in terms of level settings, I would prefer to place it at the application layer, situated between Layer 2 and Layer 3.

(2) LayerZero also relies on an intermediate consensus layer

LayerZero's design employs the relayer and Oracle to mutually verify to ensure security. However, the white paper also mentions extreme situations—where relayers and Oracles collude. LayerZero believes that maintaining relative independence can reduce this risk, but relayers are generally deployed by the project party.

LayerZero suggests that Oracles can use services like Chainlink. Without discussing the cost issues of using Chainlink for communication, essentially, this still relies on trusting that Chainlink will not collude with the project party, and Chainlink is also an intermediate consensus layer.

4. Subjective Outlook Judgment

(1) Most users cannot discern technical differences

Therefore, subtle inducements in promotional storytelling are often harmless. Some "technical" projects exaggerate even more; for us, we have seen too many "writer" type founders.

(2) Lightweight deployment is conducive to promotion and application

Compared to Anyswap, THORChain, Polkadot, Cosmos, and another project to be discussed, LayerZero's solution requires significantly less technical and ecological investment and operational costs. There is no need to build nodes or absorb other validators. The cost of organizing an intermediate consensus layer is certainly much greater than merely providing tools.

Given equal resources, I am more optimistic about LayerZero having better applications in the cross-chain ecosystem.

(3) Narrative and ecological potential are relatively low

Similar to auxiliary products like Anyswap and Chainlink, while LayerZero can play a significant role, its product characteristics limit its narrative ability and ecological expansion capacity.

For example, Chainlink's intermediate consensus layer ecosystem is already quite mature, but due to the deeply rooted image of its Oracles, the overall narrative is not as strong as that of Layer 1 projects like Solana. In fact, Chainlink's capabilities qualify it to be the Layer 3 for all chains.

LayerZero is similar; its tool-oriented product positioning results in poor narrative ability. Some clues can be seen from the two articles subsequently published on Medium. When the founder and team considered LayerZero's scalability issues, their first thought was to collaborate with Cosmos's IBC.

This is roughly equivalent to defining itself at the same narrative level as one of Cosmos's components.

(2) Heterogeneous Cross-Chain Communication Protocol - Axelar

This project is interesting; its overall title and conveyed concept align well with the issues we are discussing today. It aims to empower DApp developers and the blockchain ecosystem, taking into account the compatibility issues of different heterogeneous chain ecosystems from the design outset.

1. Officially Promoted Vision

(1) For underlying developers

Integrate your blockchain with all other blockchains.

(2) For DApp developers

Deploy your DApp anywhere and achieve cross-chain asset and information transfer between any chains through Axelar.

(3) For users

Interact directly with DApps across all blockchain ecosystems from your wallet.

2. The basic principles of the project are as follows

This diagram comes from the official documentation and looks quite complex. We will simplify it into the following textual process.

3. Axelar Cross-Chain Protocol Process

Assuming there are Chain S and Chain D, with Axelar providing cross-chain services for these two chains.

State Information Cross-Chain

Axelar operates nodes of different chains through validators within the Axelar network to obtain and synchronize state information from various blockchain systems, such as block hashes, current block heights, etc. The core process of state information cross-chain is as follows:

(1) A user on Chain D makes a request for state information data from Chain S through the API provided by Axelar, directed to the cross-chain bridge account or directly on the Axelar blockchain, denoted as Q.

(2) Each Axelar validator must run the node software for Chains S and D. Axelar validators query the API of their Chain S node software to obtain answer A and send A to the Axelar chain.

(3) Once a threshold weight of validators reports the same answer at block R, they will use threshold signature technology to publish a signature of the answer S at block R+11.

(4) Anyone can retrieve the signed answer S from block R+11 and publish it to the D network. Users on the D network can query this answer through the API provided by Axelar.

Asset Cross-Chain

Assuming a user requests to exchange x amount of tokens on the source chain S for x amount of pegged token S' on the target chain D, stored at the user's address W\_D\ on Chain D. The workflow is as follows:

(1) The user sends a cross-chain transfer request (x, W\_D\) to the cross-chain bridge account, which is captured and routed to the Axelar network by a listener.

(2) The current cluster of Axelar validators jointly creates a new deposit address D\_S\ on Chain S using threshold signature technology and broadcasts it to the Axelar network.

(3) The user obtains D\_S\ by monitoring the Axelar blockchain and then sends x amount of S tokens to address D\_S\.

(4) The validators check whether the user has successfully transferred. If a threshold weight of validators broadcasts that the transfer was successful in block R, the validators sign transaction tx\_D\, which will transfer x amount of S' tokens to W\_D\, and broadcast the signed result in block R+11.

(5) Anyone can retrieve the signed transaction tx\_D\ from block R+11 and publish it to Chain D, thus completing the cross-chain asset transfer.

This solution is more complex compared to the previously mentioned LayerZero, with more verification processes and logic. Overall, the significant difference is that LayerZero uses external Oracles as part of the validators, relying on external Oracles to ensure security and act as an intermediate consensus layer.

In contrast, Axelar constructs a third-party chain using BFT Byzantine consensus, synchronizing information from other chains to the Axelar network through CTP, and then relaying information on other chains through nodes on the Axelar chain using threshold signatures.

This solution is essentially not much different from the approaches used by Anyswap and THORChain, and can also be represented by a notary mechanism. Such solutions are one of the most important schools of thought in cross-chain communication.

4. Advantages of this solution

(1) An independent third-party chain can unleash greater imagination

The Axelar network, targeting heterogeneous chains, is essentially a blockchain network. Although it supports a DApp on chain A to cross-chain to Chain B through Axelar as an intermediary, the optimal solution for developers remains to deploy the DApp directly on Axelar. In this case, regardless of where subsequent versions are deployed, it will only diverge downwards rather than connect upwards.

If Axelar can develop its ecosystem well, it may possess the capability to become a so-called Layer 3. This position is similar to the relay chain in the Polkadot ecosystem. At that time, ETH, BTC may even have the opportunity to be referred to as subchains of Axelar.

(2) No need to rely on third-party Oracles, potentially lower efficiency and overall costs

Although LayerZero's solution has low deployment costs for endpoints and relayers and is lightweight, the cost and efficiency of using Oracles will become important factors influencing DApp developers' choices.

For example, if Project A wishes to transmit debt data from the main contract on Chain A to Chain B via LayerZero and Chainlink, the call to Chainlink may incur costs. Additionally, Chainlink does not push data as directly as Axelar listens to block data from various chains; instead, it pushes data at regular intervals or under certain rules. For instance, it may push data every minute or not push if the debt fluctuation does not exceed 1%.

This behavior requires payment to Chainlink. Chainlink has a market called Chainlink Market, where many data providers exist, and each data provider has a contract for each type of data.

You need data, so you call this contract and pay in LINK. The data provider queries off-chain and then feeds the data into your contract (thus the query is asynchronous, with at least one block of delay). The payment in LINK is roughly the gas fee for feeding data plus a bit of profit, for example, Ethereum charges about 1 to 3 LINK per transaction, while on BSC it charges about 0.1 LINK.

The frequency of this asynchronous heterogeneous chain communication is very high, and the corresponding costs can also be substantial. Therefore, Axelar's general solution may have much lower overall costs.

5. Subjective Outlook Judgment

(1) From an overall product design perspective, Axelar's product form is closer to projects like Anyswap, as most users have a higher tolerance for the decentralization level of intermediate consensus layers. The service providers and ecological conditions of the chains where Chainlink and Anyswap reside are likely unknown to 99% of users; they will only care about which cross-chain communication solution is most recommended on their respective chains.

This indicates that the true test of a general heterogeneous cross-chain solution is the project party's ability to connect to Layer 1. For now, we have not seen much action from Axelar. Additionally, in terms of technical solutions, we do not believe it possesses advantages sufficient to generate self-propagating effects.

However, compared to Polkadot, the difficulty of advancing the Axelar ecosystem will be significantly lower than that of other Layer 1s. It can be used as a tool layer without needing to recreate an ecosystem.

(2) In terms of narrative ability, Axelar's currently displayed narrative potential is far lower than that of Cosmos and Polkadot. Although both are cross-chain, and Axelar may even be more practical, Polkadot and Cosmos have both proposed standardized blockchain protocols. This gives them a much stronger overall narrative ability than Axelar.

(3) Polkadot and Cosmos

1. Basic Information

Polkadot and Cosmos are the most vocal, ecologically rich, and highest market cap projects in this market. Overall, the values and product visions articulated by these two projects far exceed those of the previously mentioned LayerZero and Axelar.

We will not discuss the specific solutions of Polkadot and Cosmos, as there are numerous documents in various languages. Instead, we will present an overview of their overall solutions.

Both Polkadot and Cosmos mention cross-chain solutions between heterogeneous chains, such as the cross-chain interactions between Substrate and Tendermint chains with ETH, BTC, etc. The basic principles are not much different from those of Axelar and LayerZero, both requiring an intermediate consensus layer to complete cross-chain transactions through a notary mechanism.

However, Polkadot and Cosmos tell another seemingly more attractive story—standardized blockchains and homogenous cross-chain solutions. In other words: recreating ecosystems for a myriad of interconnected chains.

2. Comparison with LayerZero & Axelar

From the above image, we can see that I have simplified the complex processes (the threads marked are not precise, as Polkadot's heterogeneous cross-chain requires bridging chains rather than directly interacting with the intermediate consensus layer's relay chain). The conclusion drawn is that the three types of solutions mentioned above do not have essential differences regarding the heterogeneous cross-chain issue, but their thoughts on the broader topic of cross-chain differ.

Polkadot and Cosmos believe that the security and stability of homogenous cross-chain solutions are the best, and that latecomer products have lower technical debt. Therefore, while they also support heterogeneous cross-chain, the focus is indeed on the homogenous cross-chain within the Substrate and Tendermint systems.

Axelar believes that a unified standard is the most efficient and secure way to solve heterogeneous cross-chain issues, thus establishing the Axelar Network. It inherits cross-chain communication and relay services while providing an intermediate consensus layer for interaction with heterogeneous chains.

LayerZero, on the other hand, believes that a lightweight cross-chain communication protocol for developers is a necessity, thus only providing relayers and communication protocols while using Oracles to act as the intermediate consensus layer.

Which of these solutions will gain more attention and have greater prospects in the market competition of 2022?

(4) Comprehensive Outlook Analysis

1. Current Market Competition Landscape

a. Heterogeneous chain competition incentives; multi-chain parallelism has become a foregone conclusion.

b. Whales are settling in ETH, while users are settling in multiple lower-cost, better-experienced Layer 1s—BSC, AVAX, Solana.

c. Combinatorial innovation has become the mainstream of innovation.

d. EVM ecosystem occupies a very high market share.

2. Reference Model Comparison

From the perspective of ecological development, these three solutions differ in narrative, ecological development strategies, and other directions. We will analyze each dimension in a tabular format:

From the table, we can see the biggest difficulties faced by each solution and their future prospects, as well as the user groups that need to be prioritized for expansion.

Polkadot & Cosmos, due to their greater ambitions and aspirations, face larger challenges.

We can conclude with some certainty that unless their tools are sufficiently refined and their ecosystems sufficiently active, they will find it difficult to achieve the visions described in their white papers.

At least in the current multi-chain competition, it seems that the core solutions of Polkadot and Cosmos regarding homogenous chains do not align with the current mainstream.

However, Cosmos and Polkadot still have some subtle differences in design. For example, Cosmos provides a solution for completing heterogeneous cross-chain interactions using IBC and pegs.

In short, it is roughly equivalent to saying that the functionalities provided by Cosmos can quickly and efficiently establish a network similar to Axelar. Moreover, this network may still have the potential for future interactions with other homogenous chains.

The advantage of this approach is that even if the core homogenous cross-chain cannot be completed, the efficient adoption of heterogeneous cross-chain can still be regarded as an achievement of the Cosmos ecosystem.

In contrast, Polkadot's XCMP (which is still unfinished) is heavily coupled with the consensus of the relay chain, making it difficult to split independently. Developers need to establish their own cross-chain systems with heterogeneous chains like BTC and ETH. While this reduces the development costs of the intermediate consensus layer, it is indeed far from the envisioned goals.

Therefore, overall, Polkadot's design may face numerous challenges. After the slot auction is completed, Polkadot will require substantial incentives and native DApps on the Substrate chain to break through the current fierce competition. This difficulty should be the greatest among all projects observed so far.

Of course, the capabilities of Parity and the Web3 Foundation are beyond doubt; this article only analyzes the difficulties from the product and technical perspectives and does not serve as investment advice.

6. Seer’s Perspective

(1) LayerZero's solution may reach the market the fastest

Because LayerZero's solution is more aligned with the actual needs of DApp developers in the current market. Taking the situation of Synthetix mentioned at the beginning as an example, Synthetix can use LayerZero + Chainlink to quickly complete the integration of Layer 1 & 2 debt pools.

(2) Axelar faces the greatest homogeneity competition

Compared to the lightweight and rapid deployment approach of LayerZero, Axelar's solution is more homogeneous, with Polkadot & Cosmos above it and Anyswap & THORChain parallel to it. The adoption rate of Layer 1 will be its biggest obstacle; in this regard, I do not see Axelar surpassing Anyswap. Although the latter currently focuses on asset cross-chain, the difficulty of upgrading to message cross-chain is not high, and it already has a very high Layer 1 adoption rate. Axelar is not content to merely be a lightweight communication component, as its overall narrative and value capture capabilities are relatively weak.

(3) Cosmos's expected adoption rate will be higher than Polkadot's

Cosmos's more flexible architecture makes its technical difficulty lower, and its application-oriented design style has already led to many outstanding products based on Tendermint, including the recently popular LUNA (Terra).

(4) The Polkadot ecosystem faces enormous challenges

Among all the aforementioned solutions, Polkadot faces the greatest promotional pressure, as its complex technical solutions lead to repeated delays, continuously eroding user confidence. The only thing that can truly prove Polkadot's aspirations may be a "killer product that fully leverages inter-chain composability." Of course, the many stakeholders involved in the Polkadot ecosystem may help it perform better due to its latecomer advantages.