Introduction

Blockchains are decentralized databases, fully verifiable and secured with cryptography. A client node is used to build the infrastructure and can also be used to manage the blockchain. Blockchain nodes have various types such as Light client, full node, pruned node, etc. The data contained within a blockchain is open to anyone participating in the network. Blockchains are open to anyone to join (except private authenticated blockchains that serve special purposes). The security properties of the blockchain make it very useful for applications where we would normally rely on centralized authority.

A Blockchain’s primary purpose is to store data, of any kind and in any way specified, and they do not follow a particular standard in this regard. Bitcoin for example stores a mapping of user address to Bitcoin balance. Ethereum stores an Ethereum address (Externally-owned or contract address) against a data object and also makes the data programmable (via smart contracts). Decentralization is a primary property of a blockchain and so is security. A blockchain must be secure such that participants cannot be fraudulent. But having these properties comes at a cost. The biggest tradeoff for many blockchains is scalability, related to the speed of transactions, size of the Block, and a couple more related to bandwidth and storage generally.

Problems with the Blockchain

One of the major challenges of the blockchain is fixing the scalability problem, something that is part of the blockchain trilemma. Currently, a lot of solutions have come up to fix this issue, the most significant of them involve building another blockchain that relies on the security and decentralization of the to-scale Blockchain. These sorts of blockchains are referred to as Layer-2 Blockchains, and they have helped to greatly scale blockchains to thousands of transactions per second. Examples of Layer-2 solutions are Polygon, Arbitrum, Avalanche, Optimism (all Layer-2 on Ethereum), etc.

Another solution that scales very great has to do with using SHARDs (System for Highly Available Replicated Data), a process called Sharding. The idea is to split a big blockchain, into small standalone blockchains that are specific to certain use cases. These smaller blockchains can handle their own consensus (or also the one of their base chain), but they are totally standalone chains and can function independently. Sharding is a very effective scaling solution with the possibility of hundreds of thousands of transactions per second. Examples of blockchains that are currently using Sharding are Polkadot, Cosmos and also Ethereum has a Surge update coming to implement Sharding.

One major limitation of the scaling technologies, even though the Layer-2 blockchains or even the SHARDs exist on the same base chain, they are unaware of each other. Layer-2s on a base Layer-1 do not communicate with themselves, and the same with SHARDs. As a result, with all these scaling technologies on the base chain, we cannot fully take advantage of them. Ideally, we would like to be able to verify that a certain account on Polygon (an Ethereum Layer-2) has a required ERC-721 token (commonly referred to as NFTs) without connecting to the Polygon network. We want to be able to do this while we are using our Ethereum-deployed D’app. Even for SHARDs, each SHARD is effectively different Blockchains. They have their own state, possibly their own consensus, and the only thing tying them together is the base chain. While you are on a Blockchain network, you can easily access data and also write to the Blockchain, but all this security is only available while you are on the network. A user cannot initiate transactions on another Blockchain while they are currently on a different Blockchain, by design. Transactions sent outside a blockchain will use an entirely new set of rules.

Also, to connect to a Blockchain, we need to use a node. The nodes give us access to an RPC provider that can allow queries and writes to the Blockchain. Every Blockchain uses a different node to operate, and even the ones that use the same nodes will usually operate on different networks. So to jump between Blockchains, you have to disconnect and connect your Dapp to the new network. Worse off, applications on a Blockchain are not usable on another Blockchain even if it’s the exact same code, so developers have to deploy their Dapps on various chains to allow for greater support.

Relevance of Interoperability

Demand is high for the interoperability of Blockchains and the value cannot be understated. Consider a use-case of Decentralized Exchanges (DEXes). DEXes have to deploy a copy of their codebases to various Blockchains when it should be possible to have a single copy deployed on a base chain, like Ethereum, and be able to stake your Avalanche tokens on the Avalanche network. This would mean being able to access Avalanche’s state on Ethereum or even request some piece of data. Deploying Dapps on multiple Blockchains to increase adoptions is very expensive and leaves room for UX upgrades.

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. To develop interoperability between blockchains, a mediator needs to stay in between the two chains in participation.

Here is a valid analogy, say you had a big wall (like the wall Maria in Attack on Titans). If you wanted to send a package to the titan’s side of the wall, you could dispatch the package but you would have no way of knowing if the recipient on the other side got your package. If they send a response saying they haven’t gotten the package, they also have no way of knowing. The two sides of the wall do not speak the same language, so you could even get the message and have no idea what to do with it. One way to clear this issue is to have a person on the wall that monitors the delivery and receipt of the packages. This mediator would be responsible for making sure the data is well received on either side of the wall. Of course, the mediator would have to be awake always too (or a way to tap them awake). This is pretty much the same between Blockchain networks.

The most popular way to do interoperability is using Cryptocurrency bridges. Bridges are basically used to move tokens from one chain to another chain. The tokens could be anything (from Fungible to NFTs to even native currencies). In this case, a mediator is usually a smart contract, likely on both chains, or a Dapp between the chains. The contract will be responsible for locking/burning tokens on the sending chain and then unlocking/minting on the destination chains. Bridges though have a history of vulnerabilities.

Some better secure ways of doing interoperability on Blockchains involve using Messaging Protocols. Protocols are rules that guide how something should happen, in this situation we want to guide how our messages should be sent or interpreted on distinct chains. Examples of current protocols are Chainlink’s CCIP (Cross Chain Interoperability Protocol), Tendermint’s own IBC (Inter Blockchain Communication) and my favorite XCMP (Cross Consensus Message Passing Protocol, which is an upgrade on the current HRMP) developed by the company behind Polkadot (Parity). These are some of the Web3 firms making innovations around interoperability.

CCIP is a little distinct from IBC and XCMP (which use similar techniques). CCIP takes advantage of Chainlink’s network. Think of this as a bridge that allows more than just toke transfer. With CCIP, you could interact between various Blockchain’s smart contracts, perform token swaps, and token transfers. It uses a smart contract deployed on both chains to handle the interoperability. IBC and XCMP are examples of how Sharding can facilitate interoperability. In a sharded blockchain, there is always a base chain that all the SHARDs are connected to. The approach of Polkadot and Cosmos towards interoperability is to build a network of Blockchains that all stay connected to a base chain. Data can then be sent between the chains with the base chain as a mediator. All the individual SHARDs can operate independently with no outside interference but can also verify the state between themselves by going through the base chain. Pretty effective but for now, it’s best implemented between the relevant network. For Polkadot, every Blockchain created with the Substrate framework can easily benefit from the Cross consensus protocol.

Summary

The important thing in all cases is to come to an agreement on how the message to be sent is formatted, and have all chains agree on this format. If you’re building on the Polkadot or Cosmos network, you have the benefit of the network of substrate blockchains or that of the tendermint-based blockchains. You can easily interoperate within them. But a more ideal use case is to communicate between totally distinct chains.