Interoperability Deep Dive: XCMP vs IBC vs Optics

In this article, we attempt to provide a high level comparison of the three most actively discussed interoperability protocols for communication between smart contract capable blockchains: XCMP (Polkadot), IBC (Cosmos), and Optics (Celo).

There exist numerous implementations of cross-chain communication between smart contract chains, mostly between Ethereum and another EVM blockchains. These include, but are not limited to, Near’s Rainbow bridge, Polkadot’s SnowBridge, and Cosmos’s Gravity bridge. We do not discuss these in detail — they function similarly to IBC, which describes a more generically applicable standard.

Cross Chain Communication: Model and Impossibility

Before we dive in, it is critical to understand that cross-chain communication is a hard problem and is impossible without a trusted third party. The comparison introduced here uses the Cross-Chain Design Framework from https://eprint.iacr.org/2019/1128.pdf (see also for impossibility result proof).

The impossibility result, in simple terms, means the following:

• TTP. You need a trusted third party to handle the cross-chain communication (centralized exchanges, federation, collateralized vault, etc.)

OR

• Synchrony. You are online yourself and assume that messages get delivered on time. Logic is handled via on-chain contracts (HTLC swaps, cross-chain light clients, etc.)

You can also opt for a hybrid model:

• “Watchtowers”. Assume synchrony, but enact a TTP if there is a timeout/participants are offline.
• “Fraud Proofs”. Use a TTP, but assume someone is online to check for misbehavior and submit fraud proofs.

XCMP vs IBC vs Optics

Let’s dive in.

Before we start: We link the source used for the analysis of each protocol at the end of the article.

First, let’s take a look at what exactly each of the three protocols attempt to do.

• XCMP is a protocol for communication among homogeneous parachains/parathreads (= shards) under Polkadot’s consensus.
• IBC is a standard for communication among heterogeneous (different trust models) smart contract capable chains. Protocol implementation exists for Cosmos SDK chains.
• Optics is a protocol for communication among smart contract capable chains. It uses an “optimistic” model, trying to optimize performance/costs, and operates without full light client verification.

We can see XCMP is distinct from the other two protocols — it is a protocol for communication among homogeneous shards in a sharded blockchain ecosystem. Note: Polkadot has a separate set of protocols / applications / companies building bridges to external blockchains, such as Ethereum and Bitcoin. There are also Polkadot <> Cosmos bridges being built which utilize IBC on both sides.

High Level Comparison

Let us now take a look at the designs and assumptions.

XCMP

Use Case

XCMP is used to send messages between Polkadot’s parachains/parathreads (shards) — we shall use the term “parachain” as an umbrella term in the following.

Trust Model & Assumptions

Parachains need not make additional trust assumptions when communicating with other parachains, since all rely on Polkadot’s consensus.

XCMP relies on Relay Chain (Polkadot’s main/parent chain) and target parachain Validators to verify and validate messages sent from the source parachain. This process is finalized by a block on the Relay chain.

Process

Parachain A (square) sends a message to Parachain B (circle), e.g. a transfer of assets. The main logic is executed by the consensus participants (Validators) and Polkadot specific helper-roles (Collators).

1. A user locks assets in a contract on parachain A, indicating that they are to be sent to parachain B.
2. The message is added to a public “outgoing” queue of parachain A, and in turn the “incoming” queue of parachain B.
3. In the next block of parachain B, this message is verified / executed (assets are unlocked on parachain B).
4. The process is verified and finalized by Validators and registered in a commitment on the Relay Chain.

Simplified XCMP overview. Validators and Collators not shown for simplicity.

This is conceptually similar to implementing cross-chain light clients (chain relays) across all parachains. However, the latter requires a Cartesian product (in terms of parachains) of chain relays to be implemented. XCMP instead relies on Polkadot’s shared security model and the Relay Chain to handle communication across all parachains — i.e., the architecture resembles a star (conceptually similar to payment hubs in payment channels).

Note: this only works because of the shared security model and does not work in a heterogeneous setting without significant additional trust assumptions.

IBC

Use Case

IBC is used to send messages between two heterogeneous chains.

Trust Model & Assumptions

Participating chains hence agree to

• Trust that each other’s consensus / security models hold,
• Follow a common communication standard (IBC)
• Assume that messages/light client proofs will eventually be delivered to the other chain by someone (“Relayer” role).

Process

Chain A sends a message to chain B. Chain A and chain B are independent, and can have completely different consensus mechanisms, as long as they have strong finality guarantees (i.e., we need to assume that after a known point in time, there can be no forks).

1. A user locks assets in a contract on chain A.
2. This message, including a light client proof, is relayed to chain B. This can be done by anyone (IBC calls this role “Relayers”).
3. Chain B verifies the light client proof of chain A. To do so, chain B continuously maintains a chain relay, which parses and verifies block headers of chain A, similar to a mobile wallet. Specifically: chain B verifies that the message happened on chain A, and validates that the message indeed results in assets being locked on chain A. Chain B assumes that if the message was included in chain A, then it and the block it is contained in must be valid (SPV/light client assumption).
4. If the proof is correct (proof that the transaction has been executed), assets are unlocked on chain B.

Simplified IBC overview. Auxiliary Relayer role hidden for simplicity

Optics

Use Case

Optics, similar to IBC, is used to send messages between heterogeneous chains.

Trust Model & Assumptions

Thereby, Optics introduces the role of “Updaters”, collateralized third parties who attest occurrence and correctness of messages on other chains (comparable to oracles). Two chains that use Optics to communicate hence agree to:

• Trust that each other’s consensus / security models hold,
• Follow a common communication standard (Optics)
• Assume that messages will be eventually delivered to the other chain by someone (“Relayer” role)
• Trust that the Updater will not misbehave, or, if the Updater misbehaves that there is at least one honest online user (“Watcher") to submit a fraud proof in a timely (!) manner.

Process

An Updater registers on the target chain B, locking collateral (Open question: how much? Not found in docs.)

1. A user locks assets on chain A.
2. This message is observed, processed (included in a merkle tree) and signed (merkle root) by the Updater.
3. The signed root, the message, and the merkle tree proof (& any further data necessary for verification/processing) are relayed to chain B (by “Relayers” = anyone can do this).
4. The target chain verifies the Updater’s signature and places the message (“assets locked on chain A”) into a queue — and waits for a certain time period for potential fraud proofs submitted by “Watchers”.
5. Once the time period expires without fraud proof submissions, assets are unlocked on chain B.
6. If a fraud proof is submitted, the message is cancelled (NOP) and the Updater is slashed.

Optics follows an “optimistic” approach in the sense that no cross-chain light clients (chain relays) are used to save costs. Instead, the Updater (TTP) is trusted to behave — but there is a dedicated “Watcher” role that monitors chain A and chain B (off-chain processing) and must submit fraud proofs in a timely manner if the Updater misbehaved. The Updater is then slashed (not 100% clear what happens with the collateral).

Simplified Optics overview. Updater and Watcher icons borrowed from official Celo docs. Auxiliary Relayer role hidden for simplicity.

Summarizing,

XCMP and IBC follow a proactive security model (“guilty until proven right”), whereas Optics follows a reactive security model (“innocent until proven guilty”). Optics is hence cheaper and easier to implement (assuming fraud proofs are easier to build than full-fledged light clients), while XCMP and IBC are more resilient to misbehavior.

Detailed Comparison

Using the Cross-Chain Design Framework (https://eprint.iacr.org/2019/1128.pdf) we conduct a detailed analysis of the security assumptions of each of the three protocols, at each step of the process.

Attention: reading the SoK recommended (or watching this video presentation from FC’21: https://www.youtube.com/watch?v=gsf-z_v8pao&ab_channel=ifca) before proceeding.

We summarize the result here: https://docs.google.com/spreadsheets/d/1ZbIYsJe1tahHZ-NWoQhA6GthUtn10AspQtqby9o2zh0/edit?usp=sharing

Detailed comparison of XCMP, IBC and Optics (screenshot preview, follow GSheet link for full table).

Sources

• XCMP: https://wiki.polkadot.network/docs/en/learn-crosschain#:~:text=Cross%2Dchain%20transactions%20are%20resolved,queue%20of%20the%20destination%20parachain.
• IBC: https://ibcprotocol.org/documentation
• Optics: https://wiki.polkadot.network/docs/en/learn-crosschain#:~:text=Cross%2Dchain%20transactions%20are%20resolved,queue%20of%20the%20destination%20parachain.