Full-Chain Interoperability Protocol

Forward the Original Title：万链互联的关键：全链互操作性协议

Preface

Since the beginning, blockchain has been full of conflicts. It started as a simple “electronic payment system” idea, then grew into concepts like a “world computer,” “fast processing,” and “chains for games/finance.” These different ideas and technical differences led to the creation of hundreds of different blockchains. Because of its decentralized nature, blockchain is like a closed-off island, unable to connect or communicate with the outside world. Nowadays, the main story of blockchains is moving towards having many layers. Besides the basic layer where things happen (Layer 2), there are also layers for other things like data and settling transactions. This complexity makes it harder for users, and traditional solutions for moving assets between blockchains have a lot of risks.

For regular users, moving assets between blockchains using bridges is already complicated and slow. On top of that, there are risks like incompatible assets, hackers, high fees, and not enough money on the other chain. This lack of connection between chains makes it hard for blockchains to be widely used and makes them seem more like separate countries. And while blockchains deal with these issues, there are also endless debates about which solutions are best. With blockchains getting more complicated and more popular, the old ways of connecting them aren’t good enough anymore. We need new ways to make everything work together. How far along are we in making this happen? And how far are we from having a billion users on blockchains?

What is Full-Chain Interoperability?

In the traditional internet, we can hardly feel the fragmentation in user experience. For example, in payment scenarios, we can use Alipay or WeChat to complete payments on various websites. However, in the world of Web3, there are inherent barriers between public chains. The full-chain interoperability protocol, in simple terms, is a hammer to break down these barriers. It achieves seamless transfer of assets and information between multiple public chains through cross-chain communication solutions. Its goal is to achieve a seamless experience close to the Web2 level mentioned earlier, and ultimately achieve the ultimate goal of chain-agnostic or even Intent-Centric experiences.

The implementation of full-chain interoperability involves several key challenges, including communication between heterogeneous smart contract chains and the transfer of cross-chain assets without the use of wrapping methods. To address these challenges, some projects and protocols have proposed innovative solutions such as LayerZero and Wormhole. We will analyze these projects further in the following sections. But before that, we need to understand the specific differences between full-chain and cross-chain bridges, as well as some of the challenges with cross-chain and current cross-chain methods.

What has changed across the chain?

Unlike in the past, where assets were transferred through third-party bridges requiring users to lock assets on the source chain and pay gas fees, then wait patiently to receive a wrapped asset on the target chain, full-chain interoperability protocol is a new paradigm extended from cross-chain technology. It acts as a communication hub, transmitting everything including assets through information exchange. This enables interoperability between chains, as exemplified by Stargate-integrated Sushi, where seamless asset exchanges between source and target chains can be achieved within Sushi. This maximizes user experience in cross-chain transactions. In the future, even more extravagant use cases could involve seamless interoperability between different DApps on different chains.

Triangle Selection and Three Types of Verification

In the world of blockchain, there are always choices to be made, just like the most famous public chain “trilemma”. Similarly, there exists an interoperability trilemma for cross-chain solutions. Due to technological and security limitations, cross-chain protocols can only optimize two of the following three key attributes:

1. Trustlessness: The protocol does not rely on any centralized trust entity, providing security levels similar to the underlying blockchain. Users and participants can ensure the security and proper execution of transactions without trusting any intermediaries or third parties.

2. Extensibility: The protocol can easily adapt to any blockchain platform or network, regardless of specific technical architecture or rules. This allows interoperability solutions to support a wide range of blockchain ecosystems, not just specific networks.

3. Generalizability: The protocol can handle any type of cross-domain data or asset transfer, not limited to specific transaction types or assets. This means that different blockchains can exchange various types of information and values, including but not limited to cryptocurrencies, smart contract calls, and other arbitrary data.

Early cross-chain bridges were generally divided according to Vitalik Buterin’s classification into three types of cross-chain technologies: Hash Time Lock, Witness Verification, and Relay Verification (Light Client Verification). However, according to Arjun Bhuptani, the founder of Connext, cross-chain solutions can also be divided into Natively Verified (Trustlessness + Extensibility), Externally Verified (Extensibility + Generalizability), and Locally Verified (Trustlessness + Generalizability). These verification methods are based on different trust models and technological implementations to meet various security and interoperability requirements.

Natively Verified:

● Natively verified bridges rely on the consensus mechanisms of the source and target chains to directly verify the validity of transactions. This method does not require additional verification layers or intermediaries. For example, some bridges may use smart contracts to create verification logic directly between two blockchains, allowing these chains to confirm transactions through their own consensus mechanisms. While this approach increases security by relying on the inherent security mechanisms of the participating chains, it may be more complex in technical implementation and not all blockchains support direct native verification.

Externally Verified:

● Externally verified bridges use third-party validators or validator clusters to confirm the validity of transactions. These validators may be independent nodes, consortium members, or other forms of participants operating outside the source and target chains. This approach typically involves cross-chain messaging and verification logic executed by external entities rather than directly processed by the participating blockchains themselves. External verification allows for wider interoperability and flexibility, as it is not limited by specific chains, but it also introduces additional layers of trust and potential security risks.

Locally Verified:

● Locally verified bridges refer to verifying the state of the source chain on the target chain in cross-chain interactions to confirm transactions and execute subsequent transactions locally. The typical approach is to run a light client on the source chain in the virtual machine of the target chain, or run both in parallel. Native verification requires an honest minority or synchronous assumption, with at least one honest relay in the committee (i.e., an honest minority), or if the committee cannot function properly, users must transmit transactions themselves (i.e., a synchronous assumption). Native verification is the most trust-minimized form of cross-chain communication, but it also comes with high costs, low development flexibility, and is more suitable for blockchains with high similarity in state machines, such as between Ethereum and L2 networks, or between blockchains developed based on the Cosmos SDK.

Different Types of Solutions

As one of the most crucial infrastructures in the Web3 world, the design of cross-chain solutions has always been a tricky issue, resulting in various types of solutions emerging. From the current perspective, these solutions can be classified into five categories, each employing unique methods to facilitate asset exchange, transfer, and contract invocation. [1]

●Token Swap:

Allows users to trade a certain asset on one blockchain and receive an equivalent asset on another chain. Liquidity pools can be created on different chains using techniques like atomic swaps and Automated Market Makers (AMMs) to facilitate the exchange of different assets.

●Asset Bridge:This method involves locking or destroying assets via smart contracts on the source chain and unlocking or creating new assets on the target chain through corresponding smart contracts. This technology can be further categorized based on how assets are processed:

○ Lock/Mint Model: Assets on the source chain are locked, and equivalent “bridged assets” are minted on the target chain. Conversely, when reversing the operation, bridged assets on the target chain are destroyed to unlock the original assets on the source chain.

○ Burn/Mint Model: Assets on the source chain are burned, and an equivalent amount of the same asset is minted on the target chain.

○ Lock/Unlock Model: Involves locking assets on the source chain and then unlocking equivalent assets in liquidity pools on the target chain. These types of asset bridges often attract liquidity by providing incentives such as revenue sharing.

●Native Payments: Allows applications on the source chain to trigger payment operations using native assets on the target chain. Cross-chain payments can also be triggered based on data from one chain on another chain. This method is primarily used for settlement and can be based on blockchain data or external events.

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

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

Layer Zero

Layer Zero, as one of the most famous projects in the world of full-chain interoperability protocols, has attracted significant attention from top-tier crypto capital firms such as a16z, Sequoia Capital, Coinbase Ventures, Binance Labs, and Multicoin Capital, raising a whopping total of $315 million in three rounds of financing. Apart from the project’s inherent appeal, it’s evident that the full-chain sector holds a crucial position in the eyes of top-tier investors. Setting aside these accolades and biases, let’s analyze whether Layer Zero’s architecture has the potential to bridge the entire chain.

Trustless Cross-Chain Communication: As mentioned earlier, the mainstream cross-chain bridge solutions have typically utilized pure external validation. However, due to the trust being shifted to off-chain validation, security is greatly compromised (many multi-signature bridges have failed due to this reason, as hackers only need to target where the assets are kept). In contrast, Layer Zero transforms the validation architecture into two independent entities - the oracle and the relay - to address the shortcomings of external validation in the simplest manner possible. The independence between the two should theoretically provide a completely trustless and secure cross-chain communication environment. However, the issue arises as hackers can still target oracles and relays for malicious activities. Moreover, there is also the possibility of collusion between oracles and relays. Therefore, Layer Zero’s so-called trustless cross-chain communication in the V1 version seems to still have many logical flaws. However, in the V2 version, the introduction of Decentralized Validation Networks (DVNs) aims to improve the validation method, which we will discuss later.

Layer Zero Endpoints: Layer Zero endpoints are critical elements of the entire protocol functionality. Although in V1, oracles and relays, and in V2, DVNs, are mainly responsible for message validation and anti-fraud measures, endpoints are smart contracts enabling actual message exchange between the local environments of two blockchains. Each endpoint on participating blockchains consists of four modules: Communicator, Validator, Network, and Libraries. The first three modules enable the core functionality of the protocol, while the Libraries module allows developers to extend the core functionality and add blockchain-specific custom functions. These custom libraries allow Layer Zero to adapt to diverse blockchains with different architectures and virtual machine environments. For example, Layer Zero can support both EVM-compatible and non-EVM chains.

Operation Principles: Layer Zero’s communication system core relies on endpoints, which, through the first three modules mentioned above, form the basic infrastructure for cross-chain message passing. The process starts with an application on one blockchain (Chain A) sending a message, involving the transmission of transaction details, target chain identifiers, payloads, and payment information to the communicator. The communicator compiles this information into a packet and forwards it, along with other data, to the validator. At this point, the validator collaborates with the network to initiate the transfer of Chain A’s block headers to the target chain (Chain B), while instructing the relay to pre-fetch transaction proofs to ensure transaction authenticity. Oracles and relays are responsible for retrieving block headers and transaction proofs, which are then transferred to Chain B’s Network contract, which passes the block hash to the validator. After verifying that the relay-provided packet and transaction proofs are correct, the validator forwards the message to Chain B’s communicator. Finally, the smart contract passes the message to the target application on Chain B, completing the entire cross-chain communication process.

In Layer Zero V2, oracles will be replaced by Decentralized Validation Networks (DVNs), addressing the criticized issues of centralized off-chain entities and insecurity. Meanwhile, relays will be replaced by executors, whose role is limited to transaction execution only, without being responsible for validation.

Modularity and Scalability: Developers can extend Layer Zero’s core functionality on blockchains using the Libraries module, which is part of the protocol’s smart contract set. Libraries allow the implementation of new features in blockchain-specific ways without modifying the Layer Zero core code. The protocol is highly scalable as it uses lightweight message settings for cross-chain communication.

Simple User Experience: A key feature of Layer Zero is its user-friendliness. When using the protocol for cross-chain operations, transactions can be conducted as a single transaction, without the token wrapping and unwrapping procedures typically associated with traditional crypto bridge asset transfers. Therefore, the user experience is similar to token exchanges or transfers on the same chain.

Layer Zero Scan: Given that Layer Zero supports nearly 50 public chains and Layer 2 solutions, tracking message activities on Layer Zero is not easy. This is where Layer Zero Scan comes in handy. This cross-chain browser application allows users to see all protocol message exchanges on participating chains. The browser allows users to view message activity by source chain and target chain separately. Users can also explore transaction activities for each DApp using Layer Zero.

Omnichain Fungible Tokens (OFT): The OFT (Omnichain Fungible Token) standard enables developers to create tokens with native-level functionality across multiple chains. The OFT standard involves burning tokens on one chain while minting a token copy on the target chain. Initially, the original OFT token standard could only be used with EVM-compatible chains. Layer Zero has extended this standard

Wormhole

Like Layer Zero, Wormhole is a participant in the full-chain protocol race and has recently begun to show its potential in airdrop activities. The protocol was initially launched in October 2020 and has transitioned from its V1 version of a bidirectional token bridge to building native cross-chain applications covering multiple chains. One of the most notable events in the early days of the protocol was a hacking incident on February 3, 2022, where Wormhole suffered an attack resulting in the theft of $360 million worth of ETH. However, Wormhole managed to recover the funds in less than 24 hours (source unknown), and more recently announced a whopping $225 million financing round. So what magic does Wormhole possess to attract such favor from capital.

Precision Targeting: Wormhole’s target is not primarily focused on EVM-based chains but rather on non-EVM ones. Wormhole is the only mainstream full-chain protocol that supports heterogeneous chains such as Solana and Move-based chains (APT, SUI). With the continuous growth and surge of these ecosystems, Wormhole’s prominence becomes inevitable.

Operation Principle: The core of Wormhole is the Verifiable Action Approval (VAA) cross-chain protocol and 19 Guardian nodes (Wormhole selects well-known institutions as guardian nodes, which has often been criticized). It converts requests into VAAs for cross-chain completion through the Wormhole Core Contract on each chain. The specific process is as follows:

1. Event Occurrence and Message Creation: Specific events occurring on the source chain (such as asset transfer requests) are captured and encapsulated into a message. This message details the event and the operation to be executed.

2. Guardian Node Monitoring and Signing: The 19 Guardian nodes in the Wormhole network are responsible for monitoring cross-chain events. When these nodes detect an event on the source chain, they verify the event information. Once verified, each Guardian node signs the message with its private key, indicating validation and approval of the event (requiring agreement from two-thirds of the nodes).

3. Generation of Verifiable Action Approval (VAA): Once a sufficient number of Guardian nodes sign the message, the signatures are collected and packaged into a VAA. The VAA is a verifiable approval of the occurred event and its cross-chain request, containing detailed information about the original event and signatures from Guardian nodes.

4. Cross-Chain Transmission of VAA: The VAA is then sent to the target chain. On the target chain, the Wormhole Core Contract verifies the authenticity of the VAA. This includes checking the Guardian node signatures in the VAA to ensure they were generated by trusted nodes and that the message has not been tampered with.

5. Execution of Cross-Chain Operations: Once the Wormhole contract on the target chain verifies the validity of the VAA, it executes the corresponding operation based on the instructions in the VAA. This may include creating new tokens, transferring assets, executing smart contract calls, or other custom operations. In this way, events on the source chain can trigger corresponding reactions on the target chain.

Security module:Wormhole is developing three main internal security features: supervision, accounting, and emergency shutdown, all in a public environment to provide insight into how they will ultimately be implemented. These features are awaiting completion of development and adoption by guardians. [2]

1. Supervision: This function is implemented at the guardian/oracle level, allowing the guardian to monitor the value flow on any regulated chain within a certain time window. The guardian sets an acceptable flow limit for each chain. Once this limit is exceeded, excess asset flow will be blocked;

2. Accounting: This function is implemented by guardians or oracles, which maintain their own blockchain (also known as wormchain) as a cross-chain ledger between different chains. This ledger not only makes the guardian an on-chain validator, but also acts as an accounting plug-in. The guardian can reject cross-chain transactions where the original chain has insufficient funds (this verification is independent of the smart contract logic);

3. Shutdown: This function is implemented on the chain and allows the guardian to suspend the flow of assets on the bridge through consensus when it detects a potential threat to the cross-chain bridge. The current implementation is implemented through on-chain function calls.

Quick integration: Wormhole’s Connect product provides a simple bridging tool for applications that can integrate the Wormhole protocol to achieve cross-chain functionality with just a few lines of code. The main function of Connect is to provide developers with a set of simplified integration tools, allowing developers to integrate Wormhole’s encapsulation and native asset bridging functions into their own applications with just a few lines of code. For example, an NFT marketplace wanted to bridge its NFTs from Ethereum to Solana. Using Connect, the marketplace can provide its users with a simple, fast bridging tool within its app, allowing them to freely move their NFTs between the two chains.

Messaging：In a diverse blockchain ecosystem, messaging has become a core requirement. Wormhole’s Messaging product provides a decentralized solution that allows different blockchain networks to safely and easily exchange information and value. The core function of Messaging is cross-chain information transfer, and it is equipped with a simplified integration method to accelerate the growth of users and liquidity, and has a high degree of security and decentralization. For example, let’s say a DeFi project runs on Ethereum but wants to be able to interact with another project on Solana. Through Wormhole’s Messaging, the two projects can easily exchange information and value without complex intermediary steps or third-party intervention.

NTT framework: NTT Framework (Native Token Transfers) provides an innovative and comprehensive solution for transferring native tokens and NFTs across blockchains through Wormhole. NTT allows tokens to retain their inherent properties during cross-chain transfers, and supports direct cross-chain transfer of tokens without going through a liquidity pool, thus avoiding LP fees, slippage or MEV risks. In addition to integration with any token contract or standard and protocol governance process, project teams can maintain ownership, upgrade rights, and customizability of their tokens.

Conclusion

Although full-chain interoperability protocols are still in the early stages and face risks of security and centralization in the overall implementation process, the user experience also cannot compare to the Web2 internet ecosystem. However, compared to early cross-chain bridge technologies, current solutions have made significant progress. In the long run, full-chain interoperability protocols represent a grand narrative of integrating thousands of isolated chains. Especially in the modular era where extreme speed and cost-effectiveness are pursued, full-chain protocols undoubtedly play a crucial role in bridging the past and future and are a race track that we must focus on.

Disclaimer：

1. This article is reprinted from [TechFlow Deep Wave]. *Forward the Original Title‘万链互联的关键：全链互操作性协议’.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.