An All-Chain Interoperability Protocol

Forward the Original Title：The Key to Chain-Wide Connectivity: An All-Chain Interoperability Protocol

Author: YBB Capital Researcher Zeke

Foreword

Since its inception, blockchain technology has been a constant source of contention, evolving from its initial intent as an “electronic payment system” to becoming the “world computer,” emphasizing “high-speed parallel processing,” and serving as the backbone for applications in gaming and finance. The divergence in values and technical disputes have led to the emergence of hundreds of public blockchains. Due to their decentralized nature, blockchains are inherently closed and isolated systems, unable to perceive or communicate with the external world, rendering inter-blockchain connectivity non-existent. The current mainstream narrative of public blockchains is moving towards a multi-tiered modular process. Beyond Layer 2 execution layers, we have data availability (DA) layers, settlement layers, and even execution layers atop other execution layers. The fragmentation of liquidity and disjointed user experiences are set to intensify. Traditional cross-chain bridge solutions are fraught with risks.

From the perspective of an average user, transferring assets across blockchains via bridges is already cumbersome and lengthy, not to mention the risks of asset disparity, hacker attacks, surging Gas fees, and liquidity shortages on target chains. The lack of interoperability between chains not only hampers the widespread adoption of blockchain technology but also perpetuates the perception of public blockchains as hostile tribes or nations, engaged in endless debates over the “Blockchain Trilemma” and the merits of various solutions across different layers. As the parallel development of multi-chain and multi-layer systems intensifies, the demand for full-chain interconnectivity in Web3 becomes more urgent. How far has the development of full-chain interoperability protocols come? And how far are we from reaching the next billion users?

What is Full-Chain Interoperability?

In the traditional internet, operational experience fragmentation is hardly felt, as payment scenarios using Alipay or WeChat can usually fulfill all online payment requests. However, in the Web3 world, inherent barriers exist between public blockchains. Simplified, full-chain interoperability protocols serve as the hammer to break down these barriers. Through cross-chain communication solutions, they enable the seamless transfer of assets and information across multiple public blockchains, aiming to achieve a seamless experience similar to that of the Web2 level, and ultimately reaching the ultimate goal of chain agnosticism or even Intent-Centricity.

The realization of full-chain interoperability involves tackling several key challenges, including communication issues between non-homogeneous smart contract chains and non-wrapped methods of asset transfer across chains. To address these challenges, some projects and protocols have introduced innovative solutions, such as LayerZero, Axelar, and Wormhole. We will further analyze these projects in the following sections, but before that, it’s necessary to understand the various challenges and current methods of cross-chain interactions.

What Has Full-Chain Changed?

Unlike the past, where users had to lock assets on the source chain and pay Gas, waiting a long time to receive a wrapped token on the target chain through third-party bridges, full-chain interoperability protocols represent a new paradigm extended from cross-chain technology. It serves as a communication hub that transmits all information, including assets. This enables interoperability between chains, for instance, exchanging assets seamlessly within Sushi that integrates Stargate for routing between the source and target chains, greatly optimizing the cross-chain experience for users. In the future, even more ambitious use cases could include seamless interoperability between different DApps across various chains.

Triangle selection and three types of verification

The world of blockchain is always filled with decisions, much like the famous Blockchain Trilemma for public chains, cross-chain solutions also face an Interoperability Trilemma. Due to technical and security limitations, cross-chain protocols can only optimize for two out of the following three key attributes:

1. Trustlessness: The operations of the protocol do not depend on any centralized trust entity and can provide the same level of security as the underlying blockchain. This means that users and participants do not need to trust any intermediary or third party to ensure the security and correct execution of transactions;
2. Extensibility: The protocol can easily apply to any blockchain platform or network, unrestricted by specific technological architectures or rules. This allows interoperability solutions to support a broad range of blockchain ecosystems, not just a few specific networks;
3. Generalizability: The protocol can handle any type of cross-domain data or asset transfer, not just specific transaction types or assets. This means that through the bridge, different blockchains can exchange various types of information and value, including but not limited to cryptocurrencies, smart contract calls, and any other arbitrary data.

Early classifications of cross-chain bridges were generally based on Vitalik’s divisions, categorizing cross-chain technologies into three types: hash time-locked contracts, witness-based verification, and relay verification (light client verification). However, according to Arjun Bhuptani, the founder of Connext, cross-chain solutions can also be divided into native verification (Trustlessness + Extensibility), external verification (Extensibility + Generalizability), and native verification (Trustlessness + Generalizability). These verification methods are based on different trust models and technical implementations to meet various security and interoperability needs.

Natively Verified:
· Natively verified bridges rely on the consensus mechanisms of both the source and target chains to directly validate the transactions. This method does not require an additional layer of verification or intermediaries. For example, some bridges may utilize smart contracts to create direct verification logic between two blockchains, allowing them to confirm transactions through their own consensus mechanisms. This approach enhances security because it directly depends on the inherent security mechanisms of the involved chains. However, this method might be technically more complex and not all blockchains support direct native verification.

Externally Verified:
· Externally verified bridges use third-party validators or clusters of validators to confirm the validity of transactions. These validators could be independent nodes, consortium members, or some other form of participant operating outside of the source and target chains. This approach often involves cross-chain messaging and verification logic executed by external entities, rather than being directly processed by the involved blockchains themselves. External verification allows for broader interoperability and flexibility since it is not limited to specific chains, but it also introduces an additional layer of trust and potential security risks. (Although there are significant centralization risks, external verification is the most mainstream method, offering flexibility, efficiency, and low costs.)

Locally Verified:
· Locally verified refers to the target chain verifying the state of the source chain to confirm transactions and locally execute subsequent transactions. The common practice is to run a light client on the source chain within the target chain’s virtual machine or to run them in parallel. Locally verified requires either an honest minority or a synchrony assumption, with at least one honest relayer in the committee (the honest minority) or, if the committee fails to operate normally, users must transmit the transactions themselves (the synchrony assumption). Local verification is the most trust-minimized form of cross-chain communication but is also costly, less flexible in development, and more suited for blockchains with similar state machines, such as between Ethereum and L2 networks, or between blockchains developed based on the Cosmos SDK.

Different types of schemes

Different Types of Solutions As one of the most crucial infrastructures in the Web3 world, the design of cross-chain solutions remains a challenging issue, leading to the emergence of various types of solutions. Current solutions can be categorized into five types, each adopting unique methods to facilitate asset exchange, transfer, and contract invocation.

· Token Swap Mechanisms: This process allows users to trade a certain asset on one blockchain and receive an equivalent asset on another chain. By leveraging technologies such as atomic swaps and cross-chain Automated Market Makers (AMM), liquidity pools can be created on different chains, enabling seamless exchange between various assets.

· Asset Bridging Technology: This method involves locking or burning assets on the source chain through smart contracts and unlocking or creating new assets on the target chain through corresponding smart contracts. This technology can be further divided into three types based on how assets are handled:

• Lock/Mint Mode: In this mode, assets on the source chain are locked, while “bridged assets” of equivalent value are minted on the target chain. The reverse operation destroys the bridged assets on the target chain to unlock the original assets on the source chain.
• Burn/Mint Mode: In this mode, assets on the source chain are destroyed, and an equivalent amount of the same assets are minted on the target chain.
• Lock/Unlock Mode: This method involves locking assets on the source chain and then unlocking equivalent assets in the liquidity pool on the target chain. Such asset bridges often attract liquidity by offering incentives like revenue sharing.

· Native Payment Functionality: Enables applications on the source chain to trigger payment operations using native assets on the target chain, or trigger cross-chain payments based on data from one chain on another. This method is mainly used for settlements and can be triggered based on blockchain data or external events.

· Smart Contract Interoperability: Allows smart contracts on the source chain to call functions of smart contracts on the target chain based on local data, enabling complex cross-chain applications including asset exchanges and bridging operations.

· Programmable Asset Bridges: This is an advanced interoperability solution that combines asset bridging and messaging functionalities. When assets are transferred from the source chain to the target chain, contract calls on the target chain can be immediately triggered, enabling various cross-chain functions such as staking, asset exchanges, or storing assets in smart contracts on the target chain.

Layer Zero

As the most renowned project within the full-chain interoperability protocol arena, Layer Zero has attracted significant crypto capital from a16z, Sequoia Capital, Coinbase Ventures, Binance Labs, and Multicoin Capital, completing three rounds of financing totaling $315 million. Beyond the project’s inherent appeal, this underscores the importance of full-chain interoperability in the eyes of top-tier capital. Setting aside its halo and controversies surrounding centralization and ecosystem flaws, let’s analyze whether Layer Zero’s architecture holds the potential to facilitate full-chain connectivity.

Trustless Cross-Chain: As mentioned earlier, the most mainstream cross-chain bridge solutions have relied purely on external verification, which significantly reduces security due to the shift of trust to off-chain verification (most of the multi-signature bridges that have been exploited share this vulnerability, as hackers only need to target the asset custody location). In contrast, LayerZero transforms the verification architecture into two independent entities — Oracles and Relayers, employing the most minimalistic approach to mitigate the flaws of external verification. Theoretically, the independence between the two should offer a completely trustless and secure cross-chain communication environment. However, the issue lies in the potential for hackers to target Oracles and Relayers for malicious activities. Furthermore, the possibility of centralized collusion between Oracles and Relayers raises concerns, suggesting that Layer Zero’s trustless cross-chain in Version 1 may have several logical gaps. Version 2 introduces Decentralized Verification Networks (DVNs) to improve the verification method, which we will discuss later.

LayerZero Endpoints: LayerZero endpoints are the key elements of the protocol’s functionality. While Version 1’s Oracles and Relayers, as well as Version 2’s DVNs, primarily handle message verification and fraud prevention, the endpoints are smart contracts that enable the actual exchange of messages between the local environments of two blockchains. Each endpoint on participating blockchains comprises four modules: Communicator, Verifier, Network, and Libraries. The first three modules enable the core functions of the protocol, while the Libraries module allows protocol developers to extend its core functionalities and add blockchain-specific custom functions. These custom libraries enable LayerZero to adapt to a diverse range of blockchains with different architectures and virtual machine environments, for instance, supporting both EVM-compatible networks and non-EVM chains.

How It Works: The core of the LayerZero communication system relies on endpoints. Through the three modules mentioned earlier, it forms the infrastructure for cross-chain message transfer. The process begins with an application on one blockchain (Chain A) sending a message, involving the transmission of transaction details, target chain identifier, payload, and payment information to the Communicator. The Communicator then compiles this information into a data packet and forwards it along with other data to the Verifier. The Verifier collaborates with the Network to initiate the transfer of Chain A’s block header to the target chain (Chain B), while directing the Relayer to pre-fetch transaction proofs to ensure authenticity. The Oracle and Relayer are responsible for retrieving the block header and transaction proofs, respectively, and then transmitting this information to the Network contract on Chain B, which passes the block hash to the Verifier. After verifying the data packet and transaction proofs provided by the Relayer, the message is forwarded to the Communicator on Chain B. Finally, the smart contract passes the message to the target application on Chain B, completing the cross-chain communication process.

In LayerZero Version 2, Oracles are replaced by Decentralized Verification Networks (DVNs) to address criticisms of off-chain entity centralization and insecurity. Simultaneously, Relayers are substituted by Executors, whose role is limited to merely executing transactions, not verifying them.

Modularity and Scalability: Developers can use the Libraries module to extend the core functions of LayerZero on blockchains. These modules are part of the protocol’s smart contract suite. Libraries allow for the implementation of new functions in a blockchain-specific manner without modifying LayerZero’s core code. The protocol is highly scalable because it uses a lightweight messaging setup for cross-chain communication.

Simple User Experience: A key feature of LayerZero is its user-friendliness. Cross-chain operations using the protocol can be conducted as a single transaction, eliminating the token wrapping and unwrapping processes typically associated with traditional crypto bridges. As a result, the user experience is akin to token exchanges or transfers on the same chain.

LayerZero Scan: Considering nearly 50 public chains and Layer 2 platforms supported by LayerZero, tracking message activity on LayerZero is no small feat. This is where LayerZero Scan comes into play. This cross-chain browser application allows you to see all protocol message exchanges on participating chains. The browser lets you view message activity by source and target chain separately. You can also explore transaction activity for each DApp using LayerZero.

OFT (Omnichain Fungible Token): The OFT (Omnichain Fungible Token) standard allows developers to create tokens with native-level functionality across multiple chains. The OFT standard involves burning tokens on one chain while minting a token replica on the target chain. Initially, the original OFT token standard could only be used with EVM-compatible chains. LayerZero expanded this standard in the latest OFTV2 version to support non-EVM platforms.

ONFT (Omnichain Non-Fungible Token): ONFT is the non-fungible version of the OFT standard. NFTs created based on the ONFT standard can be transferred and stored at a native level between chains supporting this standard.

Wormhole

Like Layer Zero, Wormhole is a part of the full-chain interoperability protocol space, beginning to make its mark during a recent airdrop event. The protocol was initially launched in October 2020 and has evolved from a bi-directional token bridge in its Version 1 to now enabling the development of native cross-chain applications that span multiple chains. The protocol is perhaps most famously known for a hacking incident on February 3, 2022, which resulted in the theft of $360 million worth of ETH. However, Wormhole managed to replenish the funds (from an undisclosed source) in less than 24 hours, and recently announced a staggering $225 million in financing. So, what makes Wormhole so appealing to capital investors?

Strategic Focus: Wormhole’s target is not primarily EVM-based systems but non-EVM systems. It is the only mainstream full-chain protocol that supports heterogeneous public chains like Solana, and the Move family (APT, SUI), among others. As these ecosystems continue to recover and explode in growth, Wormhole’s emergence as a frontrunner has become inevitable.

How It Works: At the heart of Wormhole is the Verifiable Action Approval (VAA) cross-chain protocol and 19 Guardian nodes (chosen from well-known institutions within the industry, a point often criticized). It converts requests into VAAs through the Wormhole Core Contract on each chain to facilitate cross-chain operations. The specific process is as follows:

• Event Occurrence and Message Creation: Specific events occurring on the source chain, like asset transfer requests, are captured and encapsulated into a message. This message details the event and the actions that need to be performed.
• Guardian Nodes Monitoring and Signing: The 19 Guardian nodes within the Wormhole network are responsible for monitoring cross-chain events. When they detect an event on the source chain, they validate the event information. Once validated, each Guardian node signs the message with its private key, indicating the event’s verification and approval (requiring agreement from two-thirds of the nodes).
• Verifiable Action Approval (VAA) Generation: Once a sufficient number of Guardian nodes have signed the message, these signatures are collected and packaged into a VAA. The VAA is a verifiable approval of the event and its cross-chain request, containing detailed information about the original event and proof of the Guardian nodes’ signatures.
• Cross-Chain Transmission of VAA: The VAA is then sent to the target chain. On the target chain, the Wormhole Core Contract is responsible for verifying the authenticity of the VAA. This includes checking the Guardian node signatures contained in the VAA to ensure they are from trusted nodes and that the message has not been altered.
• Execution of Cross-Chain Actions: Once the Wormhole contract on the target chain has verified the VAA’s validity, it executes the corresponding actions as directed by the VAA. This could involve creating new tokens, transferring assets, executing smart contract calls, or other custom operations. In this way, events on the source chain can trigger corresponding responses on the target chain.

>>>>> gd2md-html alert: inline image link here (to images/image4.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>

Security Module: Wormhole is developing three main internal security features: governance, accounting, and emergency shutdown, all in an open development environment to provide deep insights into their final implementations. These features are awaiting completion and adoption by guardians.

• Governance: This feature, implemented at the guardian/oracle level, allows guardians to monitor the value flow on any regulated chain within a certain time window. Guardians set acceptable flow caps for each chain, and any flow exceeding this cap is blocked to prevent excessive asset movement.
• Accounting: Implemented by guardians or oracles, they maintain their blockchain (also known as wormchain), serving as a cross-chain ledger between different chains. This ledger not only positions guardians as on-chain validators but also acts as an accounting plugin. Guardians can reject cross-chain transactions from chains with insufficient funds (this verification is independent of smart contract logic).
• Shutdown: Implemented on-chain, this feature allows guardians to temporarily halt asset flow on the bridge if a potential threat to the cross-chain bridge is detected. The current implementation is executed through on-chain function calls.

Rapid Integration: Wormhole’s Connect product offers applications a simple bridging tool that integrates Wormhole protocol’s cross-chain functionality with just a few lines of code. Connect’s primary function is to provide developers with a set of simplified integration tools, allowing them to incorporate Wormhole’s encapsulation and native asset bridging features into their applications with minimal coding. For example, an NFT marketplace wishing to bridge its NFTs from Ethereum to Solana can use Connect to provide its users with a simple, fast bridging tool within its application, enabling them to freely move their NFTs between the two chains.

Messaging: In a diverse blockchain ecosystem, messaging becomes a core requirement. Wormhole’s Messaging product offers a decentralized solution that allows different blockchain networks to securely and easily exchange information and value. The core functionality of Messaging is cross-chain information transmission, equipped with simplified integration methods to accelerate user and liquidity growth while maintaining high security and decentralization. For instance, a DeFi project running on Ethereum that wants to interact with another project on Solana can easily exchange information and value through Wormhole’s Messaging, without complicated intermediary steps or third-party intervention.

NTT Framework: The NTT (Native Token Transfers) framework through Wormhole provides an innovative and comprehensive solution for cross-blockchain transfers of native tokens and NFTs. NTT allows tokens to retain their inherent properties during the cross-chain transfer process and supports direct cross-chain token transfers without the need for liquidity pools, thereby avoiding LP fees, slippage, or MEV risks. Furthermore, it can integrate with any token contract or standard and protocol governance processes, allowing project teams to maintain ownership, upgrade permissions, and customizability of their tokens.

Conclusion

Despite being in the early stages, full-chain interoperability protocols currently face challenges in security and centralization risks, and the user experience cannot yet compete with the Web2 internet ecosystem. However, compared to the early cross-chain bridge technologies, the current solutions have made significant progress. In the long run, full-chain interoperability protocols represent a grand narrative of integrating thousands of isolated chains into a unified ecosystem. Especially in the era of pursuing extreme speed and cost-effectiveness in modularity, full-chain protocols undoubtedly play a pivotal role in bridging the past and future. They are a key area that we must pay close attention to.

Disclaimer：

1. This article is reprinted from [YBB], Forward the Original Title‘The Key to Chain-Wide Connectivity: An All-Chain Interoperability Protocol’, All copyrights belong to the original author [YBB Capital Researcher Zeke]. 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.