In the world of blockchain, each network can be regarded as an independent ecosystem with its own native assets, communication rules, etc. However, this characteristic also results in blockchains being isolated from one another, impeding the free flow of assets and information. Therefore, the concept of cross-chain interoperability has emerged.

1. The Significance and Use Cases of Cross-Chain Interoperability

DeFi is the core and foundation of today’s blockchain but faces many challenges such as liquidity fragmentation, insufficient depth of asset pools, and low capital utilization. The emergence of cross-chain interoperability protocols can integrate assets from various chains into a unified smart contract, thereby maximizing the user experience and capital utilization. In an ideal scenario, cross-chain interoperability protocols can reduce friction to zero.

For example:

(1) Depositing assets from the OP chain into GMX on the ARB chain to increase the depth of the liquidity pool.

(2) Using assets from the OP chain for collateralized borrowing on Compound on the ARB chain.

(3) Achieving cross-chain transfer of NFT assets.

Beyond the financial aspect, the transmission of information is also crucial: for example, cross-chain voting to support significant proposals, or the transfer of data between Social dapps. If DeFi has opened the door to the world of cryptocurrencies, then cross-chain interoperability protocols are the essential path to success!

2.Four Types of Cross-Chain Interoperability Protocols

2.1 Verification Based on Nodes or Third-Party Networks (Type One)

2.1 Verification Based on Nodes or Third-Party Networks (Type One)

The most rudimentary cross-chain protocols employ Multi-Party Computation (MPC) for transaction verification. Thorchain serves as a prime example, validating transactions through nodes deployed on the blockchain to establish security standards. Typically, such protocols attract between 100 to 250 node validators to the network. However, the downside of this approach is the requirement for each node to verify every transaction, leading to extended waiting times for users. Moreover, the operational costs of nodes are significant for the protocol and are ultimately passed on to the users.

In addition, Thorchain sets up a Liquidity Pool for each trading pair, utilizing its native token RUNE. Each cross-asset transaction requires the assets to be exchanged into RUNE and then into the target chain’s assets. This model demands substantial capital support and incurs attrition, which, in the long run, does not represent the most efficient solution for cross-chain protocols.

Tips: The attack on Thorchain was due to a code vulnerability (the system mistook fake ETH symbols for real ones) and is not related to the security of the verification method.

Table 1: Performance Comparison Among Cross-Chain Interoperability Protocols

2.1.2 Improvements

In response to this phenomenon, Wormhole has selected 19 Validators to verify the authenticity of transactions, including well-known node validators such as Jump Crypto. These validators also operate on other networks such as ETH and OP. However, this approach carries a risk of being too centralized. The author believes that complete decentralization may not always be the best choice, as a certain degree of centralized management can reduce costs. Ultimately, the goal of any project is to achieve mass adoption and maximize economic benefits. It’s important to note that Wormhole’s vulnerability to attack was due to a contract flaw; the attacker used an external contract to validate transactions and steal assets, which was unrelated to the inherent security of the validation process.

In contrast to other cross-chain protocols, Axelar is a blockchain based on Proof of Stake (POS). Axelar packages verification information from other networks and sends it to its mainnet for validation before forwarding it to the target chain. It is worth noting that there is an inverse relationship between validation costs and security. As the amount of verification information increases, more nodes are needed to participate in validation and maintain network security. In theory, there is no upper limit to the number of nodes, and an increase in node count can cause transfer costs to surge. Axelar may encounter this dilemma in the future.

Figure 1: Axelar Verification Mechanism

2.2 Optimistic Verification (The Second Type)

The success of Optimistic Verification (OP) indicates its current security, cost-effectiveness, and speed advantages. Consequently, cross-chain protocols like Synapse have adopted this verification model. However, Synapse uses a Lock/Mint method for asset exchange, which carries risks of hacker attacks. The reasons for this vulnerability will be discussed in section 2.3.1. Moreover, optimistic verification meets only present needs; more secure and reliable methods will eventually be required, while still maintaining the advantages in speed and cost. The author will now introduce Dual Verification as a replacement for Optimistic Verification.

2.3 Dual Verification (The Third Type)

The most noteworthy dual verification protocols in the market are LayerZero and Chainlink. To summarize the findings, the author believes that dual verification has the brightest development prospects in the realm of cross-chain protocols, surpassing others in terms of security, speed, and response time.

(1) LayerZero

One innovation of LayerZero is the deployment of ultra-light nodes across various chains, which transmit data to off-chain Relayers and Oracles (provided by Chainlink) for verification. This avoids the heavy computational tasks associated with the first type of protocol. The Oracle generates information such as block headers, while the Relayer confirms the authenticity of transactions. Transactions are only processed when both components function correctly. It’s important to note that they operate independently. A hacker would need to control both the Relayer and Oracle to steal assets. Compared to optimistic verification, this is more secure as it verifies every transaction.

Figure 2: LayerZero Verification Mechanism

Cost and Security Advantages: The author conducted experiments using Stargate (powered by LayerZero technology)

1）From OP to ARB requires 1 minute to complete the transaction—-$1.46

2）From OP to BSC requires 1 minute to complete the transaction—-$0.77

3）From OP to ETH requires 1 minute and 30 seconds to complete the transaction—-$11.42

Based on the above, the dual verification model is in a clear leading position.

(2) Chainlink

Committing DON collects transaction data, and the target chain ARM gathers information from the source chain ARM to reconstruct the Merkle tree and compare it with the Committing DON’s Merkle tree. After a certain number of nodes ‘verify’ successfully, the transaction is committed to the Executing DON for execution, and vice versa. Note: ARM is an independent system. Chainlink’s technology shares a 90% similarity with the principles of LayerZero, both adopting the “collect information + verify information (verify each transaction)” model.

Figure 3: Chainlink Verification Mechanism

Chainlink currently supports projects such as Synthetix (for cross-chain transfer of sUSD) and Aave (for cross-chain governance voting). From a security perspective, although ARM and Executing DON are two systems, both are controlled by Chainlink, which poses a risk of internal theft. Additionally, with similar technologies, Chainlink is more likely to attract established projects that seek in-depth collaboration to use its services, achieving a bundling effect. In contrast, LayerZero is more appealing for new projects to deploy. But in terms of supported networks and ecosystems, LayerZero has the upper hand. Moreover, project developers generally prefer to deploy their products on popular ecosystems.

Figure 4: LayerZero Ecosystem

2.3.1 The Layerzero Impossibility Triangle

Figure 5: Layerzero’s Impossibility Triangle

Security: There are four methods for cross-chain asset transfers:

1）Lock/Mint: Cross-chain protocols deploy liquidity pools across various networks. When a user wishes to transfer ETH from Chain A to Chain B, they must lock the ETH on Chain A, and then an equivalent amount of wETH is minted on Chain B. To transfer back to Chain A, the wETH is burned, and the locked ETH on Chain A is released. The risk here is that security relies entirely on the cross-chain bridge—if the amount locked is substantial, it becomes a lucrative target for hackers to attack the liquidity pools.

2）Burn/Mint: Tokens are minted in the form of Omnichain Fungible Tokens (OFT), allowing a certain amount of tokens to be burned on the source chain and an equivalent amount minted on Chain B. This method avoids the risks associated with large liquidity pools and theoretically offers greater security. The OFT model is generally chosen at the time of token issuance, facilitating circulation between dapps. While existing projects could convert their tokens to OFT, it’s challenging due to the involvement of multiple stakeholders’ interests, such as handling the native tokens within other dapps post-conversion. Therefore, it’s a more viable option for new projects. In summary, it’s unnecessary for existing projects to take this risk; they can continue developing along the existing path. Hence, choosing security means it cannot be applied to older projects.

3）Atomic Swap: The protocol establishes liquidity pools on both chains, storing a certain amount of tokens. When users perform a cross-chain transfer, they deposit assets into the liquidity pool on Chain A, and the corresponding number of tokens is withdrawn from Chain B’s pool and sent to the user. This is essentially a simultaneous increase and decrease in token amounts, offering high security.

4）Intermediate Token: As described in 2.1, Thorchain can cause attrition and involves long waiting times.

Currently, Atomic Swap is the most widely used method, but the future will likely trend towards the Burn/Mint model, achieving true zero attrition in cross-chain transfers while maintaining security. Another concern for older projects considering using Layerzero is the manipulation of oracle prices. There have been numerous attacks on oracles, and since the technology is not yet fully mature, most protocols adopt a cautious stance.

Review: Layerzero’s Relayers and Endpoint verification parameters are set by the project developers themselves, which poses a risk of malicious operation. Hence, the review process is particularly stringent, leading to few Layerzero projects breaking out into wider recognition. If the review process is abandoned to allow older projects to use Layerzero, security cannot be guaranteed. By choosing security, new projects face a particularly difficult review process. This conundrum has left Layerzero in need of more time to develop.

2.4 Modular Cross-Chain Protocol (AMB Verification, Type Four)

Connext functions as a modular cross-chain interoperability protocol, structured in a hub-and-spoke design. It delegates the verification between Chain A and Chain B to their respective Arbitrary Message Bridges (AMBs)—with the spoke being Chain A & B. The generated Merkle tree proofs are stored on the Ethereum mainnet, which acts as the hub.

Figure 6: Connext Verification Mechanism

This protocol offers the highest security level because our trust is placed in the security of the Ethereum network, applying the principle of shared security. If Layerzero technology is utilized, what we are actually trusting is the project team itself, which is theoretically safer than so-called dual validation. In the long term, some OP cross-chain protocols may have security issues, and the future trend is likely to shift towards ZKP (Zero-Knowledge Proofs) or dual validation models. On the other hand, for the secure verification of native tokens across chains, each chain uses its own AMB module for verification, and these verifications may have inconsistent transmission times. Official AMB usually requires a longer verification time, and sometimes users may have to wait up to four hours or even longer to complete the verification. This could potentially limit the scalability of the Connext protocol in terms of overall economic efficiency and general usage.

3.ZKP-Based Cross-Chain Protocol

The competition among existing cross-chain protocols is already fierce, and many project teams have set their sights on Zero-Knowledge Proofs (ZKPs), hoping to keep pace with the concept of ZK rollups. They use technologies such as ZK relayers and ZK light-endpoints, emphasizing the highest security. However, I believe that it’s still too early for ZKP to be applied in the cross-chain domain within the next 5-10 years, and it’s difficult for it to compete with existing cross-chain protocols for the following reasons:

(1) The time and cost to generate proofs are too high. Zero-Knowledge Proofs are divided into ZK STARKs and ZK SNARKs, with the former having larger proofs but shorter generation time, and the latter having smaller proofs but longer generation time (the larger the proof, the higher the cost). Most ZKP cross-chain solutions will choose ZK SNARKs because if the cross-chain cost is too high, no users will choose the solution. So, how do we address the issue of the lengthy time required? Some protocols may add a ‘fast track’, similar to Optimistic rollups (OP), where they process the transaction first and verify it later. However, this isn’t strictly a ZKP and is more like an OP Plus version.

(2) High infrastructure demands. ZKPs require significant computational data and performance support. If ZKPs were to be used on a large scale, there would be a shortage of computational power, and protocols would need to invest heavily in infrastructure, which is not economically feasible at present.

(3) Uncertainty in technological evolution. In the existing cross-chain protocols, methods involving dual verification already offer sufficiently high security to meet current needs. Although it might seem that ZKPs are not needed now, future technological iterations could change this situation. Just like twenty years ago, whether third-tier cities needed to build overpasses, there might not be an immediate need in the short term, but in the long term, ZKPs could become the cornerstone of cross-chain domain development. Therefore, even though it’s not yet the time for ZKPs, it is essential for teams to continue their research and exploration, and to stay informed, as the pace of technological development is unpredictable.

4.Conclusion and Reflection

Cross-chain interoperability protocols are essential for the development of blockchain. Among various cross-chain protocols, the dual validation mechanism stands out in terms of security, cost, and speed, especially with industry leaders like Layerzero and Chainlink. Although their technical implementations are fundamentally similar, Layerzero boasts a richer ecosystem, giving it a competitive edge at present. However, Layerzero’s progress in ecosystem development has been slower due to its security and audit mechanisms, but it is believed that there will be more opportunities for development in the future. As for Zero-Knowledge Proof (ZKP) based cross-chain solutions, while their application is still a distant prospect, their development trajectory is promising, and they warrant continued attention.

The author remains optimistic about Layerzero and the cross-chain domain but also highlights some potential issues. Most existing cross-chain protocols are at L0 (the transport layer) and are primarily used for asset transfer and message dissemination (social, governance, etc.). In terms of asset transfer, existing cross-chain bridges are pseudo-cross-chain. The author believes that true cross-chain refers to an asset genuinely moving to another chain (Burn/Mint) rather than Lock/Mint or Atomic Swap. However, to achieve this, existing projects would need to be completely overhauled for new ones to take their place, with token issuance in the OFT model. But this is highly challenging and requires a significant transition period.

We still live in a world that relies on “third parties,” with blockchains remaining isolated. In terms of message transmission, chains can rely on the transport layer to pass messages, but the current demand is not significant. For example, cross-chain communication between Lens and Cyber is required for social messaging, but the scale of development in the social domain is uncertain. Furthermore, if most dapps are deployed within the Lens ecosystem and can communicate freely, there would be no need for cross-chain. Cross-chain becomes necessary only in a highly competitive environment.

This leads to the discussion of new threats from Layer2 superchains, such as the success of the OP superchain, which could lead more Layer2 solutions to adopt similar technologies for seamless integration (assets). The success of blockchain in the future and the inability of OP and other rollups to handle an excessive number of users and transactions could give rise to more Layer2 solutions. The essence of seamless integration is the use of a common settlement layer. Thus, asset transfers do not require a third party but instead obtain transaction data from the same settlement layer and are verified on their respective chains. Similarly, what cross-chain protocols most hope to see is competition between OP, ARB, ZKsync, and Starnet without a clear hierarchy, as this would facilitate transfers between these ecosystems. Otherwise, if one Layer2 dominates 80% of the market share, cross-chain would become unnecessary. However, the future holds many uncertainties, and these are just some of the author’s concerns, which should be considered as appropriate.

Disclaimer: This article does not constitute investment advice. Readers should consider whether any opinions, views, or conclusions presented herein are appropriate for their specific circumstances and comply with the laws and regulations of their country or region.

Disclaimer：

1. This article is reprinted from[mirror]. All copyrights belong to the original author [@Daniel 花、PSE Trading Analyst]. 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.