Interoperability Overview

Criteria: The core use case of interoperability is not a specific application, but rather a concept: Connectivity. The primary value of interoperability (connectivity) comes down to the basic need for wide inclusivity – enabling the widest range of networks to connect whilst reducing the impediments to the path of connection.Given the primary value is satisfied, developers and end users may look at these solutions through the lens of trustlessness, performance, decentralisation etc. as secondary values to evaluate tools.

A close look at the DLT space reveals a series of public and private chains that operate largely in distinct silos. As DLTs accelerate towards maturity a key infrastructure requirement will be the ability for information to be transmitted in real time from chain to chain and even off-chain to old world systems.

However the question of why we need interoperability is sometimes complicated by developers and users thinking of very specific use cases- a complex array of applications and niche features. This mindset needs to be geared towards something far more simple, going down to the very basics of interoperability.


This glaringly obvious but often overlooked use case of interoperability is a concept without which DLTs will continue to function in silos but never capitalise on their full potential. Take for example, any decentralised application or network and ask if that by enabling connectivity, would it suffer or thrive?

If the internet has taught us anything, it is the true value and weight of change that connectivity has brought to the world. Connectivity itself is therefore the use case of interoperability, and to underestimate the value that this simple concept brings would be negligent.

If we assume interoperability technology is perfected and that comprehensive connectivity is available, perhaps the issue or disconnect for many lie in the tribalism forming around DLTs such as BTC, ETH, NEO, EOS etc. To bring things into perspective, it’s akin to saying Country A should remain isolated from Country B. However this mindset will restrict DLTs from even competing with existing world systems to which connectivity is inextricably linked.

This article will therefore not focus on the specific use cases as popularly imagined by most, a Decentralized Exchange being perhaps the most popular. Instead we will imagine a world in which connectivity plays a significant role in a global decentralised economy. The challenge now faced by interoperability technologies is their ability to effectively optimise for connectivity without compromising the other core tenets of DLTs – specifically the trustless nature of decentralisation.

The Varying Degrees of Decentralised Interoperability

Connectivity to certain degrees is already apparent in the current landscape. Take for example the service Changelly or a centralised exchange like Binance, they act as a medium to allow exchange of one token for another. These mediums however do not align with the tenets that the underlying traded assets were built upon, a decentralised network that does not require the trust of a centralised third party.

As such the response within the space has been to develop technologies focusing on interoperability that do align with the core decentralisation tenets of Blockchain. The main technologies can be summarized as:

  1. Notary Schemes
  2. Relaychain and Parachains
  3. Cross-Chain Hash Locking
  4. Multichain Weaving

(Please refer to Methods of Interoperability for more information)


Notary Schemes Relaychain/
Parachains (Multichain)
Hashlocking Multichain / Weaving
Value Transfer Yes Yes Yes Yes
Access to data Verifying states Full states as part of the core protocol Intended only for value transfer Full states as part of the core protocol
Validators Required Yes Yes No No
Conditional Requirements to participate – Consensus on core protocol

– Resources to set up new bridge

– Consensus on core protocol

– Resources to set up Parachain / Bridgechain

– Same type of hashing algorithm – Consensus on core protocol

– Technical implementation to include member chain as part of the mining process

– Hard fork to the adjusted multichain architecture

What is important to draw from the above technologies is the ability to identify the varying degrees to which these technologies have achieve decentralised interoperability – the extent of connectivity established while maintaining decentralisation.

Ultimately users have the choice of any number of interoperable methods, even centralised exchanges. To assist in this choice, consider the problems these technologies solve in regards to relationship of trust (blockchain tenets), security and access (connectivity). The problems manifest themselves as three core problems, in summary below and discussed in detail further down:

  1. Opportunities/limitations of interoperability – Trust and security based on knowing full state vs verifying state
    • Value transfer
      • Full state of member chains as part of the protocol’s data
      • Compatible chain communications (Hashlocking)
      • Verifying the state based on verification by a validator
    • Access to Data – Knowing the states of member chains – i.e. Proving data relative to another network, effectively allowing smart contracts and applications to leverage this “knowing”. Can be achieved via:
      • Full state of member chains as part of the protocol’s data
      • Verifying the state based on verification by a validator
  2. Methods of interoperability – Trust based on validators vs no validators
    • Centralised hubs
    • Validator based (Verification via Validators, 3rd party)
    • Work based (Verification does not require validators)
  3. Access to interoperability – conditions to participate
    • Conditional requirement to participate – i.e. requires smart contract or requires change to core protocol

The first problem: Opportunities / limitations of interoperability –  Trust and security based on knowing full state vs verifying state

The variable here is trust based. The two options being “knowing” of states vs verification of a state. Multichain technology can “know” full states as all member chains are part of the parent chain, allowing constant knowing of the latest states of said member chains. Where on the other hand variations of the notary scheme require verification of the latest state by validators. To put it simply, the difference lies in that notary schemes have to confirm information external to their protocol, where multichains are in a constant state of knowing ergo internal confirmation.

If we are to look at this in regard to security, if the members chains’ data is part of the core protocol (as proposed by Polkadot and Block Collider – multichain technology) the states of those chains is secured by the entire protocol and therefore verification and use of that data is as secure as the protocol. As popularly proposed, notary schemes, that verify states based on interoperable actions triggered, are separate chains or nodes bridging information between chains to the core protocol. The security then of the bridges is independent of the core protocol making it more vulnerable to attacks. A slight exception lies with projects like ARK, where the whole protocol acts as one cohesive notary scheme for all member chains, where the bridges are not separate chains or clusters of nodes. By doing so the resources utilised are not split to many disparate smaller bridges, ensuring more security overall.

The second problem: Methods of interoperability – Trust based on validators vs no validators

To understand this problem we must first understand the core tenets of which blockchain technology was built upon and what it ultimately means to the end user. The tenets or pillars can be thought of as four topics:

  1. Objective networks
  2. Unforgeable costliness
  3. True Trustless Networks
  4. True permissionless networks

For a more comprehensive breakdown of these topics that act as the pillars of Decentralised Protocols please read here.

“The most valued merit of the trustless model is its ability to preserve the network’s independence from any entity acting as a trusted third party (government, bank or otherwise) with the power to tamper with, control or censor any element of the network.

It is this distinguishing feature of PoW, that enables it to offer a level of trustlessness beyond other consensus mechanisms which rely on the use of validators. A validator in a blockchain is a “human element” or third party to whom the network cedes some degree of trust to confirm the verification of transactions. “… To understand the spectrum of trustlessnes, one can imagine that centralised systems which completely relinquish trust to a third party are on one end and variations of PoW that eliminate trust are on the other. The various validator reliant consensus mechanisms lie in the middle, redistributing rather than eliminating trust.”

As alluded to above, trust minimization is a crucial element of blockchain technology, where PoW variations (work based schemes) like the multichain proposed by Block Collider (PoD) attempt to preserve the network as trustless. Further mining (wok based) schemes preserve objectivity and unforegable costliness, something that is compromised when we move towards validator based consensus.

Notary schemes by design have the underlying consensus as validator based (refer to Methods of Interoperability). Multichains need not only be work based either, for example Polkadot has taken the route of multichains with a validator based consensus. (Note: Polkadot only creates the multichain between compatible parachains)

The third problem: Access to interoperability –  conditions to participate

Access can be defined by the ability for a interoperable technology to incorporate chains with as low an entry threshold as possible. Access can viewed than as a spectrum that is defined by the conditional requirement to participate.

The ideal is that if a new protocol/chain were to come into existence that it is able to join an interoperable network without any additional resources or change to their core protocol.

Some interoperable networks require compatibility and therefore require changes to the member chains at their protocol level (Cosmos / Polkadot). Largely notary schemes and Multichain schemes are excellent for reducing the entry threshold as they require no changes at the protocol layer of the member chains. What they do require though is consensus on their respective interoperable networks to add a new chain to the network:

  • Notary schemes generally require consensus, but implementation could be simple in so far as there does not need to be a “fork” of the protocol to implement a new bridge. A new set of nodes or a side chain/bridge can be formed.
  • Multichain’s as proposed by Block Collider and Polkadot would require both consensus and some technical backend work to ensure that the chain is part of the multichain protocol, requiring a hardfork.

Notary schemes by making trade offs through a validator based architecture as outlined in problems 1 and 2, do effectively make implementing new schemes (bridges) a much easier task. The threshold for a new chain to be interoperable becomes comparably lower than a multichain.

Scope and Method of Interoperability Chains

As we have identified, there are varying degrees in which interoperability is achieved by different technologies both in their ability to remain decentralised and provide connectivity. Multichain and Notary schemes are largely compatible with most chains and therefore have the broadest reach to expand their networks. Any interoperable network that require changes to the member chains will always suffer in terms of connectivity as their ability to provide connectivity is conditional. The below diagram illustrates the different projects, their scope and their methods of achieving interoperability.

© 2018 | All Rights Reserved.