R3 Corda: What Makes It Different

R3 Corda: What Makes It Different

As reported by Reuters last week, Corda, the Distributed Ledger platform we’ve been working hard on at R3 for the last year at will be open sourced on November 30.

What is it? Why are we building it? What happens next?

Corda is a distributed ledger platform designed and built from the ground up for the recording and automation of legal agreements between identifiable parties. It is heavily influenced by the requirements of the financial industry but we believe the community will find the underlying architecture will lend itself to a broad range of applications.

Corda is quite unlike any other Distributed Ledger platform that currently exists. So we’ll be releasing lots of information in the coming weeks and months. To understand why it looks the way it does, I thought I’d share the journey we went on to build it. In subsequent articles, the team and I will share more detail about how it works and what to look for when it’s released on November 30.

But first, some history.

The very first decision made by the Steering Committee of the R3 consortium was to establish our Architecture Working Group, which I chair. This group consists of hundreds of senior architects, technologists and developers, many with decades of experience in a dazzling array of areas, from across our membership over over seventy financial institutions.

We were given a simple-sounding mission:

“To establish the architecture for an open, enterprise-grade, shared platform for the immutable recording of financial events and execution of logic”.

There is quite a lot packed into that sentence..! Let’s look at just two parts:

• “Open”
  I stated publicly in April that we would open-source Corda and I was serious. Our mandate, from our member banks, was that whatever base platforms we selected, built or adopted had to be open. We’re delivering on this commitment with the open-sourcing of Corda on November 30.
• “Immutable recording of financial events and execution of business logic”
  Notice what this doesn’t say. It doesn’t say “blockchain”. Heck: it doesn’t even say “distributed ledger”! Instead, it tries to get to the heart of what we think is the essence of this exciting new field. And that’s what I want to talk about in this blog post.

We don’t like solutions looking for problems

I wanted us to be precise about what this field is all about. After all, and as I wrote when we first announced Corda, Satoshi Nakamoto didn’t wake up one morning thinking: “I really need a blockchain!”. No: he started with a well-defined business problem and engineered a solution to solve that problem. And if you need a system of censorship-resistant digital cash, then Satoshi’s design — Bitcoin — is the elegant solution and it’s available today.

And that’s why Ethereum, to take another example, looks so different to Bitcoin. Vitalik Buterin and his colleagues started with a different business problem, which I characterise as “I want an unstoppable world computer that can execute business logic and move value autonomously” and guess what? They ended up with a very different design! Now sure: there are many similarities between Bitcoin and Ethereum but also a lot of differences.

I was determined that we would not fall into the trap of taking technologies designed to solve completely different problems and blindly apply them to banking. That way lies madness.

So we drove two key pieces of work: 1) characterising exactly what is new about this field and 2) identifying precisely where in finance it may have most applicability.

And the answer, as I outlined back in April, is that there is something genuinely new in this space and it’s something that is massively relevant to the financial system.

The definition I think best captures this is as follows:

“Distributed ledgers — or decentralised databases — are systems that enable parties who don’t fully trust each other to form and maintain consensus about the existence, status and evolution of a set of shared facts”

Let’s first test that this definition works for existing public systems:

Bitcoin: the participants don’t know each other’s identities and come to consensus about how many bitcoins there are, which addresses own them and what needs to happen for any of them to be spent without having to trust each other. Check!

Ethereum: the participants don’t know each other’s identities and come to consensus about the state of a virtual computer. Check!

In those systems’ cases, they achieve these outcomes in ways with which we’re both familiar and which address requirements related to the environment in which those systems are expected to run.

But how about finance… parties who don’t fully trust each other but whom need to be in consensus about a set of shared facts?

Where do we have that problem?

Erm… how about everywhere..?!!

It’s perhaps only a slight exaggeration to suggest that the financial industry is pretty much defined by the web of contracts that exists between its participants: I deposit money with a bank? There’s a contract there that says the bank owes me that money. You and I enter into a Credit Default Swap? There’s a contract there that describes our mutual rights and obligations. And they’re recorded and managed in multiple places, on different systems, managed by different firms and it costs a fortune to keep them all in sync.

The shared facts in finance are the existence and state of financial agreements — ie contracts.

And the need for consensus is what amounts to the twenty-first century’s “paperwork crisis”: the tens of billions of dollars spent annually maintaining and managing the duplicated records that each firm maintain about the same deals. The same information about a deal is recorded multiple times across these parties and in situations where a centralised solution can’t be deployed, which is in lots of places, small armies are required to ensure that these disparate records agree with each other, get updated correctly and in synchrony — and deal with the issues when they don’t.

A ha! So now we have something phenomenally exciting: a new technology for establishing and maintaining consensus between parties who don’t trust each other. And a multi-billion dollar business problem crying out for this solution!

There’s only one minor problem…

Public systems like Bitcoin were not designed to solve these problems. They’re excellent at what they do; but we’re doing something else.

And you only need to take a cursory look at the architecture of various public blockchain systems to see why this might be the case. My business problem amounts to ensuring the Bank of Alice and Bank of Bob agree about a trade they just did and that it settles automatically and correctly. A solution which not only shares this confidential data with every other bank in the world but which also requires them to process the deal and maybe even validate it doesn’t meet my needs. And yet… that’s how every single public platform back in 2015 worked.

Perhaps those architectures can be heavily re-engineered to solve such problems, as some groups are attempting but it’s not an obvious starting point, especially when you then layer on all the other requirements we identified.

So there’s a problem: Bitcoin and its successors taught us that a new way of building distributed systems was possible: one where mutually distrusting parties can maintain a shared database. We identified a hitherto unsolved problem in finance. And yet the technology that existed simply wasn’t designed for this.

Coding, not talking

The reality is that finding fault is easy; proposing workable solutions is altogether harder. So simply going out and shouting about how 2015’s platforms didn’t solve our problems was hardly a way to make friends. No. We needed to do better than that.

So once we had decided we needed to prototype the alternate approach we had identified, we made a critical decision to buttress my leadership team of James Carlyle and Ian Grigg: we brought in Mike Hearn.

And he drove the prototyping effort to explore these concepts in the only way that gives you certainty that it can be done: by proving it in code. As Mike enjoys reminding me: when it comes to core concepts, talk is cheap; at some point, the talking has to give way to coding.

Early results were promising: the reductive, bottom-up approach we took to architecture and design, which is explored in our introductory whitepaper and on which we’ll elaborate in the coming weeks, was solid: we could model a diverse range of instruments; the design would allow for significant parallel processing; we did not need to send all data to all participants in all scenarios; the use of a mainstream virtual machine and its libraries led to high developer productivity; we were able to support multiple consensus providers on a single network; the use of a flat, point-to-point queue-based, peer-to-peer network mapped well to real business scenarios; and more.

We worked with our members to test the maturing codebase in a variety of contexts: interfacing Ricardian Contracts and Smart Contracts in the context of an Interest Rate Swap with Barclays and others; managing trade finance flows; and more.

And this focus on validated client requirements and a willingness to question some hitherto sacred beliefs (we have no blocks! we have no miners! we don’t put ephemeral data in the consensus layer! we allow per-transaction specification of consensus providers!) led to a unique design.

Had Corda ended up being a minor variation on an existing platform or a me-too copy of something else, what would have been the point in pursuing the work? But that isn’t what happened: we ended up with something quite distinct, something we believe is singularly well-suited to a wider variety of financial-services use-cases and something adapted to the practical reality that the industry is regulated and some rules simply aren’t going to change overnight.

So that’s the backstory. Our large — and growing — technology team still has a large amount of work to do. But now is the time to share our work with the broader community and encourage people — including in other industries — to use it for their own applications as it matures (it’s still a young codebase), to contribute to Corda itself, and to contribute to the architectural debate.

We’re looking forward to November 30. This is an exciting time!