Cross-chain Protocol

Research
1

Chainlink Cross-chain Interoperability Protocol

Chainlink has launched CCIP(Chainlink Cross-chain Interoperability Protocol) on the mainnet, which aims to provide a simplified interface for dApps and web3 entrepreneurs to securely fulfill their cross-chain operations, such as token transfers and arbitrary messaging. Utilizing CCIP will allow users to simplify their cross-chain processes, thereby offering a smoother, more streamlined experience.

1600×666 148 KB

CCIP Components

  • Sender/Receiver: A smart contract and an EOA.

  • Router: The router contract directs instructions to the destination-specific OnRamp

  • Committing DON (Decentralized Oracle Network): Bundle transactions, creates a Merkle root, and writes the Merkle root to the CommitStore contract on the given destination blockchain.

  • Executing DON: Checks whether the transaction is part of the relayed Merkle root in the CommitStore contract.

  • OnRamp:

    • Checks destination-blockchain-specific validity such as validating account address syntax.
    • Verifies the message size limit and gas limits.
    • Keeps track of sequence numbers to preserve the sequence of messages for the receiver.
    • Manages billing.
    • Interacts with the TokenPool if the message includes a token transfer.
    • Emits an event monitored by the committing DON.

  • OffRamp:

    • Verifies authenticity of the message by verifying proof provided by the Executing DON against a committed and blessed Merkle root.
    • Ensure transactions are executed only once.

  • After validation, the OffRamp contract transmits received messages to the Router contract. If the CCIP transaction includes token transfers, the OffRamp contract interacts with TokenPool to transfer the correct assets to the receiver.

  • ARM: A set of independent nodes that monitor the Merkle roots committed by the Committing DON into the Commit Store.

The architecture of CCIP primarily leverages an existing decentralized oracle network to transmit cross-chain information, while integrating verification at both the sending and receiving ends to further ensure message accuracy and enhance security.

LayerZero

Similar to CCIP, Layer Zero is an omnichain communication, interoperability, decentralized infrastructure.

1600×631 149 KB

Step 1: On chain A, the user application (App A) executes a series of actions as part of transaction T, identified by transaction identifier t. The format of this identifier may vary depending on the type of chain A. A step included in transaction T is the transmission of a message over LayerZero, conditioned on the success of T. For illustration purposes, and without loss of generality, we assume that in this scenario App A is using our reference Relayer. App A sends a request to the LayerZero Communicator containing the following information:

  • t: The unique transaction identifier for T.
  • dst: A global identifier pointing to a smart contract on chain B.
  • Payload: Any data that App A wishes to send to App B.
  • Relayer args: Payment information arguments in the event that App A wishes to use the reference Relayer.

Step2: The Communicator constructs a LayerZero packet containing dst and payload, referred to as Packet (dst, payload) , and sends it, along with relayer args, to the Validator.

Step3: The Validator sends t and dst to the Network. This step notifies the Network that the block header for the current block on chain A needs to be transmitted to chain B.

Step4: Validator forwards Packet (dst, payload), t, and relayer args to the Relayer, notifying the Relayer that the transaction proof for T needs to be prefetched and subsequently sent to chain B. This step is carried out concurrently with Step 3.

Step5: Network sends dst and the block ID of the current transaction (cur blk id) to the Oracle. This notifies the Oracle to fetch the block header for the current block on chain A and send it to chain B. In the event that multiple LayerZero transactions occurred in the same block, Step 5 is only executed once.
Step6: Oracle reads the block header (blk hdr) from chain A.

Step7: The Relayer reads the transaction proof associated with transaction T (proof(t)) from chain A, and stores it off-chain. Steps 6 and 7 occur asynchronously to each other.

Step8: Once the Oracle confirms that the block corresponding to blk hdr is stably committed on chain A, it sends blk hdr to Network on chain B. The mechanism determining when this happens varies per chain, but typically involves waiting for a certain number of block confirmations.

Step9: Network sends the block hash, specified as blk hdr hash, to the Validator.

Step10: The Validator forwards blk hdr hash to the Relayer.

Step11: After receiving blk hdr hash, the Relayer sends a list of any Packet (dst, payload), t, proof(t) that matches the current block. In the event that multiple users simultaneously sends messages between the same endpoints, there may be multiple packets and associated transaction proofs within the same block.

Step12: The Validator, using the received transaction proofs and the block headers stored by the Network, validates whether the associated transaction T is valid and committed. If the block header and transaction proof do not match, the message is discarded. If they do match, the Packet(dst, payload) is sent to the Communicator.

Step13: The Communicator emits Packet(dst, payload) to App B.

Compared to CCIP, LayerZero provides more flexibility and supports additional logic development on top. However, the creation of decentralized oracles and relay networks still necessitates further observation.

Integrate cross-chain protocol with StaFi

With the arrival of the Cancun upgrade, trading activity on Layer2 continues to grow, and StaFi’s rETH now supports mainstream Layer2. However, during the integration process, we faced several challenges such as how to decentralize the synchronization of rETH rates from Ethereum to Layer2 platforms like Arbitrum. After much consideration, we have ultimately decided to use the CCIP solution to deploy the rate provider contract to Arbitrum, allowing us to provide rates to dex and other dApps.

rETH rate provider caontract on Arbitrum: https://arbiscan.io/address/0x728bbe0668398f229c64ee95b34c4dbca32699c0

In the future, we will also consider integrating with Layerzero for more cross-chain use cases, such as Ominchain token-related scenarios.

4 Likes