Blog

The Inter-Blockchain Communication (IBC) Protocol and Chainlink’s Cross-Chain Interoperability Protocol (CCIP) are two of the premier blockchain interoperability solutions. With its 3-year track record, IBC has proven to be battle-tested and secure, while CCIP, having launched a year ago, is emerging as a viable option.

This blog is the first post within a series of comparison posts of IBC with its competitors. This blog aims to provide an in-depth comparison between IBC and CCIP, starting with an overview of their architectures, followed by an analysis across four key pillars of comparison:

• Security/Trust assumptions

• Expressivity

• Speed and Cost

• Extensiveness

For readers already familiar with either or both protocols, feel free to skip the section on architecture and navigate directly to the comparative analysis.

As a well-specified, battle-tested, and general-purpose interoperability protocol, IBC is a standardized transport layer that facilitates sending and receiving messages between arbitrary state machines.

The core components of IBC include:

• Light client: A lightweight representation of one blockchain on another. Used to verify block headers.

• Connections: A transport layer abstraction that connects two light clients on two disparate chains.

• Channels: A transport layer abstraction that serves as a conduit to transfer IBC packets between modules/applications on different chains.

Relayers: Off-chain processes that monitor cross-chain events, constructs IBC packets, and performs message routing.

Note: While light clients are the preferred mechanism today to verify message correctness, they are not a strict requirement. Similar to TCP, IBC is a standardized way to transport messages from point A to B. The verification method used is entirely up to the chain developer. IBC defines three interfaces - ClientState, ConsensusState, and ClientMessage - that are designed to be generic enough to swap out different verification mechanisms.

Let’s use an example of an end-to-end transaction flow between chain A and chain B to understand IBC’s architecture in detail:

1. A user on chain A intends to send a message to their account on chain B (e.g. token transfer).

2. The user triggers the relevant application module, which subsequently calls into Core IBC.

3. Core IBC commits a hash of that message to the state machine, at a predefined path agreed upon by both chains during the connection handshake.

4. The commit triggers an event. Relayers continuously monitor chains for such events and constructs a MsgRecvPacket which contains an UpdateClient message to update the light client of chain A on chain B of its latest ConsensusState (Merkle root of the application state), a Merkle proof of the message, and the message itself encoded as bytes.

5. Upon receiving the message, Core IBC writes a packet receipt to state and verifies the correctness of the message by checking if the Merkle proof provided hashes up to the Merkle root (contained within the Root field of ConsensusState).

6. In the happy path, the message is successfully verified, triggering an application callback which allows the module to unmarshal the contents of the message and perform business logic (such as minting/swapping/staking tokens or performing a function call). A MsgAcknowledgement is sent back to chain A, conveying a successful acknowledgement of the message.

7. In the unhappy path, the application logic fails on chain B. In this case, an error acknowledgement is sent back to chain A, which can then revert state (such as unlocking tokens that were previously locked).

IBC also handles timeouts, where a message was sent from chain A, but it was never received on chain B within a specified time. Timeouts are always proven on the source chain based on the counterparty’s time. Detailing how timeouts work is outside of the scope of this blog post. See here to learn more about how timeouts work.

Application developers can permissionlessly deploy their apps on top of the IBC transport layer. The reference implementation of the IBC protocol written in Go, ibc-go, offers various applications out of the box, such as:

• ICS-20 Fungible Token Transfers: For cross-chain token transfers
  

• ICS-27 Interchain Accounts (ICA): For cross-chain account management
  

• ICS-31 and 32 Interchain Queries (ICQ): For cross-chain data reads
  

• ICS-721 NFT Transfers: For cross-chain NFT transfers

ICS stands for Interchain Standards. They define the standardized technical specifications for each subprotocol or feature.

IBC also offers app devs the freedom to extend these apps with the use of middleware, enabling additional functionality that complements existing applications without having to add or change core IBC logic. Middleware that can be leveraged today includes:

• ICS-29 Relayer Fee Middleware: To pay IBC relayers for the packets they relay
  

• Callbacks Middleware: Wrap token transfer or ICA module to perform arbitrary logic upon sending or receiving a message. See here to learn more.
  

• Rate-Limiting Middleware: Safety control middleware for token transfers.
  

• Packet-Forward Middleware: Middleware for efficient packet routing.

As a general-purpose interoperability solution, CCIP is one of the many services offered by Chainlink. Thus, briefly describing Chainlink is necessary in order to explain CCIP’s architecture.

The Chainlink network consists of several Decentralized Oracle Networks (DONs) that run the Chainlink binary. These are comprised of nodes that run the core Chainlink client software known as Offchain Reporting (OCR). The Chainlink protocol can be run by anyone who wishes to tap into one of the services offered by Chainlink, including CCIP, data feeds, Proof-of-Reserves data, and verifiable random number generation.

The core components of CCIP are:

• Router contracts: Primary smart contracts that CCIP-enabled applications interface with. There exists one Router per chain.

• Committing DON: A set of oracle nodes responsible for writing Merkle roots of state to a destination chain, based on cross-chain events emitted on a source chain.

• Executing DON: A set of oracle nodes responsible for submitting Merkle proofs of cross-chain messages, and executing function calls on a destination chain.

• The Risk-Management Network (RMN):  A set of nodes that independently constructs Merkle roots of cross-chain actions and compares that with the root submitted by the Committing DON. The RMN can either ‘bless’ or ‘curse’ a contract based on whether transaction verification succeeds or fails. We discuss the RMN and DONs in more detail below.

CCIP is currently still in the early mainnet phase, therefore access to the protocol is permissioned to a certain degree. A full generalized mainnet is planned for early this year.

To understand CCIP’s architecture in more detail, let’s use an example of an end-to-end transaction flow between chain A and chain B:

1. A user on chain A intends to send a message to their account on chain B (e.g. token transfer).

2. The user triggers the relevant application smart contract, which subsequently calls into the Router contract.

3. The Router is the main entry point for users to send cross-chain messages. One router contract exists per chain. It handles fee payments, token transfers to the appropriate pools, and forwards messages to the OnRamp contract. If sufficient gas was paid for the message, it gets routed to a TokenPool contract. Each token has its own TokenPool.

4. From the Router, the message gets routed to the OnRamp contract which, among other checks, performs the following verification logic:

   • Validates the message based on the amount of data, gas, and number of tokens

   • Calculates billing/fee logic

   • Handles token locking/burning

   • Performs rate limit checks

1. Once all the necessary checks have passed, an event is emitted, with the newMessage struct containing details of the message to be sent.

2. The Committing DON monitors chains for such events (similar to IBC relayers) and writes a cryptographic proof in the form of a Merkle root to the CommitStore contract on chain B. The root is signed by a quorum of oracle nodes within the Committing DON.

3. At this point, the Risk Management Network (RMN) kicks in. It independently reconstructs the Merkle root for the transaction(s) that the Committing DON committed to.

4. In the happy path, the reconstructed root matches the one submitted by the Committing DON. In this case, the RMN ‘blesses’ (approves) the commitment by sending a transaction to the RMN contract on chain B.

5. The Executing DON, after ensuring that a commitment exists in the CommitStore and that it has been ‘blessed’ by the RMN contract, proceeds to submit a Merkle proof of the transaction(s) to the OffRamp contract.

6. The OffRamp contract verifies this proof against the commitment. If it checks out, the message is routed to the Router contract on chain B.

7. Finally, the Router calls into the receiver application contract and invokes the ccipReceive method to trigger mint/unlock of tokens.

In the context of blockchain interoperability, security is a multi-faceted property. Evaluating the security of interoperability solutions involves addressing several critical questions:

• How secure is the underlying system design?

• How secure is the implementation?

• What best practices are followed to minimize the risk of implementation bugs?

• What defence-in-depth measures exist in a worst-case scenario?

From a system design perspective, the security of IBC is intrinsically linked to the security of both the source and destination chains. Why? Because the verification performed by IBC light clients is to verify the consensus of a counterparty chain. When chain B receives a message from chain A, the former trusts what the consensus threshold of chain A’s validator set has claimed to be true. The light client cannot re-execute transactions and verify state transitions.

This opens up the possibility for a light client to be tricked into accepting invalid headers if the validator set of a chain is compromised. However, as highlighted by Henry de Valence, there's an often-overlooked nuance: one can have trustless IBC message verification between two chains when there is a validator set overlap between those chains, as that would allow full execution to be verified instead of just consensus.

As defensive mechanisms, IBC employs the following features:

• Misbehaviour detection: As mentioned earlier, even though light clients are trusting the consensus of a counterparty, in the event that the counterparty validator set misbehaves - such as double signing - light clients are capable of detecting it and freezing that connection and therefore prevent any further messages to be accepted from the malicious chain. 

• Rate limits: IBC does not yet have in-protocol rate limits. However, the IBC rate limit middleware developed by Osmosis can be used to act as a safety control mechanism to limit the amount of value that can exit a chain within configurable time intervals.

• Application circuit breaker: The x/circuit module within the Cosmos SDK allows specific messages or all to be disabled in case of a hack/bug.

As an externally verified solution, CCIP’s architecture does not offer the same degree of security as IBC. Unlike IBC, chains A and B using CCIP not only need to trust one another's consensus, but also the honest majority of CCIP nodes.

But given this additional trust assumption, CCIP has implemented robust security measures to ensure safe message delivery, such as:

• Rate limits per TokenPool contract and an aggregated rate limit per chain.

• RMN does not interact with either of the DONs, thereby verifying messages independently of that done by the Committing and Executing DONs.

• RMN is an implementation separate from the DON codebases written in a separate programming language (Rust) built by a team other than Chainlink Labs. This prevents bugs in one of the DON implementations affecting the RMN, and vice versa.

• RMN can freeze any cross-chain actions from taking place in the event of detecting invalid messages or other anomalies.

• It is also important to mention that the Committing DON, Executing DON, and the RMN are 3 separate networks. Compromising CCIP requires all 3 networks to be compromised.

Whether or not a system can be upgraded and how it can be upgraded is another factor that directly impacts security. In the case of IBC, any upgrade (such as channel upgrades) requires a governance proposal to be passed on the chain that wishes to upgrade. The IBC protocol itself is not owned by any single organization or team, and therefore no one can decide to unilaterally change IBC logic. 

In the case of CCIP, the Chainlink 4 of 8 multi-sig can propose upgrades to the protocol using a time-locked contract. Upgrades can be categorized into two types:

1. Upgrade proposals that are proposed by a dedicated ManyChainMultiSig contract and are subjected to a review period, during which the CCIP node operators can veto the proposal.

2. Upgrade proposals that are proposed by a dedicated ManyChainMultiSig and explicitly approved by a quorum of CCIP node operators.

The median latency of a MsgRecvPacket on CometBFT (formerly Tendermint) chains is 22 seconds. Given that the latency of CometBFT consensus is ~5 seconds, the latency of receiving an IBC packet is approximately 17 seconds. A full packet lifecycle (recvpacket + ackpacket) takes around 20 seconds excluding consensus latency.

The speed of IBC between other ecosystems such as Polkadot parachain<>Cosmos SDK chain is contingent upon the latency of Polkadot’s and CometBFT consensus plus relayer latency.

CCIP latency is the time to finality on the source chain plus 1-5 minutes depending on which batch your transaction got into. For example, a transfer from Ethereum Mainnet to Avalanche would take anywhere from 13-17 minutes to finalize.

In terms of fees, IBC has no in-protocol rent extraction. Users pay the associated transaction cost on the source chain, and relayers take care of fee payment for packet delivery. ICS-29 Fee Middleware can be used to incentivize relayer operators for the packets they carry. You can read here to learn more about the Fee Middleware. Users of IBC can pay fees in any token and not just the chain’s native token. This is enabled by the Fee Abstraction module developed by Osmosis.

Apart from the transaction costs, and unlike IBC, CCIP charges end users an additional network fee for the CCIP node services. Users can pay fees in LINK, native tokens of the supported networks, and wrapped versions of various ERC-20 tokens.

The property of expressiveness here is defined as the degree of freedom offered to developers to build applications.

Both CCIP and IBC support arbitrary/generalized message passing. Meaning that any data can be sent over these protocols as long as they are encoded in bytes. Both protocols support sending just tokens, just data, or both token transfer + data, where arbitrary data is sent along with the token transfer. Data is sent using the memo field in IBC and using the data field in CCIP.

One of the features unique to IBC among all existing interoperability solutions is the support for native packet receipts and acknowledgements, making it easy for app developers to build composable applications. For example, one can use the callbacks middleware to build an application that bundles multiple user actions into a single transaction. This is made possible by triggering an action upon receiving a successful ACK. 

Using callbacks middleware, developers can build apps with the following use cases:

• Send tokens from chain A to B. If the transfer is successful (success ACK received), send a subsequent message to stake/LP/swap tokens.

• Execute arbitrary smart contract logic upon receiving an ICS-20 token transfer packet.

Similar control mechanisms are not available within CCIP. If a message fails on the destination, there is no in-protocol mechanism to notify the sender. 

IBC also offers the Interchain Accounts (ICA) feature out of the box. Using ICA, any action that can be performed on a chain (send, swap, stake, LP) can be executed on a remote chain from the source chain. Currently, ICA is used in the following ways:

• Stride and Quicksilver leverage the feature for cross-chain liquid staking

• Neutron uses ICA for money market activities, such as cross-chain lending/borrowing

• Nolus and Quasar leverage ICA for cross-chain portfolio management

One of the main selling points of ICA is that from an end-user perspective, an action performed on a remote chain is indistinguishable from an action performed on the source chain. Users don’t need to leave the source chain front-end to do actions on another chain. This allows app developers to abstract the concept of cross-chain where users no longer need to know which chain they’re on and which chain they need to go to. 

An ICA-equivalent feature is not natively offered within CCIP, although in theory, any application developer could build a similar functionality with the use of cross-chain smart contracts.

Expressivity is also closely linked to what developers can and can’t do. The degree of permissioning of a protocol therefore influences expressivity. IBC is permissionless in the sense that anyone can:

• Integrate IBC. Anyone can choose to implement IBC on a new chain or ecosystem. The code is open-source and MIT-licensed, thus projects do not need to ask permission from a centralized organization to add IBC to a new ecosystem. 

• Operate a relayer

• Open connections

• Open channels

• Propose new channel upgrades

• Contribute to the protocol by adding new features or improvements

In a nutshell, all facets within the IBC protocol are entirely open and permissionless.

As of writing, CCIP has not yet reached a fully open and permissionless mainnet. Therefore, certain aspects of the protocol are permissioned. For example, new lanes (unidirectional channels between chains) cannot be permissionlessly opened. Instead, it is currently permissioned through Chainlink Labs. Similarly, new chains cannot be permissionlessly integrated.

IBC is currently live on Cosmos and Polkadot ecosystems and is used by 114 chains that include both Cosmos SDK and Substrate chains. Apart from these two ecosystems, the following teams are working on extending IBC to new chains:

• Polymer Labs: IBC for Ethereum rollups

• Union: IBC between Ethereum Mainnet and Cosmos chains

• Electron Labs: IBC between Ethereum Mainnet and Cosmos chains

• Landslide Network: IBC between Avalanche and Cosmos chains

• Composable Finance: IBC between Solana and Cosmos chains

To integrate IBC on a new chain, the following components are required:

• An IBC transport layer implementation

• A light client for the chain

• A relayer implementation

CCIP is currently supported on 9 chains. Enabling CCIP on a new chain requires all node operators to run full nodes of the chain, and for system contracts such as the Router, TokenPool, CommitStore, and OnRamp/OffRamp to be implemented.

As of writing, it is not permissionless to add a new CCIP-supported chain. Developers who want their app to interact with a non CCIP-enabled chain must reach out to the team at Chainlink Labs to request support for said chain.

In this comparative analysis, we delved into the intricacies of two leading interoperability protocols that make distinct tradeoffs to provide robust cross-chain infrastructure.

For projects building cross-chain applications, deciding which protocol to choose will ultimately depend on your specific requirements and use cases. 

If you prefer to write your programs in Solidity and require interoperability only between EVM chains, then CCIP is currently a strong option. If you’re using the Cosmos SDK or Substrate as your blockchain framework, then you get IBC out of the box with access to 100+ other IBC-enabled chains, with more ecosystems such as Ethereum Mainnet, Ethereum rollups, Solana, Avalanche, Dymension, and Rollkit rollups being added to the ever-growing IBC network.

In terms of usage and activity, IBC has a lead over CCIP. But when it comes to extensibility to EVM chains, CCIP can be more easily deployed than IBC. Both protocols support a diverse suite of features. IBC natively supports multiple applications, while with CCIP, developers are expected to hand-roll their own applications.

As the interoperability landscape continues to evolve, IBC and CCIP will undoubtedly play a pivotal role in shaping the cross-chain experience, driving forward the vision of a fully interconnected network of networks.