Classifying Blockchain Interoperability Solutions

In September 2016, Ethereum co-founder Vitalik Buterin published a paper titled “Chain Interoperability” to explain the different approaches to blockchain interoperability. He wrote,

From a technical perspective, there are three primary categories of strategies for chain interoperation:

● Centralized or multisig notary schemes, where a party or a group of parties agree to carry out an action on chain B when some event on chain A takes place.

● Sidechains/relays (systems inside of one blockchain that can validate and read events and/or state in other blockchains).

● Hash-locking (setting up operations on chain A and chain B that have the same trigger, usually the revelation of the preimage of a particular hash).

In a previous article, we explored existing blockchain interoperability solutions and how most of them come with their own unique set of limitations. Like other emerging technologies, blockchains and distributed ledgers have seen significant innovation and development in recent years. However, since these efforts are mostly disconnected from one another and motivated by differing ideologies, the problem of blockchain fragmentation has become increasingly apparent.

Realizing this limitation, blockchain developers have come up with new ways of establishing interoperability over the past couple of years. These solutions allow blockchains to directly communicate with each other, either with or without a trusted third party.

Vitalik’s technical classification of trust aside, however, we believe that blockchain interoperability projects can also be generally classified on the following factors: intrusiveness, awareness, and universality.

Intrusiveness

Blockchain interoperability solutions can be segregated into two primary categories, namely intrusive and non-intrusive. Put simply, intrusive solutions require blockchains to integrate the interoperability logic within the base protocol itself.

Projects such as Cosmos and Polkadot not only integrate their interoperability logic at the blockchain protocol level, but also require new blockchains to be created around a specific consensus mechanism. This is why they are sometimes referred to as ‘a blockchain of blockchains’ solution. While these intrusive solutions can be quite powerful, they are unfortunately not compatible with almost every single blockchain currently in existence.

Since intrusive protocols require blockchains to be designed with interoperability in mind, they can offer a seamless user interface with reduced time and cost overhead. However, implementing such protocol into an already existing blockchain could introduce new attack vectors or security flaws that can be exploited in the future. As a result, it is extremely unlikely that any major cryptocurrency blockchain will integrate such solutions.

Non-intrusive solutions, on the other hand, do not require the blockchain itself to have the interoperability logic defined. While this approach may have to tradeoff convenience, it is significantly more secure than intrusive solutions and does not require existing cryptocurrency blockchains to be modified in any way.

Awareness

While the term interoperability refers to the communication and transfer of value between chains, some solutions may not require participating blockchains to know about each others’ existence.

As a result, there are three possible scenarios: one where both blockchains know about each other, another where only one blockchain is aware of the interoperability mechanism, and finally, one where neither chain is aware of the interoperability process.

Cosmos and Polkadot, for instance, are two solutions that require the interoperability logic to be defined within each sub-blockchain. As a result, blockchains designed for these platforms are aware of the existence of other chains. On the other hand, in a third-party custodian solution such as Caasiope, the blockchain itself does not handle interoperability logic. Therefore, there is no awareness among participating chains.

Universality

The final differentiating factor among interoperability solutions is how many blockchains they are compatible with. For instance, a truly universal project would be one that manages to work with almost every single existing cryptocurrency blockchain. On the other end of a spectrum, interoperability projects that are designed to specifically work with only a small subset of blockchains can be termed ‘blockchain-specific’ solutions.

The Interledger Protocol, developed by Ripple, is the perfect example of a solution that is both universal and non-intrusive. Today, the interoperability solution is used by Ripple Labs to connect bank systems for seamless cross-border transactions. Given that banks around the world have created distributed ledgers with varying levels of similarity, the solution had to be designed with universality in mind. To achieve this, the Interledger Protocol relies on the concept of ledger provided escrow which locks funds until a certain qualifying condition is met. Payments on the Interledger Protocol are routed through trusted connectors.

Trust

Cryptocurrency fundamentalists have long argued that blockchain solutions should be completely decentralized and trustless. However, the blockchain industry has started to realize that incorporating a certain degree of trust can achieve a higher degree of robustness, similar to the modern-day banking system.

However, that is not to say that trustless interoperability solutions do not exist. A cross-chain atomic swap facilitates the exchange of tokens between blockchains in a peer-to-peer manner, making it completely trustless. On the other end of the spectrum, RSK, LiquidPay, and Caasiope involve a specific degree of trust to improve user experience, achieve interoperability with additional blockchains, reduce technical overhead or some combination of the three.

Conclusion

The blockchain industry has evolved significantly since Vitalik Buterin first laid out a classification scheme for interoperability solutions in 2016. Furthermore, the introduction of projects such as Cosmos, Polkadot, and Caasiope has resulted in the need for more granular categorization. By accounting for factors such as intrusiveness, awareness, universality, and trust, however, we can gain a solid understanding of the strengths and limitations of various solutions currently available.

This article was written for and originally published on Caasiope.net