Interoperability: A Big Unanswered Question in Blockchain

Share this via:

Interoperability between different platforms rarely troubles most professionals. Nowadays, consumers expect different software platforms to be able to connect with one another. Google Drive improved its interoperability with Microsoft Office products. An abundance of online resources allow users to convert .pages or .pdf files to .docx files and vice versa. Even historically insular platforms have taken steps to improve interoperability in select industries. Aside from iMessage not communicating well with Android’s messaging systems, interoperability rarely piques our attention or ire.

Unless, of course, you’re talking about blockchain. Interoperability is one of the biggest unanswered questions in blockchain.

Blockchain solutions are rapidly developing yet relatively immature. This immaturity and rapidity make interoperability a difficult, yet important, topic to address. The Blockchain Center of Excellence's white paper, “Towards Blockchain 3.0 Interoperability: Business and Technical Considerations,” addresses this concern by looking at a variety of concerns businesses have. In this paper, Mary Lacity, Zach Steelman, and Paul Cronan examine the relationship between the top-down business concerns executives have and the bottom-up technical concerns that developers and end-users have.

If you are new to blockchain, learn more about it.

What is Blockchain 3.0?

The Blockchain 1.0 era started with the creation of Bitcoin in 2009. Bitcoin is a single application that validates and secures transactions using algorithms and cryptography. Bitcoin does not rely on trusted third parties, such as banks, to perform these functions. Instead, it is a permissionless, peer-to-peer application that is not owned or controlled by any one party. Many other single-application blockchains, such as Namecoin and Litecoin, emerged by altering the Bitcoin Core to create other digital currencies. Ripple, a blockchain application for currency exchange, also developed in this era.

The Blockchain 2.0 era commenced with the foundation of Ethereum in July 2015. Ethereum provides a platform onto which blockchain applications can be built. Developers can use smart contracts – self-executing contracts whose terms and conditions are written directly into the code – to build applications on the system. At the same time, the permanent ledger immutably secures and records all transactions. Furthermore, interoperability is built into the system, as all of the applications run on a single blockchain. In the Blockchain 2.0 era, the question of interoperability within existing enterprise systems began to arise. How can an enterprise assimilate a blockchain solution with existing record-keeping systems? If an enterprise uses several blockchain solutions, how can it get them to work together seamlessly?

The Blockchain 3.0 era describes the many ongoing projects seeking to improve scalability, interoperability, privacy, and sustainability. Blockchain 3.0 projects aim for seamless interconnection between the following blockchains:

• Multiple public blockchains, such as Bitcoin and Ethereum
• Multiple private blockchains, such as Hyperledger Fabric and R3
• Public and private blockchains, such as Ethereum and Hyperledger
• Blockchains with legacy systems, such as MediLedger and SAP or Ripple and SWIFT

These projects, however, are in beta version or still under development. Even though interoperability is still in its earliest stages, “Towards Blockchain 3.0 Interoperability” contends that enterprises can still frame conversations about interoperability around key business and technical concerns.

Why Businesses Want Blockchains to Interoperate

The biggest barrier to blockchain adoption, according to industry leaders like IBM, is the lack of clarity regarding standards and governance. Industry has yet to create well-established data standards that are understood and accepted by trading partners. Although traditional standards-making bodies have updated interoperability standards for enterprises with multiple blockchain solutions, no identity, data, and event standardization exists. The creation of these standards might create trust in the technology, which would in turn progress the market and increase adoption. Some argue that standards should not emerge until the technologies mature. Moving too quickly towards standards could curtail further innovation. Standards might unduly shape what sort of innovations occur or prevent certain questions from even being posed, much less answered.

Businesses also care about low switching costs and barriers. Nobody wants to get locked into the wrong solution, especially given the newness of the technology. Businesses want switching costs low so they’ll have the flexibility to switch solutions if needed and to interoperate with systems. Many businesses have adopted a hedging strategy to ensure flexibility. They’ve invested resources in many initiatives because nobody is informed enough to pick a clear winner. Many businesses are in an information-gathering stage, keeping their fingers on the pulse of several blockchain applications instead of doubling down on one solution. That said, doubling down on one solution, however, does grant enterprises certain advantages. By committing firmly to one specific application, a company can focus its efforts and resources.

What Technical Questions Remain Unanswered?

The business concerns mentioned above are only half of the equation. To balance the equation, one has to acknowledge the technical considerations currently being addressed by consortia, open-source projects, and startups. The three most pressing technical questions are:

1. Can an asset be locked in one chain while another chain processes transactions relevant to that asset?
2. Can interconnectivity be automated rather than just use custom-built application programming interfaces (APIs)? APIs allow one application to create, read, update and delete data in another application
3. Can it be verified that data reads from the permanent ledger and not from a temporary soft fork ? A soft fork is a temporary branch of the ledger; they have a variety of uses but mostly are used to implement new functionalities that are backwards compatible.

Asset locking remains important because blockchain’s digital ledger is immutable – once it is written, it cannot be altered or deleted. Blockchain requires a waiting period before a response is validated. This verification takes time – the current transaction speeds for Bitcoin are 7 transactions a second whereas Visa and Mastercard can process thousands of transactions per second.

Automating interconnectivity between two or more blockchains has been the focus of projects such as Accenture’s Interoperability Node and BitGo’s multisignature wallet. This node demonstrated that information can be shared between R3 Corda and Digital Asset and between Hyperledger Fabric and Quorum. David Treat, the Managing Director and co-head of Accenture’s Global Blockchain Practice, argues that this node reduces the threat of vendor locking: “[the node is] mitigating key concerns about picking the ‘wrong’ platform or having to re-build if one partner uses something differently.” While this node has a greater level of security than a single notary or exchange (which are often targets of cyber-thieves), trust is still centralized in Accenture’s product. BitGo’s wallet grew out of concerns after Bitfinex’s 2016 hack and now serves as the custodian to more than $2 billion in digital assets and operates in more than 50 countries. Multisignature nodes require multiple signatures to verify a transaction after the assets have been locked. While slightly different from Accenture’s product, parties must still trust the federation, which acts as a de facto trusted third party.

Reliance on single payment verification allows transactions to be verified without running a full network node. Basically, it lets a party prove that its transaction is part of a valid block and that many other valid blocks have already been built on top of it. Another way of coordinating transactions across multiple blockchains are hash-time locked contracts. These contracts rely on the same data trigger, which is often called a “secret key,” “private key,” or “preimage.” Here’s how that process works:

• Jack initiates a smart contract on one blockchain that locks value into an address that contains the hash of the secret key.
• One of two things then happens – the receiver, Jill, either retries the value in the address using the secret key (the hash lock) and her digital signature or the contract expires and returns the value to Jack (the time lock)
• Jill can get the secret key by creating a smart contract on her chain and locks value using the same hash of the secret key. Jack must reveal the secret key and his digital signature to unlock the value in Jill’s contract
• The instant that happens, Jill’s smart contract learns the secret key and uses it to unlock the value on Jack’s smart contract

Overall, it is too soon to determine the best ways to approach interoperability for a rapidly changing technology. One thing that is possible, however, is to determine whether a blockchain solution works for your enterprise.

When Does a Blockchain Solution Make Sense?

How do you know if a given use case calls for a blockchain solution? When do you need immutable records and distributed trust? Asger Pedersen, Marten Risius, and Roman Beck’s recent MIS Quarterly Executive article, “A Ten-Step Decision Path to Determine When to Use Blockchain Technologies,” contends that a blockchain solution makes sense when all of these criteria are met:

• Do you need to share data?
• Do multiple parties update the database?
• Do said parties have conflicting incentives?
• Do all parties want to avoid a trusted third party?
• Do governing rules regarding who can see and/or do what vary?
• Do you need immutable records?
• Do you have stable transaction rules that allow for smart contract?

As a manager or key decision-maker, if you don’t meet all these criteria, your specific use case will likely not require a blockchain solution. What if your case does meet all of these criteria? What do you do then?

If you’re in a situation where blockchain might make sense, the following tips might ease adoption and ensure a successful test run.

• Review the ecosystems revolving around specific business applications – learn what sort of data and governance standards existing blockchain ecosystems are using
• Participate in technical projects so key staff members will understand what it’ll take to execute an actual business case
• Temper your expectations: although the technology is rapidly changing, most experts contend that we are years away from universal interoperable solutions that can connect blockchains seamlessly
• Prepare for – and advocate for – multi-vendor, platform agnostic platforms; be wary of solutions that carry the potential of vendor lock-in. Vendors understand this wariness, which is why companies such as IBM have opened its blockchain platform for use in a variety of different computing infrastructures.

Interoperable systems, while not here yet, are coming. The question for you and your organization is what that interoperability needs to look like. The top-down business considerations and bottom-up technical considerations may vary. One constant that you can bank on, though, is the need to balance these two considerations in a way that best suits your business.