Ecosystem Explorer — Exploring Cross-chain Interoperability Protocols and Their Security Measures

Background

Substantial portion of Web3 protocols are deployed on Ethereum, as a strategic choice due to Ethereum’s significant capital flow and status as the blockchain with the most users.

However, Ethereum’s low performance has led to considering alternatives to improve scalability. These alternatives include Non-EVM Layer 1 chains like Solana, and Ethereum Layer 2 chains represented by Arbitrum and Optimism. These solutions have greatly enhanced the usability of the blockchain ecosystem by allowing for high-performance blockchain utilization. However, these solutions’ growing numbers and diversity are now harming interoperability. According to DefiLlama, over 200 mainnets are currently operating. Numerous independent networks run their DApps, and due to the different characteristics of each chain, compatibility is either impossible or not smooth. This leads to a “Galapagos Syndrome” of each chain’s ecosystem, where despite appearing decentralized due to the distribution of users, in reality, the population gets concentrated on chains with significant capital, resulting in a winner-takes-all phenomenon.

Interchain operability protocols have emerged to address this, aiming to enable interaction between different blockchains.

What are Interoperability Protocols?

As mentioned, interoperability protocols allow smart contracts (or programs in the case of Non-EVM) and accounts operating on different blockchains to interact.

Interoperability protocols can be implemented in two forms:

• Intermediary blockchains
• On-chain contracts + Off-chain brokers

This article analyzes the structure of currently operational interchain operability protocols and examines various security aspects they must consider.

Research Targets

• Structure of interoperability protocols: This article discusses Wormhole, LayerZero, and Axelar, which are among the interoperability protocols with the highest Total Value Locked (TVL) based on the L2BEAT’s current TVL rank. Additionally, it covers Chainlink’s Cross-Chain Interoperability Protocol (CCIP), one of the most prominent interoperability protocols.
• Security and Limitations of Interoperability Protocols: We discuss each protocol’s security features and their inherent limitations.

1. CCIP

CCIP is an interoperability protocol developed by Chainlink, a leading provider of oracle services in the blockchain ecosystem. It enables the transmission of tokens and data between EVM-compatible chains.

CCIP has a mixed structure of on-chain and off-chain components. The article details each component of CCIP and then revisits its operational structure.

Components

1) On-chain Decentralized Applications or Accounts

These on-chain contracts interact with the CCIP router, facilitating the exchange of arbitrary data or tokens.

2) Router

Each chain supported by CCIP has a router contract deployed. The router on the source chain relays commands from users or contracts to the OnRamp, the on-chain final handler, while the router on the destination chain transfers tokens or messages received from the OffRamp to recipient contracts or accounts.

3) OnRamp and OffRamp

OnRamp and OffRamp interact with CCIP’s off-chain components. OnRamp interprets commands received from the router, verifies the validity of the requested actions, and stores them for off-chain components to read. OffRamp validates data transmitted by off-chain components and conveys received messages to the router contract on the destination chain.

For token transfers, OnRamp interacts with the Token Pool on the source chain to burn or lock tokens. Correspondingly, the destination chain’s OffRamp interacts with its Token Pool to mint tokens.

4) Token Pool

When transferring tokens between chains using CCIP, the Token Pool on both the source and destination chains is used. Rather than directly transferring tokens, a message instructing the issuance of tokens is conveyed to the destination chain.

Depending on the nature of the token, methods vary between “lock & mint” and “burn & mint.” Most tokens, excluding stablecoins like USDC that can be minted across various chains, use the lock & mint method. Here, tokens are locked in the sender chain’s Token Pool, and an equivalent amount is minted for the recipient in the destination chain’s Token Pool.

5) Decentralized Oracle Network (DON)

As evident from its on-chain components, actions intended by users via CCIP are conducted through on-chain contract transactions. However, two issues must be overcome to transfer a message from the source to the destination chain.

• Firstly, transferring the message itself from the source to the destination chain. They are both based on EVM, but fundamentally different chains. An intermediary is needed as it is not natively possible to send messages directly to the destination chain.
• Secondly, maintaining the finality of each chain. Since each chain operates at different finality speeds, the intermediary must handle this properly. Protocols like CCIP, which transfer tokens, can make critical errors, like consuming tokens without transferring them if finality is not maintained. Hence, an entity capable of handling this is required.

In CCIP, DON takes on these two tasks. CCIP refers to each pair of source and destination chains as a “Lane”, with each Lane having a pair of Committing DON and Executing DON. They monitor transactions on both chains and deliver messages according to finality, bundling submitted transactions and transmitting them in rounds.

• Committing DON: Committing DON monitors events from the OnRamp contract on the source chain and reads the sender’s message. Once transactions on the source chain are finalized, Committing DON bundles transactions submitted during the round and generates a Merkle Root. A certain number of nodes are designated to sign the generated Merkle Root. Once the number of node signatures reaches a quorum, the signed Merkle Root is stored in the CommitStore contract on the destination chain.
• Executing DON: Executing DON checks whether transactions on the source chain have formed the correct Merkle Root in the CommitStore contract on the destination chain. It then verifies whether the message has been validated by the Risk Management Network described later. Executing DON verifies that the Merkle Root stored in the CommitStore contract matches the one generated by the OnRamp contract and, upon passing verification, calls the OffRamp contract to complete the user's requested action.

6) Risk Management Network

Risk Management Network operates to prevent serious security issues, such as Committing DON generating incorrect Merkle Roots or manipulating transactions. It consists of independent nodes monitoring the Merkle Root in the CommitStore contract, which is generated by Committing DON. Each node compares the submitted Merkle Root with transactions received by the OnRamp contract for verification. Upon successful verification, the node instructs the risk management contract to approve (bless) the submitted Merkle Root. It instructs the risk management contract to oppose (curse) the CCIP system if deemed abnormal. If the number of opposing votes exceeds a quorum, the risk management contract halts the entire CCIP system, preventing any CCIP transactions from being executed.

Operational Process

An overview of CCIP’s operational process.

The process of transmitting a user’s message via CCIP involves the following steps:

Step 1: The user or contract submits a token or message to the router contract through a decentralized application.

Step 2: Router forwards the received token and message to the OnRamp contract.

Step 3: OnRamp verifies the validity and gas limits of the message received from the router, assigns an order to the received message for tracking, and specifies the amount and type of gas fee to be handled on the source chain, storing this information within the contract. If a token is transferred, the OnRamp contract interacts with the Token Pool contract to lock or burn the token.

Step 4: Committing DON waits for the transaction at the OnRamp contract to be finalized, then reads the message and Merkle Root stored in the OnRamp contract.

Step 5: Each node of Risk Management Network verifies the Merkle Root’s validity stored in OnRamp. This involves comparing the submitted Merkle Root with transactions received by the OnRamp contract. If the number of approvals for the Merkle Root exceeds a quorum, the Merkle Root signed by each node is stored in the CommitStore contract on the destination chain.

Step 6: Executing DON checks whether the Merkle Root stored in the CommitStore contract contains transactions from the source chain and waits for the Risk Management Network to authenticate the Merkle Root. The Risk Management Network stores authentication for the Merkle Root in the risk management contract. Once Executing DON confirms that the Merkle Root has been authenticated, it calls the OffRamp contract on the destination chain to perform the message.

Step 7: OffRamp contract compares and verifies the Merkle Root stored in the CommitStore contract with the Merkle Root signed by the Risk Management Network, generates and stores proof for the Merkle Root, and then forwards the user's command to the router contract on the destination chain to execute the remaining actions. If a token is being transferred, OffRamp interacts with the Token Pool to mint and transfer the token.

Step 8: Router on the destination chain delivers the message and token to the destination contract or user, completing the series of actions through CCIP.

Features

• CCIP employs a unique system called the “Risk Management Network” to authenticate the validity of messages. This system expresses approvals and disapprovals as “bless” and “curse.” If the curses reach a threshold, indicating unresolved risks, the entire CCIP system is halted until the administrator confirms the risk has been mitigated. The network also monitors for serious chain reorganizations (reorgs) and duplicate message executions. To avoid a single point of failure, the system must operate on a different codebase from the Decentralized Oracle Network.
• It authenticates the Merkle Roots submitted from the source chain’s contracts using the transactions submitted by the sender.
• Only gas fees from the source chain are imposed. CCIP uses a “Smart Execution” mechanism to reduce the burden of gas fees on the destination chain, periodically updating the gas fee cache of the destination chain. Users pay only the gas fees of the source chain to use CCIP.
• In addition to the transaction processing costs on the source chain, CCIP imposes a separate fee named “premium.” If users do not pay the fee through Chainlink’s native token, $LINK, an additional 10% fee is charged. This fee covers part of the gas fees on the destination chain and a certain percentage of the cost for the tokens being transferred.

Message Validation

CCIP validates the authenticity of messages through the Risk Management Network, consisting of nodes operating in individual environments and the Off-Chain Reporting (OCR) protocol-based off-chain component, DON.

Committing DON collects the Merkle Roots stored in the OnRamp of the source chain and stores them in the CommitStore contract of the destination chain. The Risk Management Network compares the submitted transactions and Merkle Roots in the OnRamp, validating their authenticity through voting. If the Risk Management Network deems the Merkle Root abnormal, CCIP halts the entire system to prevent any transactions via its network.

The entities validating the messages are off-chain and based on the operator’s services (Chainlink), and they possess significant authority, leading to a somewhat centralized structure.

Security and Limitations

CCIP has implemented several methods to mitigate security risks that could arise from its use.

• Rate Limiting: CCIP limits the amount of tokens that can be transferred in and out per hour. This is intended to delay massive capital movements which is typical in Web3 attacks, allowing Risk Management Networks to detect and protocols to respond quickly. The token transfer limit varies for each lane (source chain-destination chain) and is calculated using the value of the tokens in USD. The calculated limits are stored in the token pools of each chain that mints and locks tokens and in the OnRamps and OffRamps that trigger events and ultimately deliver messages to recipients.
• Risk Management Network: CCIP validates the authenticity of user messages through a Risk Management Network before execution. Sender’s messages must undergo a vote for validity before execution and must meet a quorum for the user’s message to be approved. Suppose the Risk Management Network detects a wrong message or abnormal token movement. In that case, it can detect this as an anomaly and send a transaction to the risk management contracts of all chains, stopping the entire CCIP system. CCIP calls this process Secondary Approval and Anomaly Detection.

Chainlink claims that CCIP’s Risk Management Network was developed by a “different team” within Chainlink, with a codebase in different languages, making it highly independent within CCIP. However, as it is a system operated by Chainlink and runs privately off-chain, it seems difficult to supervise or control the Risk Management Network. The authority of Risk Management Network is powerful, so thorough authority management and third-party supervision appear necessary.

2. LayerZero

LayerZero is an interoperability protocol that operates as a trustless messaging protocol. LayerZero supports all types of chains structurally.

LayerZero, like CCIP, combines both on-chain and off-chain elements but has fundamental conceptual differences.

Components

1) User Applications

This refers to all contracts deployed on chains supported by LayerZero.

2) LayerZero Endpoint

Each chain supported by LayerZero has a LayerZero Endpoint, allowing user applications to interact. These are on-chain smart contracts that serve as the backend for the protocol.

These consist of four modules: Communicator, Validator, Network, and Library. The first three are core functions of the LayerZero endpoint, while the Library supports the inclusion of new chains without changing the core modules.

• Communicator: This module interacts with user applications. It creates packets containing data and destination from user applications and delivers them to Validators, or receives packets from Validators and delivers them to user applications.
• Validator: The Validator on the source chain delivers packets to Relayers and transmits the transaction’s destination to the Network module. On the destination chain, it receives block hashes from the source chain’s Relayers and proofs about the transaction.
• Network: On the source chain, this module transmits the block ID to the Oracle, and on the destination chain, it receives the block header from the Oracle and delivers it to the Validator.
• Library: This additional contract dictates how messaging should be processed on specific chains, helping new chains be easily included. Each LayerZero endpoint should include a copy of all libraries for smooth inter-chain operations. Currently, LayerZero only supports one library, the UltraLightNodeV2.

3) Oracle

Oracles are off-chain components that operate individually for LayerZero’s services. They send block headers from the source chain to the destination chain. Oracles supporting LayerZero include Chainlink and Google Cloud. User applications can implement their Oracles or designate others.

4) Relayer

Similar to Oracles, Relayers are off-chain components that operate individually for LayerZero services. They play a role in obtaining proofs for user transactions. While LayerZero provides its Relayers, user applications can designate their own.

Operational Process

An overview of LayerZero’s operational process.

The process of delivering messages between chains in LayerZero is as follows:

Step 1: An application on the source chain submits a transaction, sending a messaging request to the Communicator. A messaging request includes several information:

• Transaction identifier, or transaction hash.
• Destination contract on the destination chain.
• Payload that the user applications append.
• Parameters for the Relayer, such as fees.

Step 2: Communicator on the source chain creates a packet based on the received information, which includes the destination contract identifier (address) and payload. The packet, along with the rest of the parameters received from the application, is then sent to the Validator.

Step 3: Validator on the source chain parses the received packet to obtain the destination contract address and transmits this along with the transaction hash to the Network module. This informs the Network module that the block header from the source chain needs to be sent to the destination chain. Simultaneously, the Validator sends all the received parameters (packet, transaction hash, Relayer parameters) to the Relayer, indicating that the transaction proof from the source chain’s application must be ultimately delivered to the destination chain.

Step 4: Network module on the source chain transmits the destination contract identifier and the block ID of the source chain to the Oracle. This informs the Oracle that it needs to send the block header of the source chain to the destination chain.

Step 5: Oracle reads the block header from the source chain. At the same time, the Relayer retrieves the transaction proof from the source chain’s user application and stores it off-chain.

Step 6: After confirming that the block corresponding to the block header is finalized, Oracle transmits the block header to the Network module of the destination chain.

Step 7: Network module on the destination chain delivers the block hash from the source chain to the Validator.

Step 8: Validator on the destination chain forwards the block hash from the source chain to the Relayer.

Step 9: Upon receiving the block hash from the Validator, the Relayer transmits a list of tuples (packet, transaction identifier, transaction proof) that match the block from the source chain. If multiple users send messages from the same endpoint simultaneously, the same block will contain many packets and associated transaction proofs.

Step 10: The Validator on the destination chain uses the transaction proof and the block header stored by the Network module from the source chain to verify the transaction’s validity. If the validation fails, the message is canceled. If it succeeds, the packet containing the destination contract identifier and payload is delivered to the Communicator and ultimately executes the operation in the destination chain’s user application.

Features

• In theory, LayerZero can support all chains. Reliance to the off-chain components makes this possible, as Oracles and Relayers interact with the smart contracts or programs of the source and destination chains.
• LayerZero supports tokens that can freely move across all chains, such as OFT (Omnichain Fungible Token) and ONFT (Omnichain Non-Fungible Token). Existing tokens can also be moved to other chains through ProxyOFT. In this case, the original token will be minted in a form that can be used in the environment of the destination chain.

Message Validation

LayerZero relies on independent off-chain components, Relayers and Oracles, to validate the authenticity of messages. Relayers fetch proof of message submission transactions from the source chain, while Oracles deliver the block headers from the source chain to the destination chain. Validators on the destination chain then verify the transaction’s validity based on this information.

Although LayerZero has a relatively simple process and components for validating authenticity, it entrusts the judgment of message validity to individual off-chain components. Unlike CCIP, both Relayers and Oracles in LayerZero can be designated and developed by users. This burdens the application users to assess whether they can trust the Relayers and Oracles used in the LayerZero process.

Security and Limitations

The security features provided by LayerZero are as follows:

• Independent Oracle and Relayer Configuration: User Applications can set different Oracles and Relayers, including ones they developed, thus distributing structural risks at the application level. LayerZero assumes that Oracles and Relayers are independent entities, excluding collusion scenarios from its protection scope.
• Pre-Crime Detection: A system to block hacking attempts in advance. Relayers fork the destination blockchain before delivering messages and executing transactions locally. They then verify the state of the blockchain by linking it with other chains and checking for malicious actions. The user application defines whether an action is malicious, forcing Relayers to detect it compulsorily.

LayerZero has a relatively simple structure compared to other interoperability protocols, likely due to the concentrated structural risks in Oracles and Relayers. Allowing each protocol to designate different Oracles and Relayers certainly distributes risks and damages, but this does not negate the potential for attacks. Similarly, if a user application with malicious intent designates a malicious Oracle and Relayer, the pre-crime detection feature can still expose users to risk.

Suppose malicious Oracles and Relayers collude to submit arbitrary block headers and transaction proofs. In that case, they can execute attacks to intercept assets users are bridging, as experimented in L2BEAT’s previous article.

In conclusion, users of applications based on LayerZero need to analyze which Relayers and Oracles the application uses meticulously, as the protcol shifts a part of its burden on security to the user side.

3. Wormhole

Wormhole, similar to LayerZero, aims to be a message transmission protocol for all chains.

Components

1) Emitter

Simply put, the user application contract of the source chain submits the user’s message to the Wormhole core contract.

Emitter can exist in various forms of contracts:

• xAsset Contract: Converts a regular token into an xAsset that can be bridged.
• Relay Contract: Performs allowing the application to deliver messages to a Decentralized Generic Relayer Network.
• Worm Router Contract: Executes operations that allow the user to interact with the chain through client-side code only.

2) Wormhole Core Contract

This is the contract on the source chain that submits messages, initiating inter-chain communication.

3) Transaction Log

Responsible for maintaining individual records on each chain, it stores messages generated by the Wormhole core contract, allowing the Guardian Network to observe them.

4) Guardian Network

Guardian Network is an off-chain component which acts as a validator for messages. The Guardian Network verifies the validity of messages produced by the core contracts on each supported chain, signs them, and creates Verified Action Approvals (VAA). Comprising 19 guardians (validators), each contributes to creating a multi-signature VAA by verifying and signing the VAA.

The Guardian Network consists of enterprise-level validators who monitor blockchain operations. Besides being a validator for Wormhole, each guardian must also operate nodes for all chains supported by Wormhole. They monitor the consensus processes of the chains and have the authority to disconnect the network from Wormhole if block consensus is not properly achieved. They also need to monitor token circulation changes through contract-level data monitoring continually.

• Gateway: Internally, Guardian Network operates a Cosmos-based blockchain called Gateway. They maintain the latest state values for all chains supported by Wormhole and assist in efficiently executing contracts using these values.

5) Spy

An off-chain daemon that tracks messages submitted to the Guardian Network, enhancing the scalability of VAA distribution by observing the network’s traffic.

6) Relayer

An off-chain component that delivers (relays) the VAA to the destination chain, its form is not specifically defined. There are three methods of VAA delivery: client-side delivery, delivery using a specified Relayer, and delivery using an automatic Relayer.

• Client-Side Delivery: Involves completing the inter-chain process directly through the user’s front-end. While it’s cost-effective and doesn’t require backend infrastructure, a downside is that users must sign the transaction and bear the transaction fees.
• Delivery Using a Specified Relayer: Involves Relayers that process VAAs for specific protocols or applications. They execute user-defined logic off-chain to improve inter-chain compatibility and optimize gas consumption. However, application developers face the burden of developing and hosting their Relayer.
• Delivery Using an Automatic Relayer: This method uses the delivery contract included in Wormhole’s components to relay messages requested on-chain. It spares applications from operating a Relayer and is cost-effective, but user-defined operations are limited.

Operational Process

An overview of Wormhole’s operational process.

The process of delivering messages between chains in Wormhole is as follows:

Step 1: Emitter submits a message to the Wormhole core contract. This message may include a transaction nonce, payload, and information about the destination chain.

Step 2: The message submitted by Emitter triggers an event in the Wormhole core contract. This event is stored in the transaction log contract of the source chain, with the Emitter and the message’s sequence number.

Step 3: The off-chain Guardian Network observes events stored in the transaction log contract and verifies the validity of the user-submitted messages. Each guardian of the Guardian Network operates nodes for all chains supported by Wormhole, enabling them to assess the validity of messages from the source chain easily.

Step 4: Once the message on the source chain is finalized, each guardian signs the message’s payload they deem valid. These signed payloads are combined to create a multi-signature-based VAA (Verified Action Approval).

Step 5: Guardian Network transmits the VAA to a REST API or Spy, which is then passed on to a Relayer.

Step 6: Upon receiving information from the REST API or Spy, the Relayer sends a transaction to the destination chain that calls the destination contract and the VAA. The Relayer must make its best effort to deliver the VAA properly.

Step 7: The destination contract, called by the Relayer’s transaction, receives the VAA and has it verified by the Wormhole core contract located on the destination chain. The destination contract then executes various actions as intended by the sender through the message.

Features

• Wormhole relies on the trustworthiness of transactions governed by the off-chain Guardian governance.
• It does not guarantee the normal operation of Relayers. Therefore, if users do not use the default provided Relayer, the proper processing of transactions depends solely on the user’s trust in the Relayer.
• Similar to CCIP, if abnormal operations such as improper block consensus are detected, the Guardian Network will disconnect from the affected network.
• Guardian Network must operate full nodes for all chains supported by Wormhole.

Message Validation

Wormhole verifies and signs the validity of messages based on the consensus of individual validators located off-chain. Guardians observe events from core contracts located on each chain and verify the event’s validity using the full nodes of the source chain they operate. A signed message is created after a quorum of guardians votes, guaranteeing the transaction’s validity.

Security and Limitations

Wormhole’s security features include:

• Guardian Network: Wormhole guarantees the authenticity of messages through a network of guardians who reach consensus. The governance members comprise enterprise-level validators with significant capital and operate through governance. Each guardian operates full nodes for all chains supported by Wormhole, allowing them to easily detect and disconnect support for chains with serious reorgs or consensus issues. Guardians also monitor data from special contracts within each supported chain, continuously observing the movement and circulation of tokens.
• Asset Layer Protection: Wormhole provides two additional protective measures for token movement. One is the governor, who tracks deposits and withdrawals across all supported chains and delays suspicious fund transfers that may result from attacks. The other is the global accountant, tracking the total circulation of assets moving through Wormhole across all chains to prevent bridging that violates supply limits.

Wormhole primarily entrusts the verification of message authenticity to the Guardian Network, making its safe operation a top priority. Even though the members of the Guardian Network are selected enterprise-level validators, relying on just 19 validators for the entire system’s safety can be seen insufficient. Wormhole has outlined plans in its official documents during the design process to improve this by introducing zero-knowledge proofs and incorporating more guardians.

Wormhole, similar to LayerZero, partially shifts security responsibilities to users. Wormhole delegates the delivery of messages signed by the Guardian Network to Relayers, allowing user applications to implement and use their Relayers. Thus, user applications can intentionally disrupt the normal operation of senders through their designated Relayers or inadvertently execute arbitrary actions due to bugs. Therefore, like LayerZero, Wormhole users need to check which Relayers an application uses or place full trust in the application.

4. Axelar

Axelar is a unique interoperability protocol that, unlike others that blend on-chain and off-chain elements, adopts a blockchain structure based on Delegated Proof of Stake (DPoS), similar to Cosmos. It employs this blockchain-based structure to implement inter-blockchain communication through a Cross-chain Gateway Protocol (CGP), akin to Web2 communication techniques.

Axelar Chain

Axelar stands out from other interoperability protocols by being a blockchain itself. It operates on a DPoS consensus mechanism with validators whose influence is weighted based on the amount of the native token $AXL they are delegated. Validators must meet a threshold commonly set at 2/3 (~0.666…) to finalize blocks or sign chain-interaction requests. They hold a key share proportional to their stake, enabling them to sign user requests. The validation is multi-signature-based, meaning only those with a combined key share exceeding the threshold are considered valid.

Validators must operate light nodes for all supported chains, which, despite its cost, benefits them indirectly as the Axelar chain expands, attracting more liquidity and stake in $AXL.

User messages validated by the validators are transferred through a component called Gateway, deployed on each supported chain. The transfer of messages through this component constitutes the Cross-chain Gateway Protocol.

Components

The CGP is inspired by the traditional Broadcasting Gateway Protocol (BGP) and aims to transfer state values from the source chain to the destination chain. Its elements are as follows.

1) Gateway

The first point of interaction for users on the source chain. Each supported chain has one Gateway contract (or program). The source chain’s Gateway transmits the user’s message to Axelar’s validators, and the destination chain’s Gateway executes the received message, completing the inter-chain interaction. Keys owned by Axelar validators control gateways.

2) Relayer

Relayers assist in the smooth processing of messages in the Axelar network. They initiate voting for message verification or provide monitoring addresses to validators. Relayers operate freely, and anyone can independently run their own.

3) Axelar Validators

Validators verify the validity of messages collected by Relayers and submitted to the Axelar network. They use their nodes to assess message validity and vote accordingly.

4) Gas Receiver

A smart contract deployed on EVM-compatible chains covers the gas costs incurred during interchain message transmission. It measures the gas used and charges it to the source chain in its native token.

Operational Process

An overview of Axelar’s operational process.

The process of message transmission across chains in Axelar CGP is as follows:

Step 1: The user application on the source chain submits a message to the Gateway.

Step 2: The source chain’s Gateway generates an event based on the user’s message.

Step 3: Validators monitor events from the Gateway using their node endpoints and collect event-triggering messages with the help of Relayers.

Step 4: Validators individually verify messages. They query the source chain’s API for information about the message and report the results to the Axelar chain.

Step 5: Validators can vote every round (block), using their key share to authenticate the message’s validity.

Step 6: A multi-signature signed message is created after the round if the key shares exceed the threshold. Only verified events are transmitted to the destination and recorded in the block. These signed messages wait in a queue for delivery to the Gateway connected to the destination chain.

Step 7: The signed message waits in the queue and is included in a block 11 blocks after creation. This timing ensures robustness in the multi-signature process and accommodates key updates or new key generation among validators.

Step 8: A validator transmits the signed result to the destination chain’s Gateway.

Step 9: The destination chain’s Gateway delivers the message to the destination contract or account, completing the message transmission.

Features

• Unlike other interoperability protocols, Axelar is a blockchain with a native token.
• It verifies message validity based on validators delegated with its native token.

Message Validation

Axelar implements inter-chain communication using a blockchain as an intermediary, ensuring message validity based on its block validity. The message validation process for users mirrors the blockchain’s transaction verification. With its DPoS-based consensus algorithm, each validator has voting rights proportional to their delegated tokens. Validators exercise these rights each round to vote on message validity.

Security and Limitations

As a blockchain-operated protocol, Axelar’s chain legitimacy guarantees message validity. Beyond the validity assured by validators, Axelar provides several security mechanisms:

• Validators: Create multi-signature-based messages by holding key shares proportional to delegated stakes. Validators operate light nodes for all supported chains, verifying message validity based on results queried from their endpoints.
• Quadratic Voting System: Designed to supplement the Delegated Proof of Stake system, this requires exponentially increasing stakes to exercise voting rights, significantly raising the cost for attackers intending to seize chain control.
• Send/Receive Thresholds: Similar to CCIP’s introduction, Axelar limits the amount of assets sent or received on the chain within a certain timeframe. While primarily offering messaging functions, Axelar supports inter-chain transfers of certain assets like USDC, FRAX, and ETH via locking/issuing mechanisms, applying these thresholds.
• Key Rotation Structure: Validators’ key shares, crucial for validating messages, are cyclically rotated for security. This prevents attackers from sequentially compromising validators to take over the chain.

Axelar’s security relies on its blockchain, making honest operation by validators crucial. Unlike Wormhole’s Guardian Network, Axelar allows open participation in its validator set. Preventing malicious validators from accumulating significant stakes is essential. As of November 2023, the stake distribution among Axelar’s validators is relatively even, and acquiring unstaked shares for an attack is prohibitively expensive, contributing to stable operation.

However, users should be aware that if Axelar chain malfunctions or halts, there’s a risk of being unable to recover funds, and users engaging with the protocol should be aware of this. Additionally, the possibility of major validators being compromised cannot be eliminated.

Conclusion

We are happy to publish the first article for Ecosystem Explorer, a new section for ChainLight Blog & Research! For this article, we have compiled an analysis and explored security perspectives of interoperability protocols with different structures. Interoperability protocols, by their nature, inevitably involve centralized entities, which is an inherent limitation. Fortunately, we were able to observe each project’s endeavors to handle this issue.

Open-ended Question

Can we completely solve the centralization issue from “interoperable blockchain nature”? If not, is interoperability really the ultimate direction that blockchain should pursue?

Reference

• https://docs.chain.link/ccip
• https://layerzero.gitbook.io/docs/technical-reference/mainnet/supported-chain-ids
• https://docs.wormhole.com/
• https://axelar.network/how-axelar-works
• https://blog.chain.link/ccip-risk-management-network/
• https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf
• https://defillama.com/bridges
• https://github.com/LayerZero-Labs/Audits/tree/main/audits
• https://blog.li.fi/layerzero-a-deep-dive-6a46555967f5
• https://medium.com/layerzero-official/introducing-pre-crime-49bef4a581d5
• https://l2beat.com/bridges/projects/omnichain
• https://medium.com/l2beat/circumventing-layer-zero-5e9f652a5d3e
• https://twitter.com/ryanzarick/status/1567511186882830337?s=20
• https://github.com/wormhole-foundation/wormhole/blob/main/SECURITY.md#3rd-party-security-audits
• https://extropy-io.medium.com/solanas-wormhole-hack-post-mortem-analysis-3b68b9e88e13
• https://axelar.network/axelar_whitepaper.pdf
• https://github.com/axelarnetwork/audits

About ChainLight

Patch Thursday is ChainLight’s weekly report introducing and analyzing vulnerabilities discovered and reported by our award-winning security researchers. With the mission to assist security researchers and developers in collectively learning, growing, and contributing to making Web3 a safer place, we release our report every week, free of charge.

To receive the latest research and reports conducted by award-winning experts:

👉 Subscribe to our newsletter

👉 Follow @ChainLight_io

Established in 2016, ChainLight’s award-winning experts provide tailored security solutions to fortify your smart contract and help you thrive on the blockchain.