Decoding Interoperability Solutions

Understanding blockchain interoperability

In the context of blockchains, interoperability is the ability of different blockchain networks to communicate. Cross-chain message passing is the foundation of blockchain interoperability that allows different chains to read data from and/or write data to other blockchains.

A cross-chain message passing protocol can allow you to build a cross-chain DApp, where a single, smart contract logic orchestrates various actions across multiple smart contracts on different blockchains. While “cross-chain DApps” and “multi-chain DApps” are sometimes used interchangeably, they do not mean the same thing.

With multi-chain DApps, you will need to deploy the same application on multiple blockchains, with each instance of the deployed DApp consisting of isolated smart contracts that do not have any connection to other chains. Multi-chain DApps give users more options when selecting which blockchain networks they want to use for a particular scenario.

For example, Uniswap was initially deployed on the Ethereum network to allow users to exchange ERC-20 tokens. It has since been deployed on other blockchain ecosystems, such as Polygon, BNB Smart Chain (BSC), Celo, and Optimism, with similar smart contracts deployed on these chains.

Unlike multi-chain DApps that do not share logic and liquidity across different chains, cross-chain DApps operate as single entities spanning multiple blockchains. Users can transfer generalized messages, such as data, tokens, and commands, between different on-chain environments.

For example, you can have a cross-chain lending protocol where users lend and borrow on different chains. Such a platform can, for example, allow users to borrow tokens on the Ethereum network and use them as liquidity on BSC by facilitating cross-chain transfer of borrowed tokens.

What are the key considerations when evaluating blockchain interoperability platforms?

The current Web3 landscape has increasingly become multi-layered and multi-chain. As of this writing, we already have over 50 Layer-1(L1) chains and an increasing number of Layer-2(L2) networks. The proliferation of L1s and L2s within the Web3 space results from an expressive design thesis that intends to scale the ecosystem. Three hypotheses explaining the design choices include:

• Having a single, high-performance L1 blockchain that supports DApps across all the industry verticals (i.e., one scalable blockchain to rule them all).

• Having a single, highly decentralized L1 blockchain that supports a wide variety of modularized DApps operating on L2s 9 (i.e., one highly decentralized blockchain to rule them all).

• Having each DApp, smart contract, or use case run on its own L1 blockchain or sovereign L2 chains.

The above hypotheses outline the reality of a multi-chain crypto world, which makes cross-chain smart contract function calls not just a prudent move but a strategic imperative for dApp developers. From a technical standpoint, interoperability solutions need to consider the following requirements:

• Application Programming Interfaces (APIs)
  All interoperability platforms rely on APIs, a software piece that enables two heterogeneous applications to connect. Simply put, APIs allow one application to CRUD (Create, Read, Update, and Delete) data into another application. In Web3, an API facilitates interoperability by allowing one DApp on chain A to send a message to another chain, say B. For example, you could have one DApp on chain A querying transactions or watching smart contract events from chain B.

  However, it is worth noting that the way Web2 APIs work differs from Web3 APIs. First, Web3 APIs can create, read, and even submit reversed transactions, but the blockchain’s ledger is immutable. Once validators append their blocks to the ledger, no one can alter or delete it.

  Secondly, Web3 APIs require a waiting period before you can confidently view a valid response, especially when dealing with a permissionless blockchain. This is because, unlike traditional databases, permissionless blockchains are secured by a network of distributed validators that must agree on the ledger’s next state.

  In such a scenario, one blockchain, say A, that wants to read data from another chain, say B, must ensure that it fetches valid data. For example, to confidently query a Proof-of-Work (PoW) chain like Bitcoin, you must wait at least one hour (i.e. until the transaction is six blocks deep).

• Blockchain interconnectivity architecture
  There are three common approaches for connecting two or more chains:

  • One-time asset pass: Here, an asset is “destroyed” on the source chain before being “recreated” on the target network. Since crypto assets are immutable, you must “lock” or “burn” the asset on the source chain before exporting and “unlocking” or “minting” an equivalent asset (usually a wrapped token) on the target network.

  • Oracle solutions. A cross-chain oracle service provides a one-way data read from one blockchain to another. The term oracle refers to third-party service data required to perform some operation on a target chain. Bitcoin (BTC) Relay is one of the earliest forms of cross-chain oracles that leveraged Bitcoin’s Simple Payment Verification (SPV) protocol to store Bitcoin’s block headers inside the Ethereum network. This solution allowed Ethereum ecosystem users to pay for transactions with bitcoins.

  • Cross-chain transaction processing: Unlike one-time asset pass or oracle solutions, cross-chain transaction processing — also called two-way pegs — allows two or more chains to coordinate operations whenever data or messages need to move between them. Cross-chain transaction processing is considered the holy grail of blockchain interoperability, as the other two are relatively simple to implement.

• Interoperability strategies
  One-time asset pass, cross-chain oracle solutions, and cross-chain transaction processing are the three ways to architect interconnectivity between blockchains. Moving value from one chain to another introduces a trust issue in all of these solutions.

  For example, the two users must find a way to trust that their transactions will be executed atomically on the two chains. For most of the interoperability platforms that we have seen so far, this trust is provided by custodians. In 2016, Vitalik Buterin — Ethereum’s co-founder — described three strategies for blockchain interoperability:

  • Hash Time-Locked Contracts (HTLCs)
    At the core of HTLCs are two primitives that ensure cross-chain operations remain atomic: hash locks and time locks. Although the mechanics of HTLC implementation may differ from one protocol to another, the overall concept of cross-chain communication remains the same.

    Let us consider a user, such as Alice, that wants to send some funds to Bob:

    • Alice creates a hashed, time-locked contract address. She then deposits the money she wants to transfer to Bob in it.

    • Alice generates a key — also called “preimage” — and hashes it. This key is what Alice and Bob use to unlock the transaction on both chains.

    • Alice sends the generated preimage to Bob.

    • Bob can use the key (preimage) to claim the money Alice has sent, provided he meets the deadline set in the HTLC.

    • If Bob does not claim the funds within the stipulated time, the funds are automatically returned to Alice.

    One primary benefit of using HTLCs is that they do not introduce any trust assumptions. However, they suffer from three main drawbacks.

    First, they require the parties to be always online. For example, both Alice and Bob need to monitor the relevant blockchain networks to meet the stipulated timelines set in the HTLC.

    Second, HTLCs are inefficient to carry out. For example, the source and destination chains require four transactions (two on each chain) for every cross-chain swap.

    Third, their scalability is in question because of the high gas fees and waiting times involved.

  • Notaries
    Under this strategy, a single party or multiple parties coordinate to perform cross-chain operations. To operationalize notaries as interoperability strategies, each notary needs to operate a full client for all the blockchains to which it connects to attest to cross-chain transactions.

    Notaries can incorporate single or multiple custodians on the connected chains depending on the level of trustless required. For example, a single custodian will largely operate with centralized exchanges (CEXs), while multiple custodians can be leveraged in a cross-chain bridge.

  • Sidechains
    Sidechains are largely sovereign blockchains that are compatible with a single mainnet. Each sidechain can have its own consensus mechanism, use case, tokens, and security parameters. Cosmos and Polkadot are two major protocols that use this model to offer interoperability. In a Cosmos ecosystem, many independent chains — called zones — can transfer value with each other via inter-blockchain communication (IBC) protocol.

    Users can transfer tokens from one zone to another through the Cosmos Hub, which tracks each zone’s total value of coins. Polkadot has a similar structure to Cosmos, albeit with slight differences. Sovereign chains — also called parachains — use bridges to connect to the Relay Chain. Parachains can also communicate through a cross-chain messaging (XCM) protocol. However, Cosmos and Polkadot networks are largely isolated ecosystems despite these functionalities.

    While the sidechain concept is noble and has gained prominence, it is worth noting that it does not solve current interoperability challenges directly. For example, a bridge or other mechanism is required to connect Cosmos- or Polkadot-based chains to legacy blockchains.

    Ultimately, each of these broad interoperability strategies has its own strengths and weaknesses regarding trust assumptions, technical complexity, and use cases.

Review of selected interoperability platforms

In this section, we’ll discuss three essential interoperability players, why they fall short of delivering seamless cross-chain capabilities, and how Analog closes that gap.

• Axelar
  Axelar Network is an early example demonstrating the power of a cross-chain messaging protocol built on top of a sovereign chain. It provides a uniform cross-chain messaging solution — also called General Message Passing (GMP) protocol — that developers can leverage to connect to any supported chain without changing their DApp’s logic or UIs.

  Like Axelar, Analog Network’s GMP is also built on top of a sovereign chain — what we are calling the Timechain — with a diverse and distributed set of validators. In addition, both platforms provide a multi-layered security architecture incorporating threshold cryptography and consensus algorithm for the sovereign chain.

  Analog Network provides a customizable security architecture, that allows DApp developers to select the number of validators they would like to participate in validating cross-chain transactions depending on the security requirements for their applications.

  The Timechain also serves as a springboard for the Timegraph — a Web3 data infrastructure protocol that any user or application can query via an intuitive and simple-to-use API.

• LayerZero
  LayerZero is a ledger-less application layer protocol for facilitating cross-chain message delivery. The idea behind LayerZero is to enable the target network to verify that a given transaction or event has occurred on the source chain. The focus of the LayerZero protocol is reducing communication costs between the chains via an ultra-light client endpoint. Because it is ledger-less, the fundamental security assumption with LayerZero architecture is that the two parties in the architecture, i.e., oracles and relayers, do not collude.

• Hyperlane
  Like LayerZero, Hyperlane uses a ledger-less approach in its cross-chain messaging solution. Whenever a cross-chain request gets submitted to the Hyperlane Network, its validators simply sign off on the messages, and their signatures are aggregated and propagated to the destination chain via relayers (also off-chain entities). Like LayerZero, the Hyperplane’s approach promotes flexibility because all validators do not need to be present on all the supported chains.

Comparative analysis

After analyzing the architectural designs and features of three cross-chain solutions, let us summarize their design trade-offs, core features, strengths, and weaknesses in a table. Flanking them in this comparative scenario are bridges — and what Analog will offer in the near future.

A key takeaway from this comparison is that no decentralized, chain-agnostic cross-chain solution built on top of a sovereign chain — that also powers Web3 data infrastructure capabilities — exists today within the interoperability space.

Closing thoughts

Blockchain interoperability is a critical component of Web3 infrastructure. It is essential for users and builders that want to securely (and seamlessly) move value and general messages from one chain to another. Without interoperability, the dream of buzzwords like composability is dead in the water.

However, in its current state, and as evidenced by this article, the interoperability space is still nascent, with many different architectural design choices that players are still experimenting with.

Analog is creating the building blocks for a multi-chain future. It combines cross-chain smart contract execution calls and Web3 data infrastructure capabilities, giving rise to an all-in-one platform that developers can leverage to interact with any supported chain. While cross-chain smart contract calls provide an asynchronous pattern for building cross-chain DApps, the Timegraph protocol allows developers to publish and query data from any supported chain.

Follow Analog on Twitter (@OneAnalog) and join the conversation on Telegram and Discord.