Interoperability in Blockchain — Quick Reference Notes

Overview

  • Definition: Interoperability is the ability to flexibly transfer assets, share data, and invoke smart contracts across public, private, and consortium blockchains without changes to the underlying blockchain systems.
  • Taxonomy (five categories): sidechains, notary schemes, hashed time lock contracts (HTLC), relays, and blockchain agnostic protocols.
  • Scope: survey analyzes system and safety characteristics; provides empirical evaluation for representative cross-chain approaches; discusses challenges and directions.

Taxonomy framework

  • System characteristics:
    • Decentralization: centralized vs decentralized
    • Locking mechanism: trusted accounts vs trustless accounts vs smart-contract–based locking
    • Verification mechanism: Observation, Certification, SPV
    • Communication direction: Unidirectional vs Bidirectional
  • Security characteristics:
    • Trust (trusted vs trustless)
    • Liveness
    • Safety
    • Atomicity

Blockchain interoperability approaches

  • Sidechains
    • Independent blockchain connected to a mainchain; assets locked on mainchain and represented on sidechain; two-way vs one-way peg; sidechains have own consensus.
    • Pros/cons: potentially faster transfers; introduces cross-chain security assumptions; centralization risk in some designs.
    • Examples: RSK (Bitcoin sidechain with merge-mining), Zendoo (zk-SNARKs for sidechains).
  • Notary schemes
    • Trusted third party or group witnesses events on one chain and confirms on another; simple to implement but risk single point of failure.
    • Types: single notary (centralized) or consortium notaries (decentralized).
    • Examples: RenVM, Bifrost, ReviewChain.
  • Hashed Time Lock Contracts (HTLC)
    • Hash lock + time lock to enable atomic swaps across blockchains without a trusted party.
    • Key ideas: pre-image x, hash h = hash(x); timeouts prevent fund lockup; privacy concerns exist.
    • Variants: TierNolan protocol, Burn-to-Claim, ARS (privacy-preserving cross-chain swaps).
  • Relays
    • Bridge-like mechanisms that relay/verifiy information (e.g., block headers) across chains; can be trustless (light clients) or trusted (multi-party relays).
    • Examples: BTCRelay (Bitcoin–Ethereum SPV bridge), XCLAIM, Verilay (PoS relay), Tesseract (TEE-based), Practical AgentChain, IvyCross (TEE-based cross-chain framework).
  • Blockchain-agnostic protocols
    • Abstraction layers enabling cross-chain communication without relying on a specific blockchain design.
    • Examples: Interledger Protocol (ILPv4), Perun (state channels across chains), Gravity/Susy (oracle-consensus–based asset transfers), Abebe et al. trusted data transfer framework.

Evaluation and findings

  • Use cases evaluated: atomic swap and asset transfer (Bitcoin↔Ethereum focus; ILPv4 evaluated Ethereum↔Ripple due to implementation).
  • Metrics:
    • Latency: time from first on-chain transaction to last on-chain transaction; Δcross ≈ Δon (Δoff negligible).
    • Throughput: TPS across cross-chain protocols; theoretical cross-chain throughput = min(TPS of each blockchain, off-chain throughput).
    • Cost: on-chain transaction fees and gas costs.
  • Key formulas:
    • Latency: Δ<em>cross=Δ</em>on+Δ<em>off≈Δ</em>on\Delta<em>{\text{cross}} = \Delta</em>{\text{on}} + \Delta<em>{\text{off}} \approx \Delta</em>{\text{on}}
    • On-chain latency: \Delta_{\text{on}} = n \cdot \text{btc_blk} + m \cdot \text{eth_blk}
      where \text{btc_blk} = 10\text{ minutes}, \ \ \text{eth_blk} = 14\text{ seconds} and for HTLC, n=7, m=13n=7,\ m=13 (example waiting blocks).
    • Throughput (cross-chain): TPScross-chain=min⁡(TPS<em>1,…,TPS</em>N,TPSoff)\text{TPScross-chain} = \min(\text{TPS}<em>1, \dots, \text{TPS}</em>N, \text{TPS}_{\text{off}})
    • Theoretical per-block throughput: \text{TPB} = \frac{\text{block_limit}}{\text{transaction_size}}, \text{TPS} = \frac{\text{TPB}}{\text{block_time}}
  • Observations:
    • Performance is dominated by the slowest underlying chain (e.g., Bitcoin↔Ethereum). Commonly low TPS (roughly a few to tens of TPS in many setups).
    • Latency grows with block times; HTLC deployment and on-chain operations can dominate cost, especially with smart-contract deployments.
    • Some approaches (RenVM, ILPv4) achieve lower costs by minimizing on-chain operations, while HTLC variants can be expensive due to contract deployment and interaction costs.
    • Theoretical throughput can be higher if blockchains are upgraded or redesigned for interoperability (e.g., Cosmos, Polkadot).

Cross-chain platforms (overview)

  • Permissionless (public):
    • Polkadot: network of parachains connected via a central relay chain; XCMP for substrate chains; bridges to Ethereum, Bitcoin via bridges.
    • Cosmos: IBC-based hub-and-zone architecture; Tendermint BFT consensus; bridges to non-IBC chains via bridges.
    • Anyswap/Multichain: token swapping with SMPC thresholds; cross-chain mint/burn and cross-chain calls.
    • Wormhole/Portal Bridge: message-passing via Guardians; supports multiple chains.
    • Osmosis: cross-chain AMMs using IBC with pegged bridges to non-IBC chains.
  • Permissioned (enterprise):
    • Cactus: open-source integration platform for enterprise blockchains.
    • FireFly: interoperability platform for enterprises with microservices.
    • Weaver: architecture using relays and drivers for DLTs; no need to modify existing ledgers.
    • YUI: IBC-based interoperability among Fabric, Corda, Ethereum (Besu).
    • WeCross: 2PC and HTLC-based cross-chain protocols for permissioned blockchains.

Challenges

  • Heterogeneous blockchain infrastructure
    • Permissioned vs permissionless interoperability; access control and trust assumptions differ.
    • Scripting languages: non-Turing-friendly blockchains (e.g., Bitcoin) complicate cross-chain logic.
    • Cryptographic primitives: differing signatures, hashes, and PKI make cross-chain verification harder.
  • Security and reliability
    • Real-world cross-chain bridge attacks (Poly Network, Wormhole, Hundred Finance) show systemic risk.
    • Smart contract correctness: bugs, audit gaps, and business-logic vulnerabilities still cause losses.
    • DoS and DoS-like attacks on relays or bridges.
  • Privacy and trust
    • Trustless vs trusted trade-offs affect privacy: trusted intermediaries reduce privacy.
    • Traceability concerns (e.g., same hash values across chains).
    • Data privacy across permissioned vs permissionless contexts requires careful design; adapters and TEEs are potential aids.

Conclusion and directions

  • Five-category framework provides a comprehensive lens to compare cross-chain techniques.
  • Empirical evaluation underscores that bottlenecks are largely due to base blockchains, not the interoperability method.
  • Future directions point toward native interoperability-focused blockchains (e.g., Cosmos, Polkadot) and stronger privacy-preserving and security guarantees for cross-chain protocols.