Interoperability Deep Dive: XCMP vs IBC vs Optics

Cross Chain Communication: Model and Impossibility

  • TTP. You need a trusted third party to handle the cross-chain communication (centralized exchanges, federation, collateralized vault, etc.)
  • 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.)
  • “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

  • 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.

High Level Comparison

XCMP

  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.

IBC

  • 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).
  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

  • 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.
  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.
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

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

Sources

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store