Cross-Chain-Interoperability

There is no denying the blockchain space is shifting at an outstanding pace, and despite many having the initial idea that one chain could triumph over the rest of them, it is almost ridiculous to hold the opinion that there is only space for one blockchain. Most of the projects in the blockchain space have been staking out different regions of the tradeoff space between security, privacy, efficiency, flexibility, platform complexity, developer ease of use and even what could only be described as political values (Vitalik, 2016). One could argue that this will only be the case until one cryptocurrency makes all the other chains obsolete by having an undeniable superiority through the lack of tradeoffs in the characteristics shared above. As much as this is a very exciting idea, it is very unlikely to happen any time soon, if at all. Given that is it quite certain that this technology will not arrive anytime soon, the blockchain space as a whole should start fostering an attitude of cooperation. This is where interoperability comes in. There seems to be an abundance of chatter regarding different ways to achieve interoperability, but no general consensus regarding a formal definition of ‘true’ interoperability. This is because every project that tries to implement it modifies that definition to make it look like they have the one and only key to deciphering the mystery. In the interest of saving time, and so we don’t have to go through each individual definition to determine which is the correct one and why, I will provide a very broad stroke into what cross chain interoperability really is.

“Cross chain interoperability deals with the creation of a protocol that is able to settle transactions between different blockchains with different consensus mechanisms without the need for a third party.”

Now that we have a definition, in very broad terms, we can examine what interoperability means for the overall blockchain space, why we need it, what shortcomings it has right now and how they can be overcome.
 I believe that most of the value of the blockchain space will be captured primarily in the protocols, as opposed to the current state of the internet where the protocol holds little value against the product. If we work from this maxim its very likely that protocols will be thin protocols. What this means, in simple terms, is that in comparison with the internet, the protocols and coins powering the protocols will hold more value than the applications using them.

There is another peculiarity in this space in comparison with the internet era, protocols can be forked as most of the work in the space is open source. This allows for anyone who is not entirely satisfied with the functioning of the protocol to fork the code and create their own version of the project with a slight modifications. This will create a hyper-competitive environment where there are many protocols, with slight changes for the same task, and in the words of Teemu Paivinen:

“The industry is growing so the perceived opportunity in more niche areas grows. Right now a highly specialised protocol might look like a $50M opportunity, but in the future if the total market capitalisation of the industry were to be 10x higher, that same opportunity would be worth $500M”.

This means that focusing on building a complex and complete protocol is no longer the best way to extract value from the ecosystem — the best way is to focus on building niche parts of a protocol. Therefore, what we are facing is essentially the idea that protocols are going to be made up of subprotocols, for example:

Interoperability can be leveraged via subprotocols in two different ways, the first being on-protocol interoperability. We could all agree to develop the subprotocols along a number of guidelines, but this would defeat the purpose of subprotocols. In turn, we get to develop a protocol to mediate between subprotocols.

In this first scenario we can see how adding an interoperability layer within the protocol layer can help all the subprotocols interact with each other. The same logic can of course be applied to different protocols:

In this example, an interoperability layer is being applied to make two applications, with two different protocol layers (made up of different sub-protocols that communicate thanks to their own interoperability layer). This is probably going to be one of the most prevalent ways to leverage interoperability. A good example for this use case would be an application that uses the SiaCoin network having to pull information from IPFS STORJ and MAID, consistently. This application could, in theory, code a framework to connect to each other independently but it would be much more reasonable to develop these connections through a single interoperability layer. By doing this, all these networks could essentially communicate with each other using the same code structure. Finally, a similar use as to that just described, we could have two blockchains who want to communicate with each other. This would be the case with Decentralised Exchanges, for example, and the architecture would look something like this:

Its important to note how the connectivity is not in between the two sub-protocols/applications/chains, but rather the intermediary protocol stores and acts as decentralised escrow for these transactions.

With a better understanding of the different ways of leveraging interoperability, and how important it will be to scaling the blockchain space, we can now look at the shortcomings. There are effectively hundreds of blockchains and many of them have inherent incompatibilities, meaning there is no easy way to approach interoperability. The solution therefore is not as simple as it might seem. To build a chain of chains that acts as an intermediary for all the other chains and implements a layer, through which the entire blockchain space can route their traffic to allow for better communication, is a painfully slow and complex process that requires a lot of manpower and a complex architecture. In on itself interoperability doesn’t solve any of the problems that the current ecosystem has. Be that throughput, [real] privacy or even cost, it just gives the developers of individual chains the chance to leverage the power of other chains to help address the shortcomings of their own chain. In other words, Bitcoins will still only be able to transact at 7 tx’s/s and Ethereum will still not be a private blockchain. Interoperability shouldn’t be viewed as a platform to mesh the best of each blockchain, it simply provides a general framework to aid the communication if someone decides it’s worth the effort. Finally, it is important to examine the current state of the art technology and the resources of the initiatives tackling it. I will therefore continue by explaining the different techniques and the companies that are attempting them, as well as how successfully they have been implemented so far.

Types of interoperability

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

  • Centralized or multi-signature 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.

The technical approach chosen depends mostly on the use case the interoperability layer/chain will be carrying out. This use is, in general terms, part of one the following:

  • Portable assets
  • Payment-versus-payment/payment-versus delivery
  • Cross-chain oracles
  • Asset encumbrance
  • General cross-chain contracts

Implementations

The implementations differ from the practice and different methods are combined in different and potentially clever ways to try and squeeze the greatest amount of functionality, scalability and security. 
 In the following paragraphs, I will discuss different companies and initiatives that are working on the interoperability conundrum, how they are approaching it and then compare them, addressing their benefits and limitations. This section tries to provide a simplified description of how the blockchains achieve their interoperability, not to provide an in depth discussion of the differences and shortcoming of each approach. It’s purpose is to try to give the reader a more representative and holistic view of the state of this technology.

Polkadot

Polkadot is a scalable heterogeneous multi-chain, designed to provide no inherent application functionality. Polkadot proposes how multiple chains with different functionalities can be hosted side-by-side under the same framework. Polkadot is, in simple terms, a chain of chains, which simply enables a framework for different chains to interact with each other. In other words, Polkadot is not building a chain that will expand its capabilities, but rather a framework for other blockchains to interact with each other. This chain allows the interaction of different chains with each other but doesn’t necessarily leverage other chains’ capabilities. Thus meaning, you can exchange Bitcoin for Ether without a central party but you can’t use Ether smart contracts with Bitcoin. In reference to the diagrams above, Figure 3 and Figure 4, Polkadot is essentially the intermediate layer.

Cosmos

Cosmos is intended for the scaling of public Proof of Stake blockchains. Cosmos is a network architecture, of many independent blockchains called zones powered by the BFT algorithm Tendermint Core. In other words, Cosmos can be regarded as a simple Proof of Stake coin that extends its functionality by appending established proof of stake blockchains. Despite having its own “inter-blockchain communication” protocol, Cosmos intendeds to be a blockchain of block chains. The purpose is not to develop an interoperability protocol but rather to create an interoperable blockchain. In other words, Cosmos wants to leverage the power of all other blockchains within its own blockchain instead of creating a framework through which other blockchains can leverage each other. Cosmos is the entire ecosystem, instead of just the intermediate layer; it makes use internally of their own intermediate layer, but its not the intermediate layer in on itself. For all practical purposes, a developer could not use Cosmos to leverage Ether smart contracts in Bitcoin, but would rather have to use the Cosmos chain to create an application, in their blockchain, that does exactly that.

Comparison of CCI Protocols

We have given very brief descriptions of the most relevant projects which are trying to leverage interoperability. Now we will proceed to compare them. Polkadot enables interoperability between different blockchains, on the other hand, Cosmos aims to become a blockchain of blockchains. Polkadot is looking for scalability through collaboration while Cosmos is trying to become the most prevalent blockchain by exploiting the capabilities of the other chains without having to code them into their blockchain. Each of these options have their shortcomings and benefits, which will be examined below.

Having a framework to communicate between blockchains is very useful, however, it comes with the limitation that you need to build applications on top of a pre-existing blockchain — which might not be ideal. Another possible approach might be to run applications off-chain but settle the transactions on chain. This is not necessarily a bad thing but it inherently limits the decentralisation at an application level. To contrast, Cosmos provides a blockchain that can extend functionality by connecting to the blockchains; not only letting them communicate but also leveraging each others capabilities. While this addresses the shortcoming of Polkadot, it comes with its own weakness, which is: chains can not use Cosmos as a communication layer, but rather people would have to build their applications on the Cosmos layer, making it restrictive by nature. Polkadot, while less user friendly, is presented as a system with no contentions other than providing a layer for different blockchains to communicate. On the other hand Cosmos Is looking to become the superior chain that mentioned at the beginning of the essay, with a catch, Cosmos is not becoming the almighty chain by its own merit but rather by developing a chains that can leverage the functionality of all the other chains. In conclusion while both Polkadot and Cosmos are tackling Cross Chain Interoperability, they are doing it in what seems to be a mutually exclusive way.

References

1. Chain Interoperability Vitalik Buterin September 9, 2016

2. https://blog.zeppelin.solutions/thin-protocols-cc872258379f(Teemu Paivinen, 2017)

3. Polkadot White paper

4. Cosmos white paper

Like what you read? Give Lucasxhy a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.