PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey on Blockchain Interoperability: Past, Present, and Future Trends

Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, Miguel Correia

arXiv:2005.14282v3cs.DCcs.CR

TL;DR

The survey examines the current landscape of blockchain interoperability solutions. It compares 80 documents covering 45 solutions and identifies differentiated suitability across private and public blockchains, while highlighting fork-related limitations.

  • Problem

    The survey asks what the current landscape of blockchain interoperability solutions is.

  • Method

    The authors compared and discussed 80 documents corresponding to 45 blockchain interoperability solutions.

  • Results

    Trusted relays and blockchain-agnostic protocols appear suitable for linking private blockchains, while sidechain and smart-contract-based protocols suit interoperability among public blockchains.

  • Takeaways & Limitations

    Blockchain of Blockchains and Hybrid Connectors support interoperability between blockchains and other distributed ledger technologies and enterprise systems.

  • Takeaways & Limitations

    Most Hybrid Connector solutions do not support hard forks, and forks remain an open issue that can affect cross-chain dApp dependability.

Abstract

from arXiv · show

Blockchain interoperability is emerging as one of the crucial features of blockchain technology, but the knowledge necessary for achieving it is fragmented. This fact makes it challenging for academics and the industry to seamlessly achieve interoperability among blockchains. Given the novelty and potential of this new domain, we conduct a literature review on blockchain interoperability, by collecting 262 papers, and 70 grey literature documents, constituting a corpus of 332 documents. From those 332 documents, we systematically analyzed and discussed 80 documents, including both peer-reviewed papers and grey literature. Our review classifies studies in three categories: Cryptocurrency-directed interoperability approaches, Blockchain Engines, and Blockchain Connectors. Each category is further divided into sub-categories based on defined criteria. We discuss not only studies within each category and subcategory but also across categories, providing a holistic overview of blockchain interoperability, paving the way for systematic research in this domain. Our findings show that blockchain interoperability has a much broader spectrum than cryptocurrencies. The present survey leverages an interesting approach: we systematically contacted the authors of grey literature papers and industry solutions to obtain an updated view of their work. Finally, this paper discusses supporting technologies, standards, use cases, open challenges, and provides several future research directions.

1 INTRODUCTION

Blockchain interoperability addresses fragmentation across heterogeneous blockchains and the resulting data and value silos. This survey maps the field, evaluates interoperability requirements and use cases, and extends prior reviews through broader coverage and updated industry information.

  • Motivation: Blockchain diversity creates fragmentation, with immature solutions and interoperability gaps producing data and value silos.Different blockchains reflect varying use cases, capabilities, security risks, and maturity levels.
  • Motivation: Interoperability can support portability, scalability, privacy, and new business opportunities across blockchain systems.The paper gives cross-chain asset transfers and cross-blockchain decentralized applications as examples.
  • Research questions: The survey asks about the current industry and academic landscape, satisfied technological requirements, and real use cases for blockchain interoperability.These questions organize the paper’s investigation of the emerging research area.
  • Contributions: The survey identifies use cases, challenges, standards, and future research directions to provide a foundation for systematic work in the field.Its stated aim is to offer a solid and comprehensive starting point for researchers.

2 BACKGROUND

Blockchains are distributed systems that maintain shared state through consensus, but they differ substantially in architecture, governance, incentives, and access models. Cross-blockchain communication is difficult because chains cannot readily verify one another’s state, motivating interoperability definitions and trust mechanisms.

  • Blockchain foundations: A blockchain maintains a shared distributed-ledger state through nodes and a consensus algorithm that establishes agreement despite faults.Consensus also shapes node behavior, communication, and each blockchain’s security assumptions.
  • Blockchain foundations: Bitcoin uses Proof-of-Work, whereas Hyperledger Fabric uses modular endorsement-based consensus and typically offers higher throughput with weaker fault assumptions.The figure contrasts a permissionless blockchain, Bitcoin, with the permissioned Hyperledger Fabric.
  • Blockchain foundations: Blockchains may be permissionless or permissioned, with Bitcoin and Ethereum exemplifying the former and Fabric, Corda, Quorum, Tendermint, and Multichain the latter.Permissioned systems authenticate users and apply governance models suited to enterprise and governmental needs.
  • Cross-blockchain communication: Cross-blockchain communication involves a source blockchain initiating a transaction and a target blockchain executing it.The source blockchain is the ledger where the transaction begins.
  • Interoperability definitions: The survey concludes that practical cross-blockchain transactions require a trusted third party or decentralized trust anchor to assure protocol correctness.Trust assumptions vary between permissionless and permissioned networks, but the reviewed solutions generally include at least one decentralized trust anchor.

3 RELATED LITERATURE REVIEWS

Earlier literature reviews cover important interoperability mechanisms but leave parts of the broader landscape insufficiently integrated. This survey positions itself as a holistic review spanning public connectors, Blockchain of Blockchains, Hybrid Connectors, private interoperability, standards, use cases, and open issues.

  • Prior surveys: Because blockchain interoperability is novel and broad, few updated surveys comprehensively cover both academic and industrial solutions.Existing reviews address different subsets of the solution space.
  • Comparison framework: This paper compares related reviews using criteria covering Public Connectors, Blockchain of Blockchains, Hybrid Connectors, architectures, standards, cross-comparison, use cases, and open issues.The comparison distinguishes fulfilled, partially fulfilled, and unfulfilled criteria.
  • Prior surveys: Many prior surveys focus on Public Connectors, especially notary schemes, sidechains, and hash-time-locking techniques.Other reviews organize solutions around sidechains, blockchain routers, smart contracts, and related mechanisms.
  • Prior surveys: Some earlier work addresses interoperability architectures, Blockchain of Blockchains, or Hybrid Connector solutions, but coverage remains distributed across reviews.The cited surveys differ in their architectural and solution emphases.
  • Contribution: Its distinctive scope combines updated grey literature with private-blockchain interoperability and a holistic comparison across connectors and Blockchain of Blockchains.The authors present this broader scope as a contrast with most previous work.

4 BLOCKCHAIN INTEROPERABILITY FRAMEWORK

The Blockchain Interoperability Framework classifies solutions through six questions and detailed criteria covering assets, control, ledgers, timing, and transaction realization. It also distinguishes implementation, correctness, trust, and flexibility dimensions, including private–private and public–private interoperability.

  • Framework design: The Blockchain Interoperability Framework classifies solutions using Who, What, Where, When, and How; Why is excluded because its purpose is constant.The framework evaluates how solutions connect chains, blockchains, and arbitrary systems such as enterprise legacy systems.
  • Evaluation criteria: The “what” criterion identifies the data objects or assets exchanged, including arbitrary data, fungible assets, non-fungible assets, and regulated tokens.The survey treats asset tokens as standardized and regulated when emitted by legal entities.
  • Evaluation criteria: The “who” criterion captures control over cross-chain transactions and the resulting trust establishment, ranging from end-users and consortia to trusted third parties.Some solutions permit different levels of control.
  • Evaluation criteria: The “where” criterion records source and target ledgers, public or non-public systems, communication direction, and whether on-chain or off-chain channels support settlement.On-chain channels are described as more resilient, while off-chain channels are more scalable.
  • Evaluation criteria: The “when” criterion distinguishes design-time customization from flexible run-time changes to business logic and transaction conditions.Run-time customization allows end-users to adjust conditions that trigger cross-chain transactions.
  • Scope: Unlike most literature reviews, the survey includes private–private and public–private interoperability and focuses on flexible approaches.It explicitly expands beyond design-time approaches and public blockchains.
  • Evaluation criteria: The “how” criterion covers cross-claim, escrowed, and mediated transaction mechanisms, trust trade-offs, testing, formal correctness, verification, and open-source implementation.The survey states that lower centralization in settlement entails worse performance but lower risk.

5 OVERVIEW OF BLOCKCHAIN INTEROPERABILITY APPROACHES

The survey organizes interoperability approaches into Public Connectors, Blockchain of Blockchains, and Hybrid Connectors, revealing distinct capabilities and trade-offs across security, flexibility, decentralization, and performance.

  • Public Connectors: Sidechains trade security and decentralization against performance, while strong security can slow settlement and reduce liquidity.RSK takes approximately 100 Bitcoin blocks, around 15 hours, to convert BTC to RBTC.
  • Public Connectors: HTLC-based connectors provide programmable escrows and enable trades without a direct connection, but timelocks can retain capital and create unfair trade conditions.HTLCs can support practical asset transfers across public blockchains and some private-blockchain settings.
  • Public Connectors: Public Connectors support cryptocurrency trades and transfers of fungible and non-fungible assets across public blockchains.The survey identifies them as the best approach for these supported uses.
  • Blockchain of Blockchains: Blockchain of Blockchains solutions provide shared infrastructure but differ in security, customization, validator scale, and throughput.Polkadot offers shared security with less customization, whereas Cosmos is more loosely coupled and flexible.
  • Blockchain of Blockchains: Polkadot supports around 1000 transactions per second, Cosmos can reach up to dozens of thousands of transactions per second with two validators, and ARK around 18.5 transactions per second.These are reported theoretical or current figures under the stated configurations.
  • Hybrid Connectors: Cross-blockchain interoperability generally relies on bridges or adapters routing transactions between particular blockchain types.Permissioned solutions are less flexible, and some interoperating networks require prior knowledge of identities and configurations.
  • Blockchain of Blockchains: Blockchain engines do not interoperate with each other, constraining users to a single engine and limiting resource leverage.Some approaches are not universally accepted, may be centralized, and require SDK access to core functionality.
  • Hybrid Connectors: Hybrid and blockchain-agnostic connectors target existing and future blockchains, but often lack backward compatibility or flexible business-logic definition.Hyperledger Cactus could transition relay models from trusted toward semi-trusted or trustless operation.

6 DISCUSSION, USE CASES AND RESEARCH QUESTIONS

The survey frames blockchain interoperability as broader than token exchange and organizes solutions into Public Connectors, Blockchain of Blockchains, and Hybrid Connectors. It finds differentiated strengths and limitations across these categories, while identifying standardization and cross-domain integration as continuing priorities.

  • Supporting Technologies and Standards: The survey identifies scant standardization of messages, data formats, and flows, while cross-blockchain use cases and infrastructure technologies support further standards development.
  • Discussion: Blockchain interoperability is no longer limited to token exchanges between homogeneous blockchains.
  • Public Connectors: Public Connectors are widely cited because they address practical asset-transfer problems, although early solutions may not succeed.
  • Public Connectors: Sidechain and smart-contract-based escrow protocols are identified as suitable for interoperability among public blockchains, balancing flexibility, decentralization, and security.
  • Blockchain of Blockchains: Blockchain of Blockchains platforms provide built-in interoperability among instances of the same platform, but can tie users to specific implementations and create data or value silos.
  • Hybrid Connectors: Hybrid Connectors, including blockchain migrators and blockchain-agnostic protocols, support user-centric connections across blockchains, enterprises, and other distributed ledger technologies.

7 RESEARCH DIRECTIONS

The survey identifies open research directions spanning interoperability architectures, connector categories, supporting technologies, standards, use cases, and security. It emphasizes semantic and organizational interoperability, compatibility with existing ledgers, and stronger guarantees for cross-blockchain applications.

  • Blockchain of Blockchains: Research should improve interoperability between permissioned and permissionless blockchains, including bidirectional connections and integration with existing systems.
  • Architecture for Blockchain Interoperability: An interoperability maturity model should represent technical, semantic, and organizational layers.
  • Architecture for Blockchain Interoperability: Stakeholder-specific views and view integration should be studied to align technical and semantic interpretations across blockchains.
  • Hybrid Connectors: Future work should strengthen connector designs through non-trusted migration, decentralized trust, ledger adaptation, atomicity, consistency, and multi-blockchain management.
  • Supporting technologies and standards, use cases, and others: Standards, programming languages, tools, identifiers, credentials, and enterprise interoperability frameworks require further research and development.
  • Supporting technologies and standards, use cases, and others: The survey calls for new multi-blockchain use cases, cross-category synergies, security studies, and analysis of value, semantic, and organizational interoperability layers.

8 CONCLUSION

The conclusion synthesizes 80 analyzed documents and 45 interoperability solutions across three categories. It finds that interoperability extends beyond cryptocurrency-focused approaches, with Hybrid Connectors covering varied use cases and Blockchain of Blockchains likely to see near-term industry adoption.

  • 80 documents covering 45 solutions were analyzed and discussed across Public Connectors, Blockchain of Blockchains, and Hybrid Connectors.
  • Blockchain interoperability extends beyond Public Connectors, with Hybrid Connectors offering solutions adapted to many use cases.
  • Blockchain of Blockchains are likely to be adopted by industry in the short-medium term by leveraging easy-to-produce, customizable blockchains.
  • The findings indicate that conditions for blockchain interoperability research are fulfilled and that many new use cases may emerge.
  • The study aims to provide a robust starting point that eases work for blockchain developers and researchers.

A METHODOLOGY

The paper conducts a systematic literature review using staged planning, screening, data abstraction, correlation, and synthesis, with special attention to grey literature and author feedback. It acknowledges that the rapidly evolving field and imperfect grey-literature coverage may leave advances unreported.

  • The review follows planning, screening, data abstraction, intra- and inter-category correlation, reporting, and synthesis phases.
  • Grey literature was included to broaden coverage of recent blockchain interoperability work and reduce publication bias.
  • The researchers used recent whitepaper versions, searched documentation for updates, and contacted project authors for feedback.
  • Grey literature included Github documentation, whitepapers, technical and institutional reports, coin-offer plans, articles, dissertations, consultant reports, book chapters, and blog posts.
  • The review recognizes that newer advances may have been missed because blockchain interoperability is fragmented and rapidly evolving.
  • The research questions address the landscape of interoperability, technological prerequisites, and real use cases for interoperable value chains.

A.2 Data Sources

The review primarily uses Google Scholar because of its broad computer-science coverage and inclusion of grey literature. It supplements this search with curated terms and references while acknowledging concerns about citation-count bias.

  • Google Scholar was selected as the main repository because it offers broad computer-science coverage and meets systematic-review guidance.
  • Its indexed sources include major digital libraries, repositories, journals, conferences, theses, books, preprints, technical reports, patents, and other scholarly literature.
  • Google Scholar’s inclusion of grey literature was considered useful for reducing publication bias.
  • The review acknowledges criticism that Google Scholar gives excessive importance to citation counts but relies on it to maximize coverage.
  • The researchers supplemented database searching with literature-informed search terms, known projects, researcher suggestions, and additional references.

A.3 Search Process

The review used a three-phase search and screening process covering peer-reviewed and grey literature. It narrowed 404 collected documents to 102 eligible documents, of which 67 were systematically compared.

  • Search phases: The search process comprised three phases: prior literature reviews, peer-reviewed papers, and grey literature.The authors also used snowballing to expand the repository during grey-literature collection.
  • Scope and eligibility: The review excluded blockchain-sharding research because its breadth exceeded the study’s scope and available space.The authors acknowledged that sharding may foster interoperability because shards need to communicate.
  • Search phases: 86 results from survey-focused queries yielded only one explicitly identified literature review concerning blockchain interoperability.The queries included “interblockchain survey,” “blockchain interoperability survey,” and “IoB.”
  • Search phases: 262 results were obtained from keyword searches covering blockchain interoperability, interchain communication, and interconnected blockchain.The authors excluded broader terms such as multiple blockchains or chain interoperability because they were too vague and produced many unrelated results.
  • Scope and eligibility: 404 documents were collected before exclusions removed 178 unrelated papers, 10 duplicates, 16 irrelevant papers, and 98 support papers.Support papers aided understanding but were not included in solution comparisons.
  • Scope and eligibility: 102 documents remained after screening, with 67 systematically compared.Screening examined titles, abstracts, and keywords first, followed by full texts when necessary.

B AN ARCHITECTURE FOR BLOCKCHAIN INTEROPERABILITY

The proposed architecture treats blockchains as autonomous systems communicating through cross-blockchain protocols, gateways, registries, and cross-chain applications. It distinguishes interoperability layers while recognizing substantial adaptation requirements for existing blockchains.

  • Architecture: The Internet of Blockchains architecture uses gateways and optional decentralized registries to identify and address blockchains, oracles, and related components.A registry can be implemented through a public blockchain, a stakeholder-maintained blockchain, trusted hardware, or a multisignature smart contract.
  • Architecture: Each blockchain is modeled as an autonomous system that communicates with others through a cross-blockchain protocol.Most nodes on public and private blockchains can serve as interoperability gateways.
  • Architecture: The architecture connects public, private, and heterogeneous blockchains through CCCP or CBCP protocols and a cross-chain decentralized application.The example includes Ethereum, POA Network, Bitcoin, Hyperledger Fabric, and Quorum, with unilateral or bidirectional interoperability depending on the protocol.
  • Architecture: A cross-chain dApp can connect multiple blockchains and thereby form an Internet of Blockchains and enable a Blockchain of Blockchains.Access to private blockchains assumes that users hold credentials such as private keys or X.509 certificates.
  • Limitations and deployment: Existing blockchains are generally incompatible with standardized cross-chain protocols and may require refactoring across network, consensus, contract, and application layers.The network layer is likely to require refactoring, with consensus changes potentially needed because transaction finality differs across blockchains.
  • Interoperability layers: The ArchiMate model represents technical and semantic interoperability as capabilities, while cross-chain protocols realize cross-chain transactions.Other interoperability layers are left for future work.
  • Limitations and deployment: Because adapting production blockchains is not feasible in the short term, interoperability solutions are typically tailored to specific blockchains or blockchain sets.The authors expect maturing standards to guide technical efforts toward convergence.

C.2 Notary Schemes

Notary schemes mediate cryptocurrency exchanges through custodial or decentralized arrangements. Centralized exchanges simplify acquisition but expose custodial assets to attacks, whereas decentralized exchanges avoid private-key disclosure and its associated single point of failure.

  • Centralized exchanges: 237 centralized exchanges versus 22 decentralized exchanges were listed by CryptoCompare at the time of writing.The comparison describes centralized exchanges as the commonly used notary scheme.
  • Centralized exchanges: Centralized exchanges acquire cryptocurrencies for users and credit the assets to exchange-owned custodial wallets.Users typically purchase assets with fiat currency, while exchanges may acquire them directly or through intermediaries.
  • Centralized exchanges: Attacks on exchanges have led to the loss of very large cryptocurrency sums.The paper presents this as a risk of the otherwise simple centralized-acquisition model.
  • Decentralized exchanges: Decentralized exchanges let users exchange assets without typically disclosing private keys, eliminating the single point of failure inherent in centralized exchanges.Examples include Nash, AtomicDEX, and IDEX; hashed timelocks are one implementation technology.
  • Other notary schemes: Agent Chain uses a multisignature trading group as a deposit pool and adds arbitration for malicious trading groups.The scheme locks deposited tokens while several trading operators manage the group.

C.3 Hashed Time-Locks

Hashed time-lock and related approaches support cross-chain asset exchange through atomic swaps, escrow, distributed keys, and claim-first protocols. The surveyed designs emphasize direct transfers, decentralized control, and mechanisms for consistency or failure tolerance.

  • Atomic swaps: Atomic swaps use hashed time-lock contracts to exchange assets directly between users on different blockchains.COMIT supports exchanges such as Bitcoin for Ether or ERC-20 tokens through several asset-specific protocols.
  • Notary and custody variants: Wanchain uses vouchers, validators, and storeman nodes to verify source transactions, register assets, and manage locked accounts.Its decentralized notary model distributes validation and custody functions across several node roles.
  • Hybrid approaches: Escrow-based approaches use third parties or smart contracts to regulate transactions while holding collateral from one party.Some combined approaches use sidechains, escrow parties, distributed private keys, or collateralization with hashed time-lock contracts.
  • Relay-based approaches: Relay-based cross-blockchain solutions can incur high operating costs, while later optimizations reduce those costs.The discussed prototype uses simplified payment verification and token incentives.
  • Cross-chain token protocols: DeXTT provides eventual consistency of asset balances across blockchains through claim-first transactions and observers.Deterministic witnesses assign rewards when multiple observers compete to propagate transfers.
  • Cross-chain token protocols: One Proof of Intent from a source wallet is valid at each time, eliminating double-spends.The protocol requires sender and recipient authorization through countersigned transfer transactions.
  • Cross-chain token protocols: DeXTT tolerates blockchain failures as long as at least one blockchain remains functional.The design is presented as a cross-blockchain token transfer approach within the TAST project.

D BLOCKCHAIN OF BLOCKCHAINS

The survey presents Blockchain of Blockchains as interoperability architectures centered on shared infrastructure, bridge-hubs, or interconnecting chains. Polkadot and Ethereum 2.0 use shared security and sharding, while Cosmos uses a bridge-hub architecture that is more difficult to scale.

  • Polkadot: Polkadot’s relay chain coordinates parachain transactions: collators forward transactions to validators, which validate blocks before adding them to the relay chain.
  • Cosmos: Cosmos uses sovereign zones connected through its network stack, with the Cosmos SDK supporting applications and Tendermint BFT providing consensus.Cosmos originally focused on asset tokens but now supports arbitrary data transfers.
  • Other blockchain-of-blockchains solutions: ARK’s smart bridges support communication among ARK chains and between blockchains using different consensus mechanisms.ACES demonstrated two-way transfers involving ARK, Bitcoin, Litecoin, and Ethereum, including smart-contract issuance from ARK to Ethereum.
  • Other blockchain-of-blockchains solutions: ARK’s ACES remains ad hoc, requires connectors for other blockchains, and depends on intermediary nodes, while ARK itself is proprietary and not open-source.
  • Polkadot and Ethereum 2.0 use shared-security/sharded interoperability, whereas Cosmos relies on a bridge-hub architecture.The survey associates the shared-security/sharded approach with better scalability and the bridge-hub approach with scaling challenges.
  • 14 solutions comprise 3 trusted relays, 4 blockchain-agnostic protocols, 4 blockchain of blockchains, and 3 blockchain migrators.

E.1 Trusted Relays

Trusted-relay and connector approaches redirect or route cross-blockchain requests through intermediary mechanisms, often using proofs, policies, or common interfaces. The survey also notes trust, implementation, and scalability limitations across representative solutions.

  • Trusted relays: Trusted relays redirect transactions from a source blockchain to a target blockchain and translate network-neutral messages into target-specific transactions.
  • Evaluation boundaries: Some proposed interoperability protocols remain weakly validated: one evaluation uses custom-made blockchains, and another provides no implementation details.
  • Trusted relays: Relayers may require verifiable proofs for requests but remain trusted because they are assumed not to suffer Byzantine faults.
  • Trusted relays: System contracts and verification policies manage data exposure and validate cross-network requests, distributing trust across transactions.
  • Blockchain-agnostic protocols: Overledger uses a common interface and four layers to retrieve, filter, order, and connect information from heterogeneous blockchains.Its filtering layer requires knowledge of all included blockchains, and its ordering mechanism supports total ordering of cross-blockchain transactions.
  • Blockchain-agnostic protocols: Overledger’s filtering requires knowledge of all included blockchains, while its message-oriented middleware resembles two-phase commit without detailed specification.

F USE CASES

The survey identifies interoperability use cases spanning payments, exchanges, data sharing, enterprise systems, and blockchain migration. These applications address cross-organizational data needs, vendor lock-in, security, and flexibility in blockchain choice.

  • Interoperability supports cross-chain payment channels, multi-party swaps, point-of-sale and utility tokens, and decentralized exchanges.
  • Decentralized exchanges: Hashed timelock contracts can enable decentralized exchanges where users exchange assets from different blockchains directly.
  • Blockchain-of-blockchains use cases: Polkadot and Cosmos ecosystems implement decentralized exchanges, while Polkadot also supports blockchain gaming platforms and stablecoins.
  • Migration and enterprise use cases: Blockchain migration lets stakeholders move assets, including data and smart contracts, between blockchains, supporting flexibility and reducing vendor lock-in.
  • Data and enterprise use cases: Interoperability use cases include healthcare data sharing with access control, food traceability, end-user wallet access control, and stablecoin pegging.
  • Security and dependability: A blockchain-of-blockchains approach is proposed as a cloud-of-clouds layer that could improve service dependability and security over individual providers.The cited discussion frames this as a possibility for addressing accidental failures and internal data breaches.
Loading 2005.14282v3…