Blockchain explained

Blockchain interoperability: I do not think it means what you think it means

Share this post:

Since being published, the next generation of the IBM Blockchain Platform has been announced. Therefore, IBM Blockchain Platform Starter Plan will be removed from the IBM Cloud Catalog starting July 5th, 2019 and you will not be able to provision new instances after that. However, existing instances will be supported until June 4, 2020. To continue your blockchain developer journey with the next gen version of the IBM Blockchain Platform, go here.

I am frequently asked about blockchain interoperability by my executives, clients, industry colleagues, press and analysts. My response has been pretty consistent: It depends on what you mean by interoperability, and what use case you have in mind.

Technology consumers are interested in interoperability because they don’t want to be locked into a specific vendor offering. They would like freedom of choice and the ability to change providers down the road. In the context of blockchain, because we are still in the early stages of enterprise blockchain development, consumers don’t want to be locked into a particular technology — but that in itself presents its own set of challenges.

Because of the decentralized nature of the technology itself, there is also a desire on the part of consumers to choose where they will run their nodes; whether on premises or in the cloud.

Deploy the IBM Blockchain Platform across multiple environments

Then, there is the aspect that for enterprise blockchain there are a multitude of platforms from which to choose: The Linux Foundation’s Hyperledger Fabric, Hyperledger Sawtooth, Stellar, Ripple, R3 Corda, and the various Ethereum offerings such as Axoni, JPMC’s Quorum and the soon to be released Pantheon from PegaSys. When people speak of interoperability, are they anticipating a day when all of these platforms interoperate with one another in some pan-galactic seamless blockchain? Do we need or even want that? Often, I fear that this is what people mean when they ask about interoperability.

You keep using that word

Now, I think that what they really mean in this case is not interoperability, but integration. Can a chaincode in Hyperledger Fabric call out to post a transaction on another blockchain, such as Ethereum or Bitcoin? Of course. Now, do we need something like the Interledger Protocol (ILP) crypto-graphic conditions to ensure that they either both happen or neither? Yes, but this is not necessarily interoperability in my book, it is a connector that presumes that the artifact being exchanged is the same on either side (a payment).

To achieve true inter-platform interoperability the likes of which I suspect some seek, would require developing the “one API/protocol to rule them all” and getting every platform to adopt that, consistently. Even if we could, it would be years in the making. There be dragons.

There is no panacea for blockchain interoperability. No silver bullet. No knight in shining armor will come riding in on a white steed brandishing Satoshi’s samurai sword to slay the dragon of cross-platform blockchain interoperability.

Achievable interoperability

Let’s take a step back to see what we might reasonably accomplish in the coming months.

We often say that “blockchain is a team sport” involving multiple parties collaborating in a common consortia network. The thought that each party in a large consortia involving thousands of participants would engage exclusively with a single vendor is also rather quaint.

The reality is that most consumers have already chosen cloud (or blockchain platform) providers and they likely have little desire to take on yet another just for one application. Thus, there is a need to ensure that there be interoperability amongst a set of platform offerings from different (or even the same) provider. For example, can we network Hyperledger Fabric peers provided by IBM, Azure, AWS and Oracle into a common consortia network? Shh… don’t tell anyone, but the answer is “yes”.

One flavor of interoperability that we can deliver near term is interoperability of vendor offerings based on the same open source implementation. Let’s consider Hyperledger Fabric – something to which I can easily relate. There are a number of vendors and start-ups building on the Hyperledger Fabric platform: IBM, Azure, AWS, Oracle and many more. Presently, there are no fewer than 72 vendors in the Hyperledger Vendor Directory claiming offerings based on Hyperledger Fabric! If these leverage the open source released software directly, do not modify, augment or obscure the native APIs, allow the open source SDKs to be used unaltered, then interoperability is definitely within reach. Is interoperability guaranteed? Not necessarily.

Circumstances matter

While we have taken pains to enable the platform to operate with components sourced from different versions (forward and backwards compatibility), there are certain circumstances where a component from an earlier version of the platform will be incompatible with a network or channel that is leveraging a feature from a subsequent version. Context matters, in this case. This is a manageable situation, as we have also designed Hyperledger Fabric such that it can be upgraded easily from one version to the next.

Further, Hyperledger Fabric is highly configurable (by design) and to ensure interoperability between offerings from different vendors, there are some configuration options that might yield incompatibilities that compromise interoperability. So, what do we need to address this?

Miracle Max

It doesn’t really take a miracle, but we might define a profile of configuration with the intention of ensuring that offerings of Hyperledger Fabric configured in accordance with that profile would be guaranteed to be interoperable. This would allow peers in one vendor’s offering to connect to a channel hosted by an ordering service running in another vendor’s offering (and vice-versa).

This is an idea I could get behind. Who’s with me?

Simplicity, speed and value for blockchain developers

IBM Distinguished Engineer, CTO Open Technology, IBM Watson and Cloud Platform

More Blockchain explained stories

Building a digital trust ecosystem for mining in British Columbia

Responsible practices to preserve our planet require innovation, agility, and collaboration. Consumers, investors, producers, and governments around the world are choosing to do business with those that demonstrate a commitment to sustainability. In the mining sector, British Columbia is committed to increased transparency and trust related to where products come from and how they are […]

Continue reading

Why open source isn’t free: Support as a best practice

The use of open source code is on the rise. Red Hat’s 2021 Enterprise Open Source Report found that 90% of companies use open source code and 79% of IT leaders expect their business use of open source to increase. Also on the rise, unfortunately, is malware and ransomware up 158% in 2020 according to […]

Continue reading

Making permissioned blockchains interoperable with Weaver

Distributed ledger technology (DLT) has gone beyond its experimental phase and is now actively managing several enterprise workflows around the world in areas like trade logistics, export finance, inter-bank payments, and regulatory compliance. But this has not led to convergence, either to a default technology stack or to a single global network that everyone runs […]

Continue reading