By Richard Gendal Brown, CTO
This piece originally appeared on Forbes.com
In my last article, I argued that truly interoperable enterprise blockchain platforms need to possess five key ingredients of interoperability:
In this piece, I look at some real-world examples of each of these ingredients in action, across a range of industries.
The home-buying experience is different in every country but few can be more painful than that endured by people in England, Wales and Northern Ireland. There are so many different parties, all trying their best, but none with the full picture. It falls to the home-buyer to coordinate the end-to-end process. Coadjute is fixing this. They’re helping all the players in the process – estate agent, mortgage company, building surveyor and so on – get into sync about what is happening, who is doing what and what the next step is.Except there’s a problem: tens of thousands of firms in multiple niches across an entire industry are not going to throw away their existing applications just because a clever start-up tells them to! The solution needs to work with, not against, the existing platforms and business processes.
And this drives the need for our first ingredient of interoperability: integration. An enterprise blockchain platform must make it easy to talk to existing applications, through whatever APIs or other access techniques they provide.
Once we’ve solved the integration problem, we can move on to the next most pressing problem: off-ledger payments. A key requirement for anybody managing a supply chain is the ability to make payments. There are lots of firms working to make this a reality.
Take Mastercard. Did you know they are active in international payments beyond cards? For example, they own VocaLink, which owns or operates several major domestic payments infrastructures around the world. Mastercard are developing a new cross-border payments solution using enterprise blockchain technology.
Their new platform needs not only to integrate with the existing systems, it needs to go deeper… we need to be able to initiate, seamlessly, a payment across one or more of these rails from a smart contract and automatically update that contract when the work is proved to have been done.
Users must be provided with an almost out-of-the-box ability to initiate payments and other transfers on existing rails. Institutional-grade cross- and off-ledger settlement is going to be massively important in 2020 and beyond.
Now, once we’re able to connect to existing systems and to initiate asset transfers on existing rails, it’s time for the fun stuff: getting two entirely different blockchain networks to talk to each other! This is what a lot of people mean when they just say “blockchain interoperability”.
We’ve been preparing for this as an industry for some time. It’s how a firm who is financing through one blockchain network could gain seamless insight into the underlying shipping lifecycle even if their logistics providers are using entirely different blockchain networks.
To take some examples, here is Accenture talking about a Corda-Quorum interchain scenario, here is IBM talking about how platforms like Corda, Hyperledger Fabric and more can communicate, and here is Deutsche Börse talking about Corda/Fabric interop.
But… there’s also a very special case of cross-blockchain interoperability… the case where the networks at each end of the connection turn out to be running the same platform. Intrachain, if you like. And there is a surprisingly valuable benefit you can achieve in such a case if your platform is designed to exploit it…
Do you have an iPhone? Find somebody else who also has an iPhone. Ask for their number and give them a call. Look at your screen.
Did you see what happened when they picked up?
This is quite remarkable. Two devices, communicating over a standardized interoperability layer, the public telephone system, that somehow manage to do things that the lowest-common-denominator interoperability layer doesn’t and can’t support!Wouldn’t it be great if you could do the same thing with blockchain interoperability? Support lowest-common-denominator standards for maximum reach but also upgrade the experience if the technologies at each end of the connection turn out to be the same?
Like so many Apple innovations, it’s obvious once you see it: if you can detect that both phones are iPhones, then you can upgrade the experience on a case by case basis.
It turns out you can pull off a similar trick with blockchains, too.
This is an example of what I call intrachain compatibility.
Consider Corda Network: an independent, not-for-profit, shared, neutral, open platform onto which multiple independent Corda blockchain projects can be deployed. Think of it as like an ‘internet of Corda nodes’. My colleague James Carlyle recently argued it could be seen as an example of a public, permissioned network, in effect.
Shared networks of Corda nodes like Corda Network provide a super-power to groups of nodes running different applications on such networks… it makes it possible for them to interoperate seamlessly with other applications’ nodes on the network should they choose to: the fact that it’s the same platform at “both ends of the connection”–Corda in this case–means we can massively increase the fidelity of the connection: easier consensus, richer data, shared business logic.
This type of ‘high fidelity interoperability’ will be increasingly valuable for projects in the same or related industries such as insurance and trade finance.
So far, we’ve focused on how two blockchain deployments can ‘talk’ with each other. But there’s another type of interoperability that businesspeople care about: being able to de-risk their investments by taking a solution designed for one platform and interchanging the underlying platform for another, without having to throw away all your existing work.
Support for large industry ecosystems such as those underpinning Java, with its reusable tools and libraries, really helps here.
And some teams are trying to be even more ambitious: writing apps that can be moved between platforms without any significant porting at all.
That’s a tougher trick to pull off. When you implicitly target multiple platforms, you’re also optimizing for none. Think back to the bad smartphone apps you’ve used in the past. I bet a lot of them tried to be ‘agnostic’ between Android and Apple’s iOS. The successful apps, the ones you use every day are usually the ones written natively to the underlying platform, optimized to take advantage of every feature.
Indeed, Facebook recently wrote about how they massively improved the speed, maintainability and user-experience of Messenger by writing versions that were tightly targeted to each supported platform.
So this is the one ingredient of interoperability where I think the jury is genuinely “out” on the right approach. But it’s important to keep a very open mind; the prize is so large. One such example is playing out right now, with the Digital Asset Markup Language. And it looks pretty interesting. If your project has the capacity to run a dual “optimize for native integration whilst also exploring ledger agnosticism” strategy, it could be the one to watch.
So there we have it: to solve the blockchain interoperability puzzle we need to make sure our solutions contain all five ingredients:
The diagram below tries to bring the story together by imagining how a trade finance application, Marco Polo in this case, running on Corda, already integrates with existing ERP systems, could easily settle payments coming due by initiating transfers over existing rails, perhaps even in the future connecting interchain to Vakt on Ethereum or CargoSmart on Hyperleder Fabric, connecting intrachain with Contour, which also runs on Corda, and maybe even absorbing capabilities from as-yet unidentified projects that decide to interchange their old platform for the one on which Marco Polo, Vakt or CargoSmart runs on. The interoperability prize is massive if we can get it right.But, when I look around the market, I see many blockchain projects struggling with just the basics, because the technology they’re using can’t easily initiate payments on existing ‘rails’ or because two deployments of the same platform can’t upgrade to FaceTime-like levels of intrachain fidelity and are stuck in the first-gear of interchain interoperability.
The lesson I’ve taken from all this is that we as technology providers should work hard to support all five ingredients. And consumers of the technology should demand we, the providers, show how they support all five ingredients of interoperability.
Share this post
Blockchain for every business in every industryLearn More
Stay up to date on the latest news and articles related to R3.