What Is Blockchain Interoperability?


Blockchain interoperability is the ability of blockchain networks to communicate with each other, sending and receiving messages, data, and tokens.

Blockchains are decentralized computer networks that track users’ account balances and data in a digital ledger. Instead of relying on a centralized authority, blockchains use decentralized consensus to collectively agree on proposed updates to the ledger before they’re accepted. The result is a new trust-minimized computing paradigm for multi-party record keeping and process automation that’s more credibly neutral, tamperproof, and transparent than traditional computing environments.

However, blockchains are akin to computers without an Internet connection—they don’t have built-in communication capabilities with other blockchains or external APIs. This limitation is commonly referred to as the oracle problem, and it not only prohibits blockchains from interacting with traditional systems but also prevents interoperability between blockchains. With the growing reality of a multi-blockchain world, blockchain interoperability protocols are critical infrastructure for exchanging data and tokens between different blockchains (i.e. cross-chain).

The following article serves as an educational primer on the definition and importance of blockchain interoperability, as well as outlines the different types of blockchain interoperability solutions and how the Cross-Chain Interoperability Protocol (CCIP), powered by Chainlink, extends the functionality of oracles to support arbitrary data messaging across chains.

What Is Blockchain Interoperability?

Blockchain interoperability refers to the ability of blockchains to communicate with other blockchains. The foundation of blockchain interoperability is cross-chain messaging protocols, which enable blockchains to read data from and/or write data to other blockchains.

Cross-chain messaging protocols support the creation of cross-chain decentralized applications (dApps), where a single unified dApp can function across multiple different smart contracts deployed across multiple different blockchains. Cross-chain dApps differ from multi-chain dApps in that a multi-chain dApp often deploys the same application on multiple blockchains, but each instance is an isolated set of smart contracts with no connection to other blockchains.

Cross-chain dApps have unified logic across smart contracts deployed on different blockchains.
Cross-chain dApps have unified logic across smart contracts deployed on different blockchains.

Cross-chain dApps that leverage cross-chain messaging protocols can be limited in scope; token bridges, for example, only exist to enable tokens on a source blockchain to be transferred to a destination blockchain. However, arbitrary data messaging protocols provide more generalized cross-chain functionality, which can support more complex dApps such as cross-chain decentralized exchanges (DEXs), cross-chain decentralized money markets, cross-chain NFTs, cross-chain decentralized autonomous organizations (DAOs), and various types of modularized applications.

The Importance of Blockchain Interoperability

The current Web3 landscape is becoming increasingly multi-chain and multi-layered. There are already more than 100 layer-1 blockchains (i.e. base-layers) and an increasing number of layer-2 and eventually layer-3 networks that exist on top of base-layer blockchains. Layer-2 and layer-3 networks are essentially separate blockchains that anchor part of their security to a base layer (e.g. rollups).

The proliferation of base layers and layer-2 networks is the result of an expressive design space for blockchain technology and blockchain ecosystems. Blockchains compete for developers and applications by optimizing their protocols to support certain feature sets—usually by making tradeoffs with other features. For instance, some blockchains focus more on decentralization and censorship resistance than throughput and composability at the base layer while other blockchains opt to build in native privacy functionality at the expense of new security assumptions in trusted hardware.

Blockchains optimize by experimenting with different consensus protocols, execution environments, and data storage solutions, which offer developers various assumptions around cost, liveness, performance, data availability, security, cryptoeconomics, and environmental impact. Furthermore, blockchains may differentiate themselves by offering support for select programming languages, focusing on capturing specific use cases and geographies, and developing unique brands and values that endear them to audiences.

One of the main differences in optimization choices revolves around a particular blockchain’s thesis on how to scale its ecosystem. Examples of scaling theses include:

  • Having a single, high-performance base-layer blockchain that supports all applications across all industry verticals.
  • Having a single, highly-decentralized base-layer blockchain that supports a wide array of modularized applications through layer-2 and layer-3 scalability networks.
  • Having each application and/or smart contract sector or use case run on its own base-layer blockchain or sovereign layer-2 network.

For a deeper dive into blockchain scalability solutions, check out the blog Blockchain Scalability: Execution, Storage, and Consensus.

Given the wide variety of blockchain ecosystems, it’s critical that all these distinct on-chain environments are able to interoperate. This is particularly important for developers wanting to build cross-chain/modularized applications that maintain a single global state and unified liquidity across numerous on-chain environments. It’s also important for application developers wanting to tap into the unique assets and features of each blockchain.

Blockchain interoperability protocols are equally important for traditional systems that need to interact with many different blockchains from their existing backends. Interoperability protocols are foundational to building blockchain abstraction layers, which allow traditional backends and dApps to interact with any on-chain environment via a single blockchain middleware solution. Without a blockchain abstraction layer, Web2 systems and dApps would need to build separate, in-house implementations for each cross-chain interaction they want to leverage—an incredibly time-consuming, resource-intensive, and complex process.

Types of Blockchain Interoperability Solutions

The best place to start when trying to classify blockchain interoperability solutions is by looking at the most popular cross-chain interactions.

Token swaps involve trading a token on a source chain and receiving a different token on a destination chain. Cross-chain token swaps are generally made possible by atomic swap protocols and/or cross-chain automated market makers (AMMs), which have separate liquidity pools on each blockchain to facilitate the swap.

Token bridges involve locking or burning tokens via a smart contract on a source chain and unlocking or minting tokens via a separate smart contract on the destination chain. Token bridges allow assets to be moved across blockchains, increasing token utility by making cross-chain liquidity possible. There are three types of token handling mechanisms that enable token bridges:

  • Lock and mint token bridges (i.e. IOU) lock tokens in a smart contract on the source chain, then wrapped versions of the tokens are minted on the destination chain, often referred to as bridged assets. In the reverse direction, the wrapped tokens on the destination chain are burned to unlock the original coins on the source chain.
  • Burn and mint token bridges (i.e. native) burn tokens on the source chain, then re-issue the same tokens by minting them on the destination chain.
  • Lock and unlock token bridges lock tokens on the source chain, then unlock the same tokens from a liquidity pool on the destination chain. These types of token bridges usually attract liquidity on both sides of the bridge via incentive programs such as revenue sharing.

Native payments involve an application on a source chain triggering a payment on a destination chain in its native asset. Cross-chain payments can also be made on the source chain in its native asset based on data from a separate blockchain. Most of these payments often represent some form of settlement, and can be based on blockchain data or even external events.

Contract calls involve a smart contract on a source chain calling a smart contract function deployed on a destination chain, potentially based on data originating on the source chain. Several contract calls can be combined to form a more complex cross-chain application, which may involve token swaps and bridging.

Programmable token bridges involve a combination of token bridging and arbitrary messaging, wherein a contract call can be executed as soon as tokens are delivered to the destination chain from the source chain. This happens in a single transaction, enabling richer cross-chain functionality, such as staking, swapping, or depositing tokens into a smart contract on the destination chain as part of completing the bridge function.

To support these cross-chain interactions, there are four general interoperability solutions for validating the state of a source blockchain and relaying the subsequent transaction to the destination blockchain. Both of these functions—state verification and relays—are key to completing most cross-chain interactions.

Web2 Validation

Web2 validation is when someone uses a Web2 service to execute a cross-chain transaction. The most common example in practice is users leveraging centralized exchanges to swap or bridge their own tokens. The user simply deposits their assets into an address on the source chain that’s under the control of the exchange and then withdraws the same tokens or different tokens (via a swap on the exchange) to an address on a destination chain controlled by the user.

Web2 validation can be fairly convenient for personal transactions and requires less technical expertise. However, it’s not as useful for supporting cross-chain applications and requires trust in a centralized custodian. Furthermore, it’s predominantly limited to swapping and bridging tokens to and from blockchains that the exchange supports.

External Validation

External validation is when a set of validator nodes separate from those of either blockchain involved in the cross-chain interaction are used to validate the state of the source blockchain and trigger the subsequent transaction on the destination chain once a specific set of criteria is met. While there are many approaches to committee-based consensus—i.e., multi-party computation, decentralized oracle networks, threshold multi-signature contracts—they all involve validator nodes doing trust-minimized off-chain computation that’s authenticated on-chain (i.e. hybrid smart contracts).

External validation typically requires an honest majority assumption, wherein a majority of the external validator nodes must behave honestly in order for the integrity of the cross-chain interaction to be upheld. However, additional techniques can be utilized to increase trust-minimization, such as optimistic bridge validation, risk management networks, and cryptoeconomic staking. Despite an additional trust assumption, external validation is currently the only practical way to perform cross-chain contract calls between certain types of blockchains while still providing trust-minimized guarantees. It’s also a highly generalized and extensible form of cross-chain computation, capable of supporting more complex cross-chain applications.

Local Validation

Local validation is when the counterparties in a cross-chain interaction verify the state of one another. If both deem the other valid, the cross-chain transaction is executed, resulting in peer-to-peer cross-chain transactions. Cross-chain swaps using local validation are often referred to as atomic swaps.

Local validation via atomic swaps has a high level of trust-minimization given reasonable blockchain assumptions, as the swap either happens or both transactions fail. However, it’s not very generalizable to a variety of cross-chain contract calls, and comes with tradeoffs like the inadvertent call option problem—a situation where the second party in an atomic swap can either act or not act on the swap, giving them an inadvertent call option for a certain period of time. Thus, local validation is mostly used in cross-chain liquidity protocols involving liquidity pools that exist independently on each chain.

Native Validation

Native validation is when the destination blockchain in a cross-chain interaction verifies the state of a source blockchain to confirm a transaction and then executes a subsequent transaction on its own chain. This is typically done by running a light client of the source chain in the virtual machine of the destination chain or running them both side-by-side.

Native validation relies on an honest minority or synchronous assumption, where at least one honest relayer must exist within a committee (i.e. honest minority), or the user must relay their own transaction if the committee fails (i.e. synchronous assumption). Native validation is the most trust-minimized form of cross-chain communication, but it is more expensive, offers less development flexibility, and is more suited to blockchains with similar state machines, such as between Ethereum and EVM-based layer-2 networks or only amongst Cosmos SDK-based blockchains.

The Cross-Chain Interoperability Protocol (CCIP)

In order to accommodate the growing ecosystem demand for blockchain interoperability solutions, Chainlink is currently developing the Cross-Chain Interoperability Protocol (CCIP)—a new global standard for cross-chain communication, including arbitrary messaging and token transfers. CCIP aims to establish a universal connection between blockchain networks via a single, simple and elegant interface. In addition, it aims to integrate with a variety of other oracle services within a programmable token bridge framework to support highly complex cross-chain interactions.

Given the growing number of cross-chain exploits—approximately $1.2B USD in value lost in the past year—a security-first mindset is being applied to CCIP. Its development is being supported by some of the best cryptography and computer security experts in the world, including Ari Juels, Dan Boneh, Lorenz Breidenbach, and Dahlia Malkhi. Some of the security enhancements being applied to CCIP include a Risk Management Network that monitors for malicious activity, decentralized oracle computation from a wide range of high-quality node operators with verifiable on-chain performance histories, and the off-chain reporting (OCR) protocol, which has already secured hundreds of billions of dollars on blockchain mainnets.

To learn more about Chainlink CCIP, check out this blog https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/.

CCIP architecture
CCIP is a cross-chain messaging protocol powered by Chainlink decentralized oracle networks that plans to support a variety of cross-chain dApps, token bridges, and programmable tokens bridges.

Growing Web3 Through Blockchain Interoperability

Blockchain interoperability is a big part of the next frontier of the ever-evolving Web3 landscape. Interoperability protocols like CCIP can not only help unlock complex applications that function as a unified entity across many blockchains, but they can help empower enterprises, institutions, and governments to securely access any on-chain environment from a single interface. Both functions will be key in developing next-generation dApps that are accessible through more traditional user interfaces, accelerating the rate of Web3 adoption.

To learn more about Chainlink, visit the Chainlink website and follow the official Chainlink Twitter to keep up with the latest Chainlink news and announcements.

Learn more about blockchain technology

Get the latest Chainlink content straight to your inbox.