Blockchain Interoperability Landscape

Overledger [24]: Overledger’s official purpose is to provide a ‘messaging layer’ for blockchain-based applications, which is agnostic to each blockchain’s consensus mechanism. Instead, it allows the different chains to send messages to each other through a standardized format. Quant Network, the company behind Overledger, describes the project as an “operating system of blockchains”, as it can serve as the entry point for existing payment systems and blockchains to be abstracted for the application layer.

Hyperledger Cactus [4]: Hyperledger Cactus is an enterprise-grade application that allows for seamless cross-chain transactions. On top of achieving interoperability for assets, it also looks into the interoperability of data between blockchains, such as sharing inventory data between permissioned enterprise networks.

Hyperledger Firefly [8]: Hyperledger Firefly is an API abstraction layer for applications based on the blockchain, similar to Overledger. It aims to allow for permissioned data passing among different chains. Compared to Hyperledger Cactus, this project focuses more on the application development side, as it seeks to provide a software development kit for building DApps based on multiple chains.

Polkadot [25]: Polkadot is a layer-0 solution for blockchain interoperability. It enables the communication between different blockchains through what is called “parachains” and the “relay chains” [18]. It looks to address scalability in computing and networking while working with systems with diverse needs and guarantees in the blockchain space.

Cosmos [10]: Cosmos shares a similar goal as Polkadot, providing a layer-0 solution for interoperability. It aims to address the drawbacks of many current blockchain networks, such as energy inefficiency and low performance, and bring all networks together through a parallelized structure called “zones.”

Loom [7]: The Loom Network is an Ethereum sidechain powered by the native LOOM token, a native ERC-20 token. It strives to achieve interoperability by connecting different blockchains to the ‘basechain’ using a gateway mechanism. Loom tokens can be burned and minted on the source and destination chain using these gateways, allowing liquidity flow across various blockchains.

Hybrix [11]: Hybrix is a peer-to-peer (P2P) protocol to achieve interoperability between blockchains. A node on a Hybrix system runs software called hybrixd, which includes connection mechanisms for supported blockchains, a data abstraction mechanism, and a secure signing mechanism to enable a connection between interoperating blockchains.

Chainlink [3]: Chainlink is a network of Decentralized Oracle Networks (DONs). It aims to provide reliable data – both from on-chain and off-chain – for other blockchains to consume. With the announcement of Chainlink v2 [3], the project has introduced a new term called hybrid smart contracts, which is an abstraction of on-chain computation using off-chain data from DONs.

Poly Network [23]: Finally, Poly Network is another project that follows the hub and spoke architecture (Figure 3(a)) to provide interoperability. Poly Network itself is not a blockchain, but it provides the protocol for nodes of blockchains participating in Poly Network to create a consortium blockchain that has shared storage.

Hub and Spoke: The hub and spoke approach is a commonly used architecture for constructing large networks. Figure 3(a) shows a simple architecture diagram. This approach connects individual ‘nodes’ – blockchains in this case – to a central hub through which they can interoperate. Some projects implementing this architecture are Polkadot, Cosmos, Loom, and Poly Network.

Decentralized Relay: The decentralized relay architecture is a design in which networks can communicate through ‘gateways.’ A blockchain gateway is an entry point to the underlying ledger with read/write access. In this design, each gateway is assigned a particular blockchain to connect to the main network or handle connections between the main network and all other blockchains. Figure 3(b) shows a simple diagram describing this architecture. For projects such as Overledger, Hyperledger Cactus, and Firefly, the software must run on a trusted machine – not necessarily an active network node – and use connectors for each blockchain. Hybrix also uses this architecture to relay messages from one blockchain to another through a P2P gateway mechanism. At a glance, this architecture can appear similar to the Hub and Spoke architecture, as it achieves a similar network scheme of connecting different chains through a designated entry point. To avoid confusion, we differentiate these by their usage of additional blockchains. Then, the Hub and Spoke approach is an architecture in which both the hub and spoke are different blockchains that sync with the target chains. On the other hand, a decentralized relay is a piece of software that connects blockchains without introducing additional blockchains, meaning that it does not necessarily have to deal with the state of the networks as long as it forwards data between blockchains.

Decentralized Oracles: An oracle in the blockchain space refers to an entity that allows a blockchain to access out-of-chain information. This information can be both on-chain from another blockchain, such as the amount of liquidity present in the network, or off-chain, such as foreign exchange rates. If a blockchain depends on information from a centralized oracle service, the validity of the entire blockchain ledger can be compromised by compromising the oracle’s data source. Decentralized oracles try to tackle this problem by adding redundancy at the oracle level by having multiple nodes serve the same data only if it can be agreed upon by the validators and verified. Previous works in analyzing blockchain interoperability have classified the Oracle approach as a mechanism used to achieve interoperability, similar to that of other mechanisms such as Hashed Time Lock Contracts [6] or Burn-and-Mint [2]. However, unlike those mechanisms, oracles are not necessarily crypto-centric. It can convey information related to transactions, but it can also communicate any other kind of data. In this work, we view decentralized oracles as an interoperability solution because of the wide range of data they can transfer between blockchains and the traditional world. Chainlink [3] implements this approach by connecting various Decentralized Oracle Networks (DONs) to create a meta-chain of oracles that can provide data feeds to its target blockchains.

Native Validation: Native validation is defined as validation happening inside the interoperability solution. This approach applies to solutions implemented in their chains, which can have their state validated. Several projects, such as Polkadot, Cosmos, Loom, Chainlink, and Poly Network, use this approach.

Polkadot: Polkadot’s relay chain state is maintained by its validator nodes. To prevent malicious behavior from validators, Polkadot has a unique role called fishermen who are in charge of checking the blocks signed by the validators. If it turns out that the fishermen did indeed detect misbehavior, they are rewarded by the network. The reward amount scales with the number of validators who signed off on the illegal block, as it implies higher risk in the network [25]. In each parachain, collators are the nodes responsible for working with the validators. As the name suggests, the collators combine the transactions by building a block for the validators.

Cosmos: In Cosmos, each zone updates its parent hub with the state of its blockchain. The zones also update their status based on the hub, allowing for bi-directional information flow [10]. When a zone needs to send or receive information from another zone, it posts a Merkle tree proof of the sender on the hub, which the destination zone receives. Similarly, the destination zone also publishes evidence that the information was received. This mechanism is similar to how sidechains communicate by establishing a bi-directional channel for proof-of-existence transactions.

Loom: The Loom base chain uses Delegated Proof of Stake (DPoS), an improvement over the commonly used Proof of Stake (PoS) mechanism, to validate the data coming from outside. Unlike PoS, in which the validator is chosen with randomness proportional to each user’s staked amount, DPoS allows users to vote for new validators, each vote worth the amount they have staked.

Chainlink: As an oracle framework, Chainlink must verify that it serves the correct data, whether off-chain or on-chain. Before the data is relayed to the requesting blockchain, validation is done by selecting random nodes of each DON to compare the data against its own.

Poly Network: Validation happens in Poly Network by recording the block header of the relayed data. Using the Merkle root inside the block’s header, the Poly Chain (the main chain) re-verifies the block’s validity. Once this block is verified and recorded in the relay chain, the data can be sent to other chains, completing the cross-chain operation.

Third-party Validation: Third-party validation refers to a validation mechanism in which the task of validating is delegated to a third party who is not a part of the interoperability solution. A federation of validating nodes is commonly used to provide a robust security guarantee. While convenient because different validators can be switched in and out, this approach can also introduce a security bottleneck if it needs to be decentralized enough compared to the connected blockchains. Projects that use this approach are Hyperledger Cactus and Firefly, both of which make use of ledger plugins (called blockchain plugins in Firefly). The choice of validator service is left up to the user, meaning that the security of these projects’ instances depends on the validator service.

Hybrid Validation: Hybrid validation is when verification happens through a different mechanism than extending the connected chains’ state. This mechanism is applicable when the data being passed in the interoperability protocol are not assets but pieces of arbitrary data. A typical implementation of this mechanism uses the message field in transaction data. By setting a protocol for reading and writing to this field, the interoperability solution can ensure that the data it receives is original. Two projects that use this approach are Overledger and Hybrix. Overledger uses a proprietary algorithm known as TrustTag to generate and verify hashes for messages. When a transaction needs to be sent off-chain, the user’s identity and transaction details are encrypted using the application’s public key and added to the metadata field. The digest is verified using the application’s private key when this message arrives at the application layer. This mechanism allows the app to confirm that the message has not been tampered with and provides the ability to assign unique IDs for each user. This technology is closed source and is patented by Quant, the company behind Overledger. Like Overledger’s message verification mechanism, Hybrix also uses the message header field to validate the originality of the incoming data. To achieve this, empty transactions that carry data are composed and pushed to each blockchain. The first block contains a genesis recipe, which establishes the interoperability protocol. The cross-chain transactions sent after this genesis recipe is checked using its hash value.

Software-based: This category applies to solutions that provide the software to construct or connect to the network, such as Overledger, Cactus, Firefly, and Hybrix. These solutions implement a microservice-based architecture, meaning that the connector service for each network can be upgraded separately without impacting the other functionalities.

Blockchain-based: This category applies to solutions that leverage a new blockchain to achieve interoperability, including projects such as Polkadot, Cosmos, Loom, Chainlink, and Poly Network. Upgradability is an essential feature in this category of solutions because they can be susceptible to a hard fork if the community does not unanimously agree with a substantial update. Polkadot addresses this problem with its protocol. Its governance is a meta-protocol, meaning that the governance can define upgrades without requiring a hard fork. Chainlink addresses this problem by providing a service called contract-update to account for unforeseen changes. This service allows users to modify the existing smart contract, publish a new one, and update the DON connections to point to the revised contract. Cosmos, Loom, and Poly Network do not specify plans for unforeseen changes to the network. Thus, with the exceptions of Polkadot and Chainlink, blockchain-based solutions may face a hard fork when there are essential requirements to upgrade.

Hub and Spoke: Projects that implemented the hub and spoke architecture can have more complicated requirements for new networks to join the interoperability network. These requirements arise from the hub’s blockchain need to stay secure. Depending on the implementation of the main chain’s validation and consensus, each project has a slightly different requirement for new blockchains.

Polkadot: Anyone can build a parachain for Polkadot [25]. For a parachain to become a part of the Polkadot ecosystem, it must have validators. To maintain the integrity of the main network when adding new networks, Polkadot requires that the existing stakeholders of the network be incentivized by some means – whether that be paying a fee or providing a new feature. For connecting a new chain that does not conform to Polkadot’s governance, such as Bitcoin, Polkadot provides a “bridge chain.” Additionally, Polkadot runs a test network known as “Kusama” to provide a sandbox for developers to test their blockchains.

Cosmos: Anyone can build a zone for Cosmos. Cosmos separates the governance between the hub and zones, allowing its zones’ failures to be isolated from the entire network. Compared to Polkadot, Cosmos has a lower entry condition as the zone creator can choose their validators for the zone instead of being designated validators by the main network.

Loom: Loom network’s main chain exists as a layer-2 Ethereum blockchain and is supported by the Loom ERC-20 token. Loom has achieved interoperability by allowing different ‘versions’ of this token to be transferred between various blockchains using smart chain mechanisms such as burning and minting. Although Loom makes no specific requirements for a blockchain to be supported, it can be assumed that the new blockchain must support some form of ERC-20 compatible tokens and some form of smart contracts.

Poly Network: The relayer function needs to be implemented for a new blockchain to join the Poly Network environment. The new network must also support light client verification mechanisms such as Simple Payment Verification (SPV) or Light Ethereum Subprotocol (LES) to implement the validation step in the relay chain.

Decentralized Relays: Decentralized relays such as Overledger, Hyperledger Cactus, Hyperledger Firefly, and Hybrix use the comment field to facilitate interoperability. Thus, a critical requirement for a new network to join these systems is that it must support a comment field in the transaction data. For Hybrix, the new blockchain must also be public for validation purposes.

Decentralized Oracles: Chainlink does not have any requirements because its role is simply to serve the data. However, some security requirements exist for new DONs to join its meta-network [3].

On-chain: On-chain governance is applicable for solutions that maintain the main blockchain network that other networks connect through.

Polkadot: Polkadot governance is composed of a ‘council’ and a ‘technical committee.’ A council is a group of elected stakeholders, of which there are currently 13 members. The council is responsible for: 1. managing treasury, 2. proposing referenda, 3. canceling dangerous referenda, and finally, 4. voting for the technical committee members. Only teams or individuals who have added successful implementation to Polkadot can be a part of the technical committee. The technical committee can submit emergency proposals and veto a proposal.

Cosmos: Cosmos’ governance is responsible for managing updates to the network, changing protocol parameters, and using community pool funds. Each validator needs to deposit a minimum amount of ATOM tokens. A validator may be deactivated for a certain amount of time if a validator does not vote. On top of the Hub’s governance, each zone may also have its governance. Nevertheless, the Hub’s governance will reign superior, acting as a constitution for zones inside the Cosmos ecosystem.

Loom: Loom Network’s governance is based on the native LOOM token. Validators and delegators stake the tokens to secure the network. Application developers who use Loom’s base chain also pay for their service in LOOM, even though the individual users do not need to pay. The token can also be bonded when a developer adds a new chain to the network to discourage malicious behavior.

Chainlink: With the announcement for v2 of Chainlink, no specific governance protocol has been announced for the network. However, the governance model will be evolutionary [3], meaning that the governance mechanism itself can be subject to change. Each DON may also have its governance mechanism to account for DON-specific changes.

Poly Network: Governance happens on its main chain, called the Poly Chain [23]. However, Poly Network does not issue a token, so it remains to be seen how the network members can partake in the governance of the main chain.

Off-chain: Interoperability solutions that provide the software rather than another blockchain do not have on-chain governance. These solutions are Hyperledger Cactus, Hyperledger Firefly, and Hybrix. They are designed to be used by a consortium of entities to run their nodes and form an off-chain network. Overledger is an exception because it requires the Quant network’s QNT token to be licensed. However, governance within the consortium network is still dependent on the user group. The provided software can also include functionality for the consortium to make decisions, as Hyperledger Firefly does.