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.
Protocol | Number of supported chains | Verification mechanism | Safety assumption | Liveness assumption | Arbitrary message passing | Latency | Cost | Permissioning | Launched on |
---|---|---|---|---|---|---|---|---|---|
IBC | 114 | Light clients verify block headers. Can plug in arbitrary verification logic. | Honest majority of source and destination chain validator sets. | At least one relayer | Yes | Source and destination chain finality time + ~20 seconds | No protocol fees | Permissionless: operating relayers, opening channels and connections, integrating new chains, upgrading channels. | April 2021 |
CCIP | 9 | 3 distinct oracle networks verify consensus of source chain. | Honest majority of at least 1 of 3 oracle networks. | Liveness of Committing DON, Executing DON, and Risk Mgmt Network | Yes | Source chain finality time + 1-5 mins | Network fee paid to oracle nodes | Adding new lanes and chain integrations are permissioned by Chainlink Labs. | July 2023 |
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:
A user on chain A intends to send a message to their account on chain B (e.g. token transfer).
The user triggers the relevant application module, which subsequently calls into Core IBC
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.
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.
Upon receiving the message, Core IBC writes a packet receipt to stateRoot
field of ConsensusState
).
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.
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
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:
A user on chain A intends to send a message to their account on chain B (e.g. token transfer).
The user triggers the relevant application smart contract, which subsequently calls into the Router
contract.
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
.
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
Handles token locking/burning
Performs rate limit checks
Once all the necessary checks have passed, an event is emitted, with the newMessage
struct containing details of the message to be sent.
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.
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.
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.
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.
The OffRamp
contract verifies this proof against the commitment. If it checks out, the message is routed to the Router
contract on chain B
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:
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.
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 speed of IBC between other ecosystems such as Polkadot parachain<>Cosmos SDK chain is contingent upon the latency of Polkadot’s
Protocol | Latency | |
---|---|---|
IBC | Source and destination chain finality time + ~20 seconds | No in-protocol fees. Chains can add relayer fees by integrating relayer fee middleware. Anyone (end-user, community pool, chain, etc.) can pay relayers using fee middleware. |
CCIP | Source chain finality time + 1-5 mins | Charges network fee paid for CCIP node services |
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
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.
Protocol | Token transfer | Arbitrary message passing | Token transfer + data/action | In-protocol packet receipts & acknowledgements | Cross-chain data writes | Cross-chain data reads |
---|---|---|---|---|---|---|
IBC | Yes | Yes | Yes | Yes | Yes - ICA | Yes - Interchain Queries (ICQ) |
CCIP | Yes | Yes | Yes | No | No in-protocol feature | Yes - oracle data feeds |
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.
Protocol | Number of supported chains | Requirements to add new chains | Permissionless |
---|---|---|---|
IBC | 114 | Implement transport layer logic, light client, and relayer. | Integrations are permissionless. |
CCIP | 9 | Implement system contracts. Node operators run full nodes of new chain. | Integrations are currently permissioned. |
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.
Core IBC comprises of 02-client, 03-connection, 04-channel, 23-commitment, and 24-host.
Used to verify existence or non-existence of key-value pairs.
See here to learn how Merkle proofs are used in conjunction with Merkle roots to prove the existence/non-existence of values.
As of writing, there is no publicly available information on the total number of nodes, node diversity and geographical distribution of the Committing DON, Executing DON, and the Risk Management Network.
There exists one OnRamp
and OffRamp
contract per lane. Where a lane is a distinct, unidirectional pathway between a source and destination chain.
The root could be to prove a single message or a batch of messages.
Unlike standard multi-sig contracts, ManyChainMultiSig
supports signing many transactions targeting many chains with a single set of signatures. This is useful for administering systems of contracts spanning many chains without increasing signing overhead linearly with the number of supported chains.
~5-second blocks is the CometBFT default config. In practice, chains increase/decrease block times according to their use case. For example, Sei has < 1-sec blocks, while Celestia produces blocks every 12 seconds.
Time to finality on Ethereum Mainnet is 12 minutes.