Blockchain Interoperability: Towards a Simpler Debate

Blockchain Interoperability: Towards a Simpler Debate

R3 announced a new approach to interoperability this month, the Corda Settler. It may have Corda in its name but don’t let that fool you; the underlying concept — don’t worry… it’s not yet another new protocol! — can be easily implemented by any platform and it could supercharge the blockchain interoperability debate.

It seems like every day, a new “blockchain interoperability” protocol concept is published. Interledger Protocol, Polkadot, Sidechains, Ion, Cosmos, you name it…

Do we really need them all? How can there be more interoperability protocol designs than there are live enterprise blockchain deployments?!

The business need for interoperability is unarguable, of course: as Lee Braine of the Barclays CTO Office recently observed:

“the potential benefits of shared ledgers and tokenization [may] be diluted because different platforms won’t be able to … communicate the full richness of what they need to communicate… there should be a focus on determining how to get the different DLT platforms interoperating.”

And yet, despite this obvious need, little progress is being made. I think this is because we’ve tried to do too much too soon as a nascent industry. We need to simplify the problem, massively.

In this piece I argue that the journey to an interoperability strategy for our industry starts with a radically tactical first step, and this is why we might come to look back at the recently open-sourced “settler” pattern as a major breakthrough.

What problem are we trying to solve?

The Oxford English Dictionary defines “interoperability” as “the ability of computer systems or software to exchange and make use of information.”

This seemingly simple definition is surprisingly profound.

Imagine it had just said “the ability of computer systems or software to exchange information.” That would have been trivial.

But there is that annoying extra little bit: “make use of.”

And this is where the underlying nature of blockchain systems rears its ugly head.

What is the external information a blockchain system needs to “make use of”?

Typically, what we need to make use of is important stuff like: has a payment we were waiting for on that other ledger actually happened? Has an asset been moved safely into escrow on that other platform?

At the heart of this is information that will directly influence the output of the consensus process on your ledger but which arises extrinsic to that very same consensus process.

We’re talking about signatures from authenticated, trusted third parties that a payment that occurred elsewhere did indeed take place. Or evidence from another blockchain platform that some transaction has been confirmed.

Information whose provenance we care about, whose meaning we need to elicit and whose permanence must be assured.

That last bit sounds a bit weird, but it is key to blockchain platforms. After all, a technology that depends on deterministic execution and transactions that are confirmed with finality cannot safely “make use of” information that itself could subsequently turn out
to have been overturned or rolled-back!

And this, I think, explains why there have been so many attempts to design an “interoperability protocol to rule all interoperability protocols.” It’s more more difficult than the problem of simply moving data around, because we also have to agree on how this data will be authenticated, how it will be validated, and how we will determine whether the information is irrevocably persistent in the source system.

And yet: to deliver the promise that “I know that what I see is what you see” across platforms as well as within a single platform, we have to solve this problem.

And that means competitors working with competitors — to agree on some minimal common patterns and techniques we can all agree to use.

That’s easy to say and hard to do, of course…

Thankfully the answer may be staring us in the face… we just need to radically simplify how we think about things…

The Blockchain Indifference Principle

I think the key to move the debate forward is to adopt a very simple principle when reasoning about or implementing interoperability protocols in the blockchain space: we shouldn’t care whether the foreign ledger with which we’re trying to interoperate is a blockchain or not.

We should be indifferent.

The Blockchain Indifference Principle:

“When an action on a blockchain network is contingent on an event on some other platform having occurred with finality, we should be indifferent as to the nature of the other platform.”

In other words, if an interoperability protocol makes assumptions that the foreign network is a blockchain or even that it has a particular architecture, then it’s a sign that we’re probably doing it wrong.

We shouldn’t be ashamed to be tactical

The history of Corda has a huge dose of serendipity at its core. Originally designed to solve a surprisingly narrow set of problems in the financial markets, we woke up one day and discovered we’d inadvertently built a general-purpose platform suitable for multiple industries!

It was as if going really deep and focusing on a very small number of scenarios helped us crystallise a design that captured a far broader truth about the nature of consensus systems in business. It wasn’t the intention, but we and the users of Corda across multiple industries are happy it worked out that way.

I’m beginning to think we may be able to do something similar when it comes to interoperability.

As I argued above, the heart of the interoperability problem is figuring out how one platform can determine to its own satisfaction that something truly has happened somewhere else.

So what if we just focused on a single problem through that lens?

Imagine the thing you want to know for sure actually happened was a payment. A plain old simple payment. Maybe a Bitcoin transaction. Or an XRP transaction. Or a payment across SWIFT. Any kind of payment.

If the obligation to make that payment arose on one ledger but the payment itself will happen on a different ledger, then the absolute smallest problem you need to solve is:

• Agree how this payment will be made. Over which network? To which account? When?
• Agree what will constitute evidence that it actually happened. That is: what evidence will the recipient on the first ledger need to see to convince them that the payment really did happen on the second ledger without them having to go check for themselves?

That’s it.

If two or more parties on one place can agree on these things then we have all the information we need in order to achieve this simple level of interoperability.

Note how this is a very tight problem definition. It doesn’t try to solve every problem in the world but it does provide a building block for more complex interoperability scenarios such as atomic swaps and so forth.

So we can start small: solve the one-way-payment-with-certainty problem and build from there.

“Here’s how I want you to pay me and this is the evidence I will accept as proof it happened”

And it’s deceptively generic:

• If the foreign ledger is a traditional RTGS system, the “evidence” might consist of a transaction data structure, perhaps in ISO20022 format, describing a fiat money payment between two accounts, with a specific reference string, signed by the receiving bank. It is trivial to write code to verify this on pretty much any platform. No complex re-engineering of the world.
• If the foreign ledger is a platform that uses a validator-list-based approach to defining the byzantine-fault-tolerant consensus provider set, such as the XRP ledger, maybe the evidence is not a signature from a trusted third party but a Closed Ledger data structure containing the transaction in question, signed by
  a supermajority of unique nodes.
• Perhaps the evidence needed if the remote ledger is Bitcoin is a Bitcoin transaction with a proof that it appears in a block that appears with sufficient work under a sufficient number of other blocks.
• Or perhaps the evidence is simply the pre-image to a hash. If the intended recipient had revealed that pre-image to their bank, with the instruction to reveal it only if the bank is satisfied the money has arrived, that would be sufficient. Anybody familiar with the Interledger Protocol will recognise this approach.
• And so on.

In other words, the form of the evidence may vary from one scenario to the other and can be agreed by the parties to the underlying obligation, but the pattern is consistent: the foreign ledger supplies a single piece of information, which participants on the local ledger had pre-agreed would constitute satisfactory evidence that the event in question had occurred, without requiring further reference to the other ledger or to other participants on the local ledger. This single piece of evidence is the entire proof. And it has been pre-agreed that it will be sufficient: no need for the recipient to go check that it really, really, really did happen.

That last point is really important: we in the enterprise blockchain space are in the business of building systems that bring people to consensus about business facts they care about and keeping them in consensus. The last thing you want is to “drop out” of that process and have to revert to phoning each other to say: “I sent the payment… did you receive it?!?!” Our architecture has to remove all such sources of doubt and reconciliation.

Introducing a Generic Tactical Architecture for Cross-Ledger Settlement Interoperability

So if we believe the foregoing, what might a path forward for the industry be?

Here’s what I think could be a path forward and which is embodied in the Settler pattern and open-source codebase. I’ll outline the idea through a worked example.

A simple scenario: settling an obligation

Let’s first assume our scenario is the simplest one. A one-way payment. Let’s also assume we’re using Corda, since that’s the platform with which I’m most familiar. But, as will become clear, nothing in this description requires Corda.

Let’s imagine you and I have been using Corda to manage a business relationship between ourselves. And, as a result of this work, I now owe you some money. I am obliged to deliver $100 to you some time tomorrow. We call this an “obligation”; you may also like to think about it as an IOU.

So there is an obligation contract on Corda, held by you and me, recording that I am obliged (hence the name…) to pay you $100.

Now, if you’re happy to have those dollars settled over the Corda ledger there’s nothing to worry about. That would be trivial if your business app and some USD coins were deployed to the same Corda network. That would be an example of compatibility (I have a companion post about this, which will go up soon).

But let’s assume that’s not the case. Let’s assume the payment is going to happen across some other network.

Negotiating how the obligation will be settled

• So what can we do? Well there’s a bit of back and forth we need to do to agree all the details… an inter-firm workflow, if you like.
• Happily, the Corda flow framework is excellent for this. Some other platforms may have something similar.

Agree the settlement mechanism

• I owe you $100 value but which currency would you like me to settle it in?
• Let’s make things interesting… how about XRP?!

Finalising the value of the payment

• OK… so how many would that need to be? Let’s check an exchange rate oracle… it’s about 344 XRP at the time of writing
• Great… so let’s update the Obligation contract on Corda to reflect the amendment to the agreement.

Where should I send the money?

• Now I need to know where to pay you. What’s your XRP address?
• Let’s update the obligation to record that too.

What evidence must I obtain to convince you and other nodes on the Corda ledger that the XRP payment actually happened?

• And now for the fun part…. What evidence will you accept as irrefutable proof that I actually did it?
• Recall our objective: we want to define a piece of information I can obtain from the foreign network — the XRP ledger in this case — which my node and all other relevant nodes on the Corda network — including YOURS — will all interpret as proof the payment happened and did so with finality.
• We have a few choices. The best would be for us to agree on an XRP transaction data structure and compare our respective XRP “Unique Node Lists”, and maybe agree we want to see signatures from a pool of 80% of the overlapping entities. If I can obtain enough signatures over this data structure, you’ll be satisfied. And note: that would be quite easy to do. We don’t need to “teach” Corda about how the whole of the Ripple architecture works. We just need to code the “settler” CorDapp how to create and parse an XRP data structure and check some signatures. A much simpler problem.
• But let’s go even simpler for this example. We’ll assume there’s
  a third party out there that we both trust. Let’s ask them to observe the XRP ledger and, when they see the transaction has been confirmed, they’ll sign a Corda transaction to confirm. Yes — I know this isn’t fully realistic for real life — but it makes the explanation here easier…

Making the payment, securing the evidence from the foreign ledger and providing it to the local ledger

• So we update the Corda transaction to record which oracle we will use.
• I now make the payment across the XRP ledger, including the relevant reference number as a memo.
• I then forward the ID of the XRP transaction to the oracle, along with a transaction that will update the Corda obligation contract from “pending” to “done”, inviting them to sign the latter when they are satisfied the former has settled, and return it to me.
• I get this Corda transaction notarised and forward it to you.

And that’s it!

• I have provided you the proof you requested (in this case, a signature over the relevant Corda transaction from a trusted oracle — it’s a simple example, recall) and since you had pre-agreed this would be ample proof, your Corda node automatically updates to reflect that my debt to you is settled. No messing around checking whether the payment arrived or inconsistency, delay, prevarication or reconciliation needed. We’ve moved all sources of such confusion out of the way.

This video shows it in action:

In the video, we see a simple workflow being executed on Corda to agree precisely how you want to be paid, what will constitute evidence and who needs to sign it. We eliminate all sources of disagreement or confusion up-front.

And then I just need to make the payment, secure the relevant evidence, which will be specific to the target network — XRP in this case, and then provide it to your node on the local network, which updates its records to reflect that the obligation has been settled.

Open Source Code to Demonstrate the Concept

We’ve recently written some sample code to show this in action. We call it the “Corda Settler” but, really, any platform could implement it. It’s designed to require utterly minimal changes to source or destination. This is all about moving the interoperability debate forward without requiring huge up-front work by any platform, old or new.

Roger has additional technical information in this embedded video.

And you can join us over at the repo.

We’ve implemented XRP support already via the simple oracle model outlined above.

And more integrations are in the works.

You can also read more about it here or listen to the team discuss it on “Life in the Fast Chain”