Blockchain Interoperability Explained: Bridges, Cross-Chain Protocols, and CCIP

The power of connected blockchains

A major problem in the blockchain universe is its fragmentation: there are hundreds of blockchains, thousands of asset types, millions of users, and countless applications and protocols. Imagine a country with five different languages but no lingua franca: you either have to learn all the languages or use translation tools for each language. With blockchains, this means using different tools for each chain and using exchange sites to convert tokens from chain A into tokens compatible with chain B. This process is necessary to access and use chain B's applications when you only have tokens from chain A.

Bridges and cross-chain protocols solve this problem. They allow you to use different blockchains' tokens, functionality, and data, without the friction of using exchanges and being subject to transaction fees and exchange rates. For example, they can offer:

• Asset transfer across different blockchains: Tokens created on Ethereum could also “exist” and be tradeable on, say, Polygon, Avalanche, and Polkadot.

• Increased liquidity and capital efficiency: If assets are easier to move across blockchains, they’re more easily invested in trading pools, for example.

• Cross-chain software, aka smart contracts: You can imagine chain A leveraging the functionality of a smart contract on chain B.

Let’s thus delve into the technology that connects blockchain before focusing on a recent cross-chain protocol.

From cross-chain bridges to protocols

A blockchain bridge, also known as a cross-chain bridge, is a system that allows two different blockchain networks to exchange assets, when the asset can be represented on both chains. For example, you can send bitcoins to an Avalanche address: the bridge will lock the BTC, while the Avalanche bridge contract will mint BTC.b tokens, a representation of bitcoins on the Avalanche network. The newly created wrapped bitcoins will thus represent the locked bitcoins on the Ethereum network.

A bridge therefore reduces the financial cost and risk of using different blockchain platforms. It allows users to move assets from one chain to another without needing to go through a centralized exchange, or without resorting to atomic swaps between different assets, which are susceptible to unpredictable exchange rate fluctuations.

However, bridges also introduce a major security risk as they often lock funds and have the capability to mint tokens. A bug in a bridge could potentially allow an attacker to steal the locked funds or mint as many tokens they want. It’s thus no surprise that many of the most significant blockchain hacks are bridges hacks, with over $2.5B losses. Another risk tied to bridges is their centralization. For example, when the Ren protocol was acquired by Alameda Research, the fate of Ren became intertwined with Alameda's, leading to concerns as Alameda folded. To learn more about bridges and their risks, read, for example, Ethereum’s introductory page or Chainlink's, and Binance Research’s report Decoding Cross-Chain Interoperability.

A cross-chain protocol generalizes the concept of bridge: it allows blockchains to exchange arbitrary messages—such as calling a smart contract on a different blockchain, querying data, or controlling accounts on other chains. Today, one of the main cross-chain protocols is the Inter-Blockchain Communication (IBC) protocol, developed by the Cosmos ecosystem’s Interchain Foundation. However, IBC was not initially designed for Ethereum compatibility, even if solutions have been put in place to allow it. Another major cross-chain protocol is Wormhole, which is more focused on Ethereum. This article explores the Cross-Chain Interoperability Protocol (CCIP), a recent cross-chain protocol from Chainlink.

The Cross-Chain Interoperability Protocol (CCIP)

Chainlink is mainly known for its oracles, or ways to provide on-chain applications with off-chain data such as exchange rates. In 2023, Chainlink released the Cross-Chain Interoperability Protocol (CCIP), an infrastructure designed to perform cross-chain operations, including asset transfers, messaging, and data access. Both CCIP software and smart contract are available on GitHub.

Compared to IBC, CCIP addresses a similar problem but with a different architecture. While IBC requires blockchains to implement the IBC protocol, CCIP integrates directly with the native protocols of blockchains. However, CCIP heavily relies on Chainlink’s infrastructure, introducing a centralization aspect often perceived as undesirable. Many expect both protocols to coexist and serve different use cases, eliminating the need for custom and fragile bridges. Note that CCIP’s applicability can extend beyond blockchain organizations, with ongoing experiments by the Swift network, as well as the Australian bank ANZ.

It’s also worth noting that CCIP, although in version 1.0.0, is (as we write) “in the ‘Early Access’ stage of development, which means that Chainlink CCIP currently has functionality which is under development and may be changed in later versions.” It currently supports EVM-based mainnets of L1 and L2 protocols: Ethereum, Optimism, Arbitrum, Polygon, Avalanche, BNB Chain, and Base.

CCIP is composed of several components:

• Router contract, deployed on each supported blockchain.

• OnRamp and OffRamp contracts, which receive messages from the router that is on the same blockchain.

• Risk Management Network contract, which oversees validation and anomaly-detection aspects, respectively via the concepts of “blessing” and “cursing”.

The two main type of supported tokens are ERC-20 and ERC-677. For example, the token LINK, used to pay the node operators in the Chainlink architecture, is an ERC-677.

In the rest of this article, we’ll focus on the different ways to use CCIP to transfer tokens between two chains, which is its main use case.

CCIP token transfer approaches

CCIP provides three ways to handle cross-chain token transfer, which we’ll describe below. Throughout this section, we’ll assume the scenario that we’re transferring assets from some chain A (the source chain) to some chain B (the destination chain).

In each approach, the router contract transfers tokens to an associated pool. Such pool must be deployed and registered in the router contract for each source chain and destination chain. The code snippet below, extracted from the router’s contract, illustrates this transfer operation:

Note that the definition of such pools is restricted to the contract owner, as exemplified in the EVM2EVMOnRamp.sol contract:

Executing CCIP transfers

To send the transfer operation to the router contract, an end user (externally-owned account) can encode the message off-chain, for example, through a front-end GUI, and send it directly to the router contract by calling the external function ccipSend. This function is not restricted by an access control and can be called by anyone.

Another possibility—for instance, if you wish to use the bridge with your dApp or manage the fee payments yourself instead of your end user—is to create what the bridge documentation indicates as a sender contract. This contract receives the token contract address, the amount to transfer, the destination blockchain (if not harcoded), and will generate the message to the router and pay the fee. An example of such a contract is available in the Chainlink documentation.

1. Burn & Mint

In this model, the bridge burns tokens from chain A and mints as many tokens on chain B, where each token is the unique representation of the asset transferred on its respective chain. These may be a “native” token and a “wrapped” token or simply two tokens where neither is inherently more “native” than the other. As with any bridge, both operations must happen “at the same time”: burning without minting destroys tokens, and minting without burning creates additional tokens—though perhaps not additional value.

As CCIP’s code shows, the token must have a public burn function that will be called by the token pool of the bridge. To mint new tokens, the token pool will call the mint() function of the smart contract, as indicated in the code. Likewise, the contract BurnMintTokenPoolAbstract.sol defines a function lockOrBurn() that calls an internal function _burn():

In the contract BurnMintTokenPool.sol, which inherits from this contract, the internal function _burn() is defined as follows, showing a call to the burn() function from the ERC-20 token:

Of course, not anyone should be able to burn or mint tokens. Instead, an access control mechanism must be implemented and configured to allow the token pool to burn and mint tokens. For example, OpenZeppelin’s role-based access control (RBAC) framework might be a good choice. Note that the ownership system with a modifier onlyOwner is not feasible, as it would make the token pool contract the owner of the token, posing a security risk.

To allow the pool to mint or burn tokens, an ERC-20-compatible token must therefore implement one of the the burn() functions and the mint() function, as per the IBurnMintERC20 interface:

For additional information about token pools, you can refer to the Chainlink documentation.

2. Lock & Mint

The model involves locking tokens on chain A and minting tokens on chain B. Locking tokens means that they still exist (they aren’t burnt) but cannot be transferred. In this model, you generally have “native” tokens locked on the source chain, and “wrapped” tokens minted on the destination chain.

Lock & Mint requires fewer permissions than Burn & Mint, as the token pool can only mint new tokens on the destination chain but cannot mint or burn tokens on the source chain. From a “financial” perspective, the locked tokens don’t exist, as the total supply must remain constant. From a technical perspective, however, the locked tokens still exist and may be transferred if the bridge logic is flawed—a risk not present in the Burn & Mint approach.

This method is also useful for blockchain-native gas tokens, such as ETH, MATIC, and AVAX, which cannot be minted on the destination blockchain. Instead, you can lock the tokens on the source chain and mint a wrapped or synthetic asset on the destination chain.

3. Lock & Unlock

The last mechanism only works when tokens already exist on both chains and are locked in liquidity pools. As you’ve guessed, this model locks tokens on the source chain and unlocks an equivalent number of tokens on the destination chain. For this, the bridge contracts need (un)lock capabilities on liquidity pools but don’t require access to mint or burn capabilities, thus mitigating the damage in case of a hack—an attacker could only access as many tokens as there are in the pool.

To use this method, you have to provide liquidity to the contracts' pools. The contract LockReleaseTokenPool.sol from CCIP, defining this type of pool, provides two functions, addLiquidity() and removeLiquidity(), to manage the liquidity in the pool:

Risk and practical considerations

If you consider using CCIP in production, we first recommend that you wait until the protocol has stabilized and undergone enough security analysis and review by security experts. Although Chainlink’s CCIP appears to have solid security mechanisms, the relative complexity of the protocol and the potential impact of a hack increase the risk to a level that may or may not be acceptable, depending on your use case.

Aside from the maturity and risk aspects, you must consider the following points if you intend to use CCIP (non-exhaustive list):

• Networks supported: Which chains does CCIP support now, and which ones is it likely to support in the future?

• Sender contract: Apart from the token contract and the CCIP router, you’ll need a contract called “Sender contract” in Chainlink’s documentation. See for example this contract designed to mint an NFT on one chain and pay for minting on another.

• Transfer fees: You will need LINK tokens or another supported token to pay CCIP fees; you should estimate these costs in advance.

• Liquidity pools: If you intend to use the Lock & Unlock logic, there must be pools with liquidity on both chains, defined by the TokenPool.sol and LockReleaseTokenPool contract.

• Access control:

  • Pool: Which entities and accounts can manage and control the different pools used?

  • Tokens: If you intend to use the Burn & Mint or Lock & Mint approaches, you’ll need tokens equipped with an access control mechanism to grant CCIP contracts burn and/or mint capabilities.

• Finality: What happens if your tokens are locked or burnt on the source chain, but an error in the destination chain results in a reverted transaction? For example, imagine that in the destination chain, there is a maximum supply limit on the tokens that have to be minted for each token blocked on the source chain. In this scenario, if the pool on the destination chain attempts to mint new tokens, the transaction will be reverted, but your tokens are already locked on the source chain.

  Conclusion

  Chainlink’s established reputation in the realm of oracles positions CCIP as a technology with good adoption potential. CCIP offers multiple ways to transfer your tokens, ensuring compatibility with the majority of tokens and use cases and allowing you to choose the most suitable method for your specific needs.

  Contrary to several blockchain bridges, CCIP is an infrastructure designed to be integrated and used within an application. Its primary target is not actually the end user; therefore, you won’t find a user-friendly graphical interface from Chainlink. Instead, there’s comprehensive documentation of the architecture that explains how CCIP works and how to integrate it into your dApps.

  In a forthcoming post, we will delve deeper into the technical aspects of CCIP.