Tag Archives: Corda

Standard

Posted by

Posted on

February 21, 2017

Posted under

consensus, Corda, Uncategorized

Comments

19 Comments

The Corda Way of Thinking

The Corda Way of Thinking

Corda is a revolutionary new Distributed Ledger Platform, the only DLT specifically designed for the needs of financial services. This article introduces the “Corda Way of Thinking”: understand this article and you’ll be well on your way to being a Corda Expert Solution Designer…!

What problem are we trying to solve with Distributed Ledgers? 

The world is full of people who need to collaborate, trade and transact.  And, to do that, we need to know that the agreements – the contracts – that underpin their relationships are clearly documented, clearly understood and consistently recorded.

The promise of DLT is that we can all have our own records and yet somehow, as if by magic, they all stay in sync whenever somebody legitimately updates any of them.

Corda achieves this in a unique and massively powerful way. And this article explains it. And to prove how easy it is, we’re going to do it without computers…

Imagine we live in a world where all we have is paper, photocopiers and the postal service…  How could you keep a network of trading partners around the world in perfect sync with each other?

Building a Distributed Ledger with paper, photocopiers and the postal service

First, let’s imagine I have a filing cabinet filled with papers… each sheet represents a specific piece of information that I share in common with at least one other party… maybe it records a deal or a loan between us or is my healthcare history and you’re my doctor. Each piece of paper could record anything.

And you have a filing cabinet full of your papers … In fact, everybody has their own filing cabinet with their own papers.

And each paper is numbered – so it’s easy to find.

If you and I share a piece of information in common then we’ll both have a copy of that record: it will have the same number and contain precisely the same information.

picture1

In the diagram, we see that Richard and Albert both have a copy of record #128, Albert and Harrison both have a copy of record #140 and all three of them have a copy of record #132.

Each person’s filing cabinet only has papers that relate to their own business dealings with some other person or people. For example, Harrison doesn’t have a copy of record #128 because he is not involved in that deal.

OK – so that’s the set-up. I have a filing cabinet full of numbered papers, you have a filing cabinet of numbered papers, everybody has a filing cabinet of numbered papers.  Each sheet of paper represents a contract or agreement or deal or other interesting fact… and anybody who needs to have one has an identical copy.

Let’s look a little closer at record #128.   This is a record that I (Richard) and Albert both have.

picture2

Record #128 is a piece of paper that both Richard and Albert have.  It records a bet they have entered into.

It turns out that this piece of paper records a bet between me and Albert: if it rains in London on Wednesday, he owes me $10; if it doesn’t, I owe him $10. A weather report from a reputable newspaper will serve as proof. Pretty Simple. But note that the ideas we’ll be talking about work for more complex, multi-party situations, too.

So, as of right now, we’re in consensus. We both have the same details of the bet and are in agreement about it.

I know that what I see is what Albert sees.

picture3

Both Richard and Albert have a perfect copy of the record which records the existence of the bet and its current status (that we’re waiting to find out if it rained or not on Wednesday)

As you can tell, we’re starting in the middle of this story and you’re probably asking yourself how we came into consensus in the first place!  Don’t worry – we’ll get there!  It just happens to be easier to tell the story if we jump right into the middle.

Time passes…. And now it’s Thursday.  It’s time to resolve the outcome of the bet: did it rain yesterday or was it dry? We need to come to consensus on this and agree who owes the $10 to the other. And we need to update our records to record this updated information perfectly and consistently.

I can reveal that it… RAINED!  This means I win!!

And I have a report from the Wall Street Journal to confirm how wet it was. As I know you weren’t simply going to take my word for it…  And, as it happens, the terms of the bet demand that the winner provides proof to the loser for their records.

picture4

My newspaper confirms that it rained yesterday.  I will need to send a copy of this proof to Albert soon.

So we now have to update our shared record. We need to record that an external observation has been made, that it confirms that it rained and that you therefore owe me $10.

This is the key problem we’re trying to solve: bringing parties into consensus about the evolution of shared facts.

Our shared fact, of course, is the existence, nature and detail of a bet we’ve entered in to. And the evolution is that I now know that it rained and need to make sure that you know this and that you owe me the money.

Now – and this may seem a bit strange – we’re not actually going to edit or amend our pieces of paper; we’re going to create new records that completely replace the old ones.

That’s because in complex scenarios with huge numbers of events and updates, we’d be crossing things out all the time, making amendments and gluing new pieces of information at the bottom. It would be a total mess.  And we’d lose all ability to look back at history to remind ourselves what had happened in the past, with certainty that the historical record was completely tamper-free.

But that’s OK… paper is cheap… so it’s really no hardship to fill out a new blank sheet to record the new status of any agreement in its entirety from scratch each time something changes and replace the old version with this updated, newer version.

So what I’m going to do is fill in a brand new piece of paper with all the updated information of the bet.  And our challenge is to figure out a way to make this piece of paper replace the previous one as the dominant, current record of our deal for both me, Albert and anybody else who has a copy (perhaps a regulator or his accountant).

picture5

I know it rained and that I won the bet so I want our shared record (#128) to be replaced with an updated record (#156 in this case) that contains the latest information about the bet

So I pull out the original record, #128, from my filing cabinet – I’ll be putting a big red line through it later, and sending it away for archiving – and I start writing a letter to you.

In that letter, I reference this piece of paper – each piece of paper has a unique number at the top, remember. The letter goes something like this:

“Hello Albert!  Richard here.  Remember that bet we entered in to? You should find it in your filing cabinet under reference #128.  As you know, the bet related to yesterday and guess what? It rained in London! I’m attaching a copy of the newspaper report as proof. Sorry old chap, but that means you lost. So you owe me $10.  I’m attaching a new piece of paper that fully summarises the terms of our bet and memorialises that it did indeed rain and that this means you owe me $10.  I think you’ll find per the terms of the gambling rulebook we agreed to abide by mean you’re obliged to update your records with the attached sheet of paper.  I have done likewise.  You can pay me next time we meet.  Cheerio! Signed Richard”

picture6

I write a letter to Albert explaining that he needs to remove record #128 from his filing cabinet and replace it with record #156, which I’ve attached and which records that he now owes me $10. I include a copy of the newspaper report and put it all in a letter, which I post to Albert.

I send Albert a copy of this letter, with attached piece of paper recording the new state of the deal, and a copy of the newspaper report.  I might also send a full copy to a regulator if betting is regulated in my country and to Albert’s accountant if he also had a copy of #128… this doesn’t have to just be a bilateral conversation after all.  But let’s just focus on Albert for now.

When Albert receives the letter, he digs out his copy of the old record from his filing cabinet (it will have the same reference number) to remind himself about the details of the bet. He compares this record (#128) with the new one I’ve sent (#156), checks that the updates comply with the rules in the rulebook we’d agreed to use and, because it does, he puts a big red line through the old piece of paper and sends it away for archiving.  And he then adds the new piece of paper to his filing cabinet.

picture7

Record #128 has now been superseded by record #156

We both now have identical, updated versions of the contract in our filing cabinets.  And because we’d pre-agreed to use the same rulebook there can be no ambiguity: I had provided the proof necessary to move us to an updated version of the agreement. He makes a mental note to pay me next time we meet and we’re done.

Now, in this case, it was pretty simple. This example only required one letter to be sent:  mine to Albert.  The newspaper proof left him with little choice but to accept the updated record.   But you can imagine scenarios where Albert needs to reply back or maybe even write to somebody else before we can conclude that the new record has superseded the old one.  It’s these complexities that Corda handles for us – but which aren’t necessary for understanding the core concepts.

Now… if you’ve got this far and understood all the concepts then you know pretty much everything you need to know to build solutions on Corda.

Corda is deliberately and powerfully simple 🙂

So let’s map this example to how Corda actually works

What are the building blocks of a Corda solution?

picture2

  • All those pieces of paper representing deals, contracts, trades, balances, IOUs, loans?
    • These are Corda State Objects
    • Mental model: think of documents recording all the details pertaining to a single trade, balance, trade, agreement and so forth.
  • The filing cabinet?picture8
    • That is the Corda Vault
    • Mental model: think of the place where the most current versions of all
      your contracts and deals and trades and IOUs and bets are stored
  • Those covering letters telling your peers that you’d like them to put red lines through some pieces of paper and replace them with some new ones that you’ve attached with a paperclip and included in the envelope?
    • These are Corda Transactionspicture6
    • Mental model: think of them as letters from one party to all other interested parties suggesting it’s time to remove some papers from their filing cabinet and replace them with some new ones, which are attached to the letter, provided the recipients agree this complies with the rules we’d previously agreed.
  • The postal service?
    • That’s the Corda point-to-point messaging network
    • Mental model: think of it as being how information flows around the Corda network. We don’t send everything to everybody; just those with a need to know.
  • The rulebook that Albert used to check we’d done everything in accordance with the gambling rules we agreed to be subject to?
    • That’s Corda Contract Code
    • Mental model: think of this as being the test you apply whenever you get a new letter asking you to cross-out some pieces of paper and replace them with some new ones: is this letter asking me to do something that’s consistent with the rules I signed up to when I first entered into this agreement?  This is a fundamental component of Corda’s consensus architecture (the other being Consensus Clusters, discussed briefly below)

 

So that’s pretty much it:  pieces of paper, letters, photocopiers, the postal service. And yet it turns out to allow us to model all sorts of business problems and it lets us maximise privacy, scalability and performance: only the parties to deal need to process them and store them, for example.

Once these ideas click in your head, you’ll find yourself mentally trying to model all kinds of problems as Corda state objects, transactions and contract code. And you’ll start introducing some additional questions to your business analysis sessions.  You’ll ask questions like:

  • What’s written on the pieces of paper?
  • Whose responsibility is it to write the letters?
  • What business logic do they use to fill out the new pieces of paper and figure out which ones from the filing cabinet they’re going to replace?
  • To whom do they send them?
  • Can we do this with a single letter or do you need to provide additional information and reply to me? Do some steps require you explicitly to agree (by countersigning the letter?)
  • What rules do we need to have pre-agreed to use to check that the letters are asking us to do something valid?

And this, at heart, is the Corda Way of Thinking: a way of ensuring you’re in perfect synchrony with your trading partners that naturally and obviously maps to real-world ideas and which anybody can understand.

So, if you’ve tried to use other distributed ledger platforms and got frustrated at how quickly they got complex whenever you tried to do something that didn’t spray data to everybody or how you were expected to be a crypto expert, fear not:

Corda is different.  Corda is simpler.  Corda is better.

And now you know the secret of the “Corda Way of Thinking”.

Hang on… what about consensus algorithms??????

OK… 🙂  if you’ve studied other distributed ledger platforms, you may still have a couple of questions.  If you fall into that category, continue reading…

Consensus: How do we deal with the problem of two different letters crossing in the post, both referring to the same piece of paper in the filing cabinet? We can’t cross it out twice! So we need a way to choose which letter trumps the others.

  • Answer: Corda Consensus Services (aka “notary clusters”.)    In Corda, the question of whether an update is valid is purely a matter for those processing or verifying the transactions but we need to resolve conflicts if two transactions try to update the same record at the same time.  This is where Corda Consensus Services come in. Corda has a really innovative design here, too, allowing multiple Consensus Services on the same network, including consensus service clusters running  different consensus algorithms.   (Note: the Corda documentation also refers to notary clusters: this is the same concept, but consensus services is a more understandable name!)

Workflows: What do we do if I need a response from you before I can finish updating my filing cabinet? Do I just sit there, motionless, waiting?

  • Answer: Corda flows. These are also what we would have used to establish our first record of the deal, #128, where both of us would have needed to agree that the details of the bet were correct.

You can read more about both of these in our documentation!

Summary

I’m grateful to my colleague Chris Khan, for the awesome diagrams and Clemens Wan, for creating this table, which pulls it all together:

Analogy Component Responsibility Corda Component DLT Role
Filing Cabinet Keeps track of papers Vault Stores State Objects
Sheet of paper describing a contract or agreement or deal Represents specific facts or document State Object Stores data model and references to legal prose and contract code (the “rulebook”)
Newspaper Weather Report Provides weather at time of bet Oracle Third party trusted data source for the specific deal
Letter with cover note Tells other parties that somebody has calculated some updated papers, with evidence. Transactions Method of evolving the state objects as governed by contract code
Rulebook Provides rules that govern the bet Contract Code Provides verifications and rules that govern the state object’s evolution
Pinned paper to noticeboard Provides a copy of the cover note for others interested in the party to review and sign Corda Flow Manager Specifies transaction details for multi-party signature
Signature Proof that letter really did come from who it claims to be from Signature (digital) Proof that a transaction really did come from who it claims to be from – prevents repudiation
Postal Service Ensures letters are sent to the correct parties and delivered reliably Network Map Service & point-to-point messaging network Provides a reliable way of ensuring transactions get delivered to precisely the right parties and nobody else

 

 

Standard

Posted by

Posted on

January 24, 2017

Posted under

Corda, GSL, open source, Uncategorized

Comments

3 Comments

Towards Deeper Collaboration in Distributed Ledgers: Thoughts on Digital Asset’s Global Synchronisation Log

It’s now almost two months since we open-sourced Corda and I’m delighted by the reception it has received. In our rapidly growing community, we’re already seeing new users grow into leaders who help other newcomers get to grips with the platform.

And I am amazed by the number of inbound messages from users who have been impressed by the quality of Corda’s design and codebase – and who are already building significant applications and products on top of it. Indeed, as I write this, one of our member banks is running a global hackathon, with over 150 of their developers building on Corda and I’ve just returned from our Asia Members’ Conference in Hong Kong, where I sat through so many presentations about Corda projects I didn’t even know were happening…

If you’re not already on our Slack or participating in our discussion forum, you’re missing out!

But one additional benefit from delivering on our commitment to make Corda Open Source is that it means we can explore opportunities to collaborate with peers, competitors and partners across the ecosystem: identifying areas where our visions are aligned, where we see things the same way and where we might be able to reuse rather than needlessly reinvent.

A good example of the potential for firms who some might see as competitors (but who actually aren’t…) to collaborate was provided late last year in the form of an excellent whitepaper from Digital Asset: The Global Synchronization Log.  The paper helps clarify some really important aspects of distributed ledger design and shows a really deep understanding of the tradeoffs that are inherent in the design of these platforms.

The first time I read the paper, I was struck by how closely our two firms’ visions for DLT are aligned. As Mike Hearn has written, there are two fundamentally different ways to design a DLT –“UTXO” or “replicated virtual machine” – and it was very encouraging when I realised that our two firms, completely independently, had both concluded that the correct architecture for a significant range of important financial services use-cases is the UTXO model.

This bears repeating: two firms who, in R3’s case, had worked with a huge consortium of financial institutions on a groundbreaking year-long Architecture Working Group and, in the case of Digital Asset, had begun delivery of implementations for clients, had reached extremely similar conclusions about what the “correct” architecture should look like.

But, in reading the paper, it was also clear that we had made some different decisions, too.  And the interesting thing is that the differences are almost all related to choices we’d made about acceptable tradeoffs.  As I’ve often written, there are no perfect solutions in DLT; just tradeoffs. But I will also freely admit that we made some additions to Corda’s technical vision in the light of the paper!

So it’s time, I thought, to share my thoughts on what I think are the key points in the paper and outline how I think Corda could be a perfect way to implement the concept.

What is the Global Synchronisation Log?

At the heart of this space is a beguilingly simple vision:

DLT allows me to build systems where “I know that what I see is what you see”

That is: if a computer system that I own and run and which exists to serve my needs tells me something about a deal you and I have done, I want to know that the system you’re looking at, that you own and run and which exists to serve your needs, is telling you the same thing.

Before Bitcoin and blockchains and Distributed Ledger Technology there were only two ways of doing this, neither of them perfect:  1) we could build a centralised infrastructure and just agree to agree that whatever they say is the truth… consensus by authority, if you like or 2) we could build our own systems and then spend all our lives checking that they had come to the same conclusion about everything… consensus by reconciliation.

Bitcoin and the systems it inspired showed us there was a third way:  we could use advances in cryptography, consensus algorithms and other technologies to give ourselves near total assurance that our systems were in sync without having to employ armies of people to check.

But there was a problem… and this problem is at the absolute heart of everything that’s going on in the DLT space today: the solution invented by Bitcoin and refined through subsequent systems depends on all data being shared with all parties.  So you gain something amazing on one hand: an end to errors, duplication, inconsistency and associated risk. But, on the other hand, you create a privacy nightmare and a system that goes slower the more things you use it for.

This is precisely the conundrum that motivated the invention and development of Corda. We decomposed the building blocks of existing blockchain platforms and reassembled them in the light of the different threat-model we have, the different use-cases and different tradeoffs we are prepared to accept.

One of the key insights in our work was that, for our scenarios, we can separate transaction verification from the question of whether two verified transactions conflict with each other. I wrote about this when we first announced Corda in April last year.

We think the question of transaction verification should be down to the transaction participants: if one of them pretends that their smart contract produced a different answer to what it actually did then we’ll deal with it out-of-band; it’s a permissioned system and we know who they are…   They gain nothing by playing games like that.

But the question of which transactions actually get confirmed is a question for an independent observer; we need somebody we all trust to choose between two equally valid but conflicting transactions. At R3, we call this observer a notary but that’s just the name we use to generalise the role performed by miners in a traditional blockchain.

In so doing, we addressed many of the privacy and scalability issues of other platforms at a stroke.

But it’s a tradeoff, of course.  Because there’s something that a full public blockchain gives you that this approach doesn’t. Both approaches assure you that only valid transactions can get confirmed, but a full public blockchain also ensures that everybody gets to know when this happens.

But, of course, a traditional blockchain does this by using full broadcast, in the clear, of pretty much everything that happens. A privacy and scalability disaster.

So we had some very heated debates when we designed Corda about which tradeoffs were acceptable and which ones were not. And the GSL paper touches on all of them really succinctly.

Two of the more important debates were as follows:

  • If I send a full transaction to a notary (think ‘miner’ in a traditional blockchain), that could be a privacy leak: the notary gets to see all the data in the transaction. But if I only send the pieces of the transaction that the notary actually needs to see in order to decide transaction ordering then I could execute a “denial of state” attack by having the notary confirm an invalid transaction that “consumes” an input and stops a valid transaction from subsequently being confirmed.
  • If I send a transaction to a notary, how does it know which other parties to inform? I could execute an attack whereby I get a transaction confirmed but the other side doesn’t learn about it… that might allow me to selectively choose not to reveal it if it so suits me.

In Corda, we made the following observations. We said:

  • The “notary privacy versus denial-of-state” question is one that should be solved on a case-by-case basis. So we support “validating notaries” that need to see all data and “non-validating notaries” that just see the subset that allows them to make a confirmation decision. But we require the non-validating notaries record who sent them the transactions they sign so we know who’s to blame if anybody does try to do something nefarious.
  • But the notification issue is more tricky: recall, the full-broadcast solution used in “traditional” blockchains just won’t cut it. Indeed, that’s why, in Corda, there is no global broadcast, by design.  So if a notary is going to inform you that something happened, it needs to know who you are and how to reach you. But that’s also a privacy issue if you implement it simplistically. So users effectively need the right to decide who they trust more: the notary or their counterparties.

So now to Digital Asset’s paper.   What they propose is very reasonable.  In essence, they say the following:

  • The Digital Asset GSL model is comfortable with the risk of a “denial of state” attack. (As are we at R3 for many scenarios, by the way, because the mitigations are robust; but Corda’s default mode is to protect against this threat).
  • So this means it’s fine if the notary only gets to see the subset of a transaction that is needed in order to determine ordering/uniqueness.
  • But GSL users are entirely not OK if a transaction can be confirmed and yet all the affected parties don’t get to hear about it at the same time as the transaction submitter.

And the paper goes on to explain how they think that last problem should be solved.

In essence, they do the following:

  • They effectively add the identities of all the parties who should know about the transaction to the outside of the transaction. This is the part that the notary sees.
    • They don’t actually put the interested parties’ identities on directly – that would be a privacy leak – but that’s the effect; you can think of them as “tagging” the transaction with the list of everybody who needs to know about it.
  • But that’s not enough, of course. The notary doesn’t get to see most of the transaction contents, remember… so the list could be wrong and the notary wouldn’t know! So they go a step further.
  • They add an additional rule to the transaction verification logic: if the transaction doesn’t “tag” the right set of intended recipients then it isn’t considered valid.
  • So now you have something pretty cool: you can get a transaction that fails to tag the right people notarised just fine (the notaries are ‘non-validating’ in the DA model, remember). But the “attacker” gains nothing because the transaction itself won’t be considered valid per the rules of the system.  So whatever nefarious scheme you were plotting fails…
  • And if you do construct a valid transaction then the act of getting it confirmed is also the irreversible act of having the notary inform all affected parties. So a bad guy doesn’t get to withhold valid, confirmed transactions.
  • This approach binds the question of transaction validity to the question of notification of affected parties.  You can’t have one without the other.

So you achieve something useful: transaction contents remain visible only to those who need to see them, transaction verification is in the hands of those to whom they pertain, notaries don’t see what they shouldn’t and if a transaction gets committed all relevant parties get to hear about it.  For a good number of use-cases, that’s a decent set of tradeoffs.

So can Corda provide a solution for the GSL?

(Spoiler: YES!)

It turns out that Corda’s design already has every single one of the features needed to implement the GSL – apart from one, which we added specifically to address this requirement.

  • Corda’s notaries already log the transaction submitters when operating in non-validating mode so we already solve the “denial of state issue” just fine.
  • Corda already supports “transaction tear-offs”, the mechanism whereby only the relevant information is shared with third parties such as notaries, using Merkle trees.
  • Corda already supports the concept of “participants” – aka“tags” – a list attached to each transaction that identifies interested parties
  • Corda’s transaction verification engine already allows contracts to verify that the participant list is correctly populated.

So we already have the mechanism to bind the verification to the population of the notification list.  But the “out of the box” design does not then ensure the notification actually happens…  This was a deliberate choice based on prioritisation of requirements and (yet another!) tradeoff around privacy.

In other words, there was one missing piece, albeit a deliberate one.  But reading this paper made us convinced adding that feature made sense and so we’ve added it to our design and will be added to the codebase in a future milestone release. The thinking is captured in section 7.5 of our technical whitepaper, starting page 33.

Note that our proposed implementation is slightly different to the design sketched in the Digital Asset paper because we deliberately and famously don’t have a blockchain: so there is no data structure that participants can passively browse to look for transactions of interest. Instead, we use a push point-to-point messaging network.  So the notary will directly inform affected parties.

Open Innovation: 2017 is the Year Corda Goes Mainstream

One of the many benefits of working on an open source project is that it becomes so easy and natural to explore these sorts of concepts with other firms, through initiatives such as the Hyperledger Project; through discussion of each other’s papers, like here; and through coding and direct collaboration between developers: we’re very much enjoying working with one of Digital Asset’s developers in our public Slack group, for example.

We think Corda is shaping up to be a perfect architecture for implementing the Global Synchronization Log concept and I am grateful to the team at Digital Asset for sharing their thinking – and their list of requirements – so openly and clearly.

Here’s to open innovation!

Standard

Posted by

Posted on

November 25, 2016

Posted under

Corda, distributed ledger, distributed ledgers, open source, Uncategorized

Comments

39 Comments

Countdown to Corda Open Source

R3 will soon be open-sourcing Corda. Here’s what to expect.

As I confirmed a few months back, R3’s Corda platform will be open-sourced, under the Apache 2 licence, on November 30.

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.

We’ve built Corda because we see requirements – especially in finance – that need a distributed ledger but which cannot be met by existing platforms.

  • Corda is the only Distributed Ledger platform designed by the world’s largest financial institutions to manage legal agreements on an automatable and enforceable basis.
  • Corda only shares data with those with a need to view or validate it; there is no global broadcasting of data across the network.
  • Corda is the only Distributed Ledger platform to support multiple consensus providers employing different consensus algorithms on the same network, enabling compliance with local regulations.
  • Corda is designed to provide a great developer experience and to make integration and interoperability easy: query the ledger with SQL, join to external databases, perform bulk imports, and code contracts in a range of modern, standard languages.

We designed it with the members of R3, the world’s largest financial services DLT consortium, but we think its applicability is far broader.  You can find out more in our introductory whitepaper and my blog post on why we’re building Corda and what makes it different. If you prefer videos, here’s a short interview I did with Simon Taylor of 11:FS that explains the thought process behind Corda.

What we’ll release on November 30 is pretty much the full codebase as it exists today and we will be improving it actively and openly from then on. In fact, the only code we’ve held back pertains to laboratory projects we’re working on with our members and work on our own commercial business products that will run on top of Corda.

So do take a look around when the code is released: there’s a lot in there that is still work-in-progress and not yet integrated. For example, you’ll find a fascinating approach to writing financial contracts in the experimental branch and ongoing work on our deterministic sandbox for the JVM.   We will, of course, also be developing a commercial version of Corda for those who need specific enterprise features and support, but the open source codebase is the foundation of everything we do.

This is a really important point: distributed ledger technologies will have such phenomenally powerful network effects that it is unthinkable that serious institutions would deploy base-layer ledger software that is anything other than fully and wholeheartedly open. And it’s why we’ve been committed all along to releasing Corda just as soon as we were sure it was heading in the right direction.  It is and so we are.

We will also be publishing a draft of our technical whitepaper.  This whitepaper outlines our roadmap to version 1.0 of Corda and production-readiness.

What to expect on November 30

We’re really proud of Corda and its progress to date. But, that said, Corda is far from finished. Mike Hearn will soon be publishing a “warts and all” description of quite how much work we still have to do. This is true for all other platforms in this space, of course, but I feel a particular responsibility to be transparent given the ambitions we have for Corda and the uses to which it will be put.

By way of example, perhaps a good way to help you figure out what we still have to do is to look at some items on the list of work we’ve set for the months ahead of us:

  • Functional completeness: Corda still has gaps in its functional capabilities. The technical whitepaper outlines the full vision and you’ll see us working on and merging a lot of functional enhancements in the coming months to implement the full vision in the paper.
  • Non-functional characteristics: We focused first on design and then on implementation of Corda’s core functionality. The work to ensure we meet our non-functional requirements, such as performance, is still ahead of us but we have a clear roadmap and have designed the platform with these needs firmly in mind.
  • Security hardening: There are lots of areas where we need to tighten up security. Much of this we know about and we have called it out in the code or associated docs. But there will, of course, be others. So just as you shouldn’t be using other enterprise DLT platforms in production just yet, please don’t download Corda and put it straight into production just yet either!
  • API Stability: Corda’s development is iterative and organic – and it is heavily influenced by the range of projects and applications to which our members are choosing to put it. As we learn about common patterns and discover assumptions that prove to be wrong, we adapt. In particular, this means that we do not commit to API stability or backwards-compatibility until version 1.0.  Expect parts of the implementation to change in the coming months, perhaps quite significantly!

But these things are transient: we know how to fix them and we’ll knock the issues off one-by-one in the coming months as we head towards version 1.0.  But we want you to be fully aware of them.

Why are we open-sourcing Corda now?

We had a vigorous internal debate about when was the right time to release Corda: wait until it was more mature, when we were confident we’d ironed out the bugs and made it fly?  Or wait only until the design roadmap was clear and then share it immediately with the world for comment, criticism, contribution and collaboration?

We’ve wholeheartedly chosen the latter path: to release early and to work openly.

We’re serious about inviting the community to critique, collaborate and contribute. To take one example, our friends at Digital Asset recently published an excellent paper describing a set of requirements for what they call a “Global Synchronisation Log” (GSL), encouraging those in the community to incorporate these requirements into their platforms. We think that Corda’s vision is extremely well aligned to the GSL concept and by open-sourcing our work whilst there is still time to tweak our design it means we maximise the opportunities for firms such as ours to collaborate.

But open-sourcing Corda when it is still fairly young is not without its risks!  In fact, I’m a little apprehensive. I’m a completer-finisher and I obsess over every detail. So the idea of releasing something before it’s perfect makes me feel uncomfortable.  You will find gaps, issues, problems. But that’s fine: please do share what you find.  Even better, submit a fix…!

In fact, I also have a hope that some of those who come to critique will find that they nonetheless like much of what they see, and may even join the community.

What happens next?

I performed a thought experiment a while back… I asked: what will the enterprise distributed ledger world look like when everything settles down in a few years? How many independent enterprise DLT platforms will the world need and which ones will they be?

My conclusion was that there will probably be at most three such platforms, each carefully designed and adapted for a specific set of requirements. They will all be fully open source. And they will be surrounded by thriving, inclusive communities.

And we firmly intend to ensure Corda is one of them.

Our open-source release next week is a key step on that journey.

How to get Corda on November 30

Corda’s home will be corda.net.

Head over to corda.net on November 30 for links to the codebase, simple sample applications and a tutorial to get started writing your own CorDapps.

 

 

Standard

Posted by

Posted on

November 8, 2016

Posted under

blockchain, distributed ledgers, ledgers, Uncategorized

Comments

29 Comments

On Distributed Databases and Distributed Ledgers

Why can’t companies wanting to share business logic and data just install a distributed database? What is the essential difference between a distributed database and a distributed ledger?

Last month, I shared the thinking that led to the design of Corda, which we at R3 will be open sourcing on November 30; and Mike Hearn and I were interviewed by Brian and Meher of Epicenter last week. We’ve been delighted by the response and are looking forward to working with those seek to build on Corda, help influence its direction or contribute to its development and maturation;  there’s a lot of work ahead of us!

But one or two observers have asked a really good question. They asked me: “Aren’t you just reimplementing a distributed database?!”

The question is legitimate: if you strip away the key assumptions underpinning systems like Bitcoin and Ethereum, are you actually left with anything? What is actually different between a distributed ledger platform such as Corda and a traditional distributed database?

The answer lies in the definition I gave in my last blogpost and it is utterly crucial since it defines an entire new category of data management system:

“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”

“Parties who don’t fully trust each other” is at the heart of this. To see why, let’s compare distributed databases and Corda.

Comparing Corda to a distributed database

In a distributed database, we often have multiple nodes that cooperate to maintain a consistent view for their users.   The nodes may cooperate to maintain partitions of the overall dataset or they may cooperate to maintain consistent replicas but the principle is the same:  a group of computers, invariably under the control of a single organisation, cooperate to maintain their state.  These nodes trust each other.   The trust boundary is between the distributed database system as a whole and its users.    Each node in the system trusts the data that it receives from its peers and nodes are trusted to look after the data they have received from their peers.  You can think of the threat model as all the nodes shouting in unison: “it’s us against the world!”

This diagram is a stylised representation of a distributed database:

 distributed-database

In a distributed database, nodes cooperate to maintain a consistent view that they present to the outside world; they cooperate to maintain rigorous access control and they validate information they receive from the outside world.

So it’s no surprise that distributed databases are invariably operated by a single entity: the nodes of the system assume the other nodes are “just as diligent” as them: they freely share information with each other and take information from each other on trust. A distributed database operated by mutually distrusting entities is almost a contradiction in terms.

And, of course, if you have a business problem where you are happy to rely on a central operator to maintain your records – as you sometimes can in finance it should be said – then a distributed database will do just fine: let the central operator run it for you.  But if you need to maintain your own records, in synchrony with your peers, this architecture simply won’t do.

And there are huge numbers of situations where we need to maintain accurate, shared records with our counterparts. Indeed, a vast amount of the cost and inefficiency in today’s financial markets stems from the fact that it has been so difficult to achieve this. Until now.

Corda helps parties collaborate to maintain shared data without fully trusting each other

Corda is designed to allow parties to collaborate with their peers to maintain shared records, without having to trust each other fully. So Corda faces a very different world to a distributed database.

A Corda node can not assume the data it receives from a peer is valid: the peer is probably operated by a completely different entity and even if they know who that entity is, it’s still extremely prudent to verify the information.   Moreover, if a Corda node sends data to another node, it must assume that node might print it all in an advert on the front page of the New York Times.

The trust boundaries – the red curves in the diagram- are drawn in a completely different place!

decentralised-database

In Corda, nodes are operated by different organisations and do NOT trust each other; but the outcome is still a consistent view of data.

To repeat, because this distinction is utterly fundamental:  nodes of a distributed database trust each other and collaborate with each other to present a consistent, secure face to the rest of the world.   By contrast, Corda nodes can not trust each other and so must independently verify data they receive from each other and only share data they are happy to be broadly shared.

And so we call Corda a distributed ledger, to distinguish it from distributed databases. A distributed ledger that is designed painstakingly for the needs of commercial entities.

Put more simply: you simply can’t build the applications we envisage for Corda with traditional database technology.  And that’s what makes this new field so exciting.

Standard

Posted by

Posted on

October 25, 2016

Posted under

Corda, r3, Uncategorized

Comments

33 Comments

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!

Standard

Posted by

Posted on

August 24, 2016

Posted under

blockchain, Corda, r3, Uncategorized, whitepaper

Comments

20 Comments

Corda: An Introduction

Announcing the Corda Introductory Whitepaper

The Wall Street Journal had a couple of good pieces this morning that describe some of the work we’re doing at R3 and our vision for the future of financial services.

Project Concord is our codename for the overall vision, with Corda as our underlying distributed ledger software.

I first wrote about Corda back in April and we demonstrated it in public for the first time a few weeks later.  Since then, we’ve been continuing to develop the code base in collaboration with our members, trialling it through an ongoing series of proofs-of-concept, prototypes and more advanced deployments, refining the design and maturing our thinking.

As part of this process, we wanted to share more information with the broader community about what we’re doing.  I’m pleased to announce the release of our first whitepaper on Corda: an introductory, non-technical overview that explains our vision, some design choices and outlines the key concepts underpinning the platform.  We’ll follow this up in the coming months with a more detailed technical whitepaper.

whitepaperThe whitepaper, which you can download here, explains how we set ourselves the challenge of starting with the financial industry’s pain points: duplicated, inconsistent data and business logic and redundant business processes – and asked ourselves if we could apply breakthroughs in distributed ledger and blockchain technology to solve them.

Our conclusion is that distributed ledger and blockchain technology represents a once-in-a-generation opportunity to transform the economics of data management across the financial industry. But there’s a problem because the blockchain and distributed ledger platforms that led us to this exciting moment were never designed to solve the problems of financial institutions and do not meet all our needs: we need tight linkage to the legal domain; we have an obligation to prevent client data being shared inappropriately and so can’t send all transactions to all network participants; we must integrate and interoperate with existing financial infrastructure; and more.

Corda is the outcome of the analysis we did on how to achieve as many of the benefits of distributed ledger and blockchain technology as possible but in a way that is sympathetic to and addresses the needs of regulated financial institutions. Corda is intended to be a contribution to the plurality of technologies that will be adopted in the coming years, one that is targeted specifically and with a laser-focus on the needs of financial institutions.

I hope you find the whitepaper interesting and illuminating and we would love to hear your feedback.

 

 

Standard

Posted by

Posted on

April 5, 2016

Posted under

blockchain, Corda, distributed ledger, r3

Comments

101 Comments

Introducing R3 Corda™: A Distributed Ledger Designed for Financial Services

UPDATE: The Corda introductory whitepaper is now available! And this blog post gives more context.

As reported in Bloomberg this morning, I’m delighted to confirm that R3 and our member banks are working on a distributed ledger platform for financial services: Corda™. I explain it on our official R3 blog and reproduce it here.

For the last six months, my team and contributors from our membership have been building a distributed ledger platform prototype from the ground up, specifically designed to manage financial agreements between regulated financial institutions. I am massively excited by the progress our team, led by James Carlyle, our Chief Engineer, and Mike Hearn, our Lead Platform Engineer, are making and I think the time is right to share some details.

Corda: A Distributed Ledger for Recording and Managing Financial Agreements

Corda is a distributed ledger platform designed from the ground up to record, manage and synchronise financial agreements between regulated financial institutions. It is heavily inspired by and captures the benefits of blockchain systems, without the design choices that make blockchains inappropriate for many banking scenarios.

Corda’s key features include:

  • Corda has no unnecessary global sharing of data: only those parties with a legitimate need to know can see the data within an agreement
  • Corda choreographs workflow between firms without a central controller
  • Corda achieves consensus between firms at the level of individual deals, not the level of the system
  • Corda’s design directly enables regulatory and supervisory observer nodes
  • Corda transactions are validated by parties to the transaction rather than a broader pool of unrelated validators
  • Corda supports a variety of consensus mechanisms
  • Corda records an explicit link between human-language legal prose documents and smart contract code
  • Corda is built on industry-standard tools
  • Corda has no native cryptocurrency

Corda’s design is the result of detailed analysis and prototyping with our members and will be open sourced when the code has matured further.

In the remainder of this post, I want to share some insight into our thinking.  Why are we building Corda?  Why have we made some of the design decisions we have?  When will the code be ready for others to examine and build upon? How does this relate to other platforms and projects?

A thought experiment

When I joined R3 from IBM in September 2015, I forced myself to stop and think.  The blockchain bandwagon was running at full speed, I’d just been appointed CTO of a project intended to bring blockchains to finance but there was a nagging worry at the back of my mind…  how could I avoid falling into the trap of believing all the hype?!

I imagined myself sitting in front of the CIO of one of our member banks some time in the future.  I imagined we had naively selected a “blockchain for finance” based on what was popular at the time and widely deployed a range of products and services on top of it. And I imagined we had believed the hype, had suspended our critical faculties and had omitted any engineering.  In this imagined scenario, I now found myself facing an angry CIO, who wanted to know why the system I had built had just failed calamitously. Why on earth did I build it the way I did?!

I concluded that an entirely inappropriate answer to that question would be: “because blockchains were cool in 2015”!  No. That simply won’t do.

The reality is that solutions based on selecting the design first and then trying to apply it to arbitrary problems never work out well.  Every successful project I’ve worked on started with the requirements, not some cool piece of technology, and I was determined to bring that discipline into our work at R3.

Remind me again why a system designed to replace banks is also supposedly their saviour?

And there is a second reason for this caution: the technology and finance industries collectively “decided” some time in early 2015 that “blockchain technology” was somehow the future of financial services.

Indeed, I am one of the most active proponents of precisely that claim. But the reason for blockchain technology’s importance is extremely subtle – and this subtlety is something that most people seem to have missed.

To understand this, we need to look at Bitcoin.

Bitcoin’s architecture, as I have often written, is a marvel.  Its interlocking components are one of those rare examples of something so elegant that they seem obvious in hindsight, yet which required a rare genius to create.

But what is often missed is that the cleverest part of Bitcoin isn’t actually its architecture; I think the cleverest part was to articulate the business problem.  We don’t tend to think of Bitcoin as being the solution to a “business problem” but it can perhaps be thought of as a wonderfully neat solution to the problem of: “how do I create a system where nobody can stop me spending my own money?”   Now, I can’t claim to know the mind of Satoshi and he certainly didn’t write the whitepaper in this way but it triggers a very useful thought-experiment.

In fact, once you write this ‘business problem’ down, the design drops out almost trivially!  (Almost…) You want always to be able to spend your own money? Then you can’t have a central point of control.  It could be shut down by the authorities.  You can’t even have a collection of validators with known identities as they could also be shut down with concerted effort.  Very quickly you realise you need a massively replicated consensus system and, if you don’t want to tie actions to real-world identities, you need something like Proof of Work to make the voting work.  You work the logic through and pretty much the whole design (the blockchain, the need for mining, block rewards, maybe even the UTXO transaction model, etc., etc.) drops out.  Of course, it does push a lot of work onto the users: confiscation of somebody’s bitcoins is easy if you know their private key… but let’s leave that to one side for now.

And this way of looking at it is important because it highlights how Bitcoin’s blockchain can be thought of as the solution to a business problem.    Satoshi Nakamoto didn’t wake up one morning wanting to “apply Blockchain to finance”.  Blockchain was the tool that was invented to solve a real problem.

So we have a conundrum, right?  If that’s the case, then what on earth is the argument that says blockchain has any relevance at all to banking?!

Indeed, last time I checked, banks have the inverse of my Bitcoin problem statement!

What is the defining characteristic of blockchain systems?

So I spent most of October sitting in a dark room (really! This was our first London office… a tiny four-person room in a shared working space in the City of London) questioning some of the most fundamental assumptions about blockchains.  What is it exactly that makes them interesting to banks?

Most people had already made the mental leap that the “bitcoin package” was unacceptable as a take-it-or-leave-it deal: proof of work is unnecessary for private deployments, for example.  But, as I looked around, all I could see was firms who had accepted everything else…  It seemed strange to me that, as an industry, we could tease apart one part of the “blockchain bundle” but then stop there.

I spent several of my earlier, formative years at IBM in a role called “technical sales”.  If you’ve ever bought technology from a large IT vendor, you’ll have met somebody like me.  We’re the people who visit clients with the sales rep and act as the technical expert: we explain how the product works, make sure we’re proposing the right solution to the client and ensure there is no technical barrier to closing the deal.

A lesson I learned very early in that role was: it doesn’t matter how hard you wish or how many client meetings you schedule or how aggressive the sales rep gets, if you can’t show how your solution is going to solve the client’s business problem then the deal almost certainly won’t close.  And those that do are the ones you’ll live to regret…

Fast forward a decade, and as I surveyed the blockchain landscape in October 2015, all I could see was excitable (and vocal!) firms touting solutions that made very little sense to me for the kinds of problems I was trying to solve.  I will confess to many moments of self-doubt:  maybe they were all sane and I was the mad one..?!

But I ploughed on: even if they are right that a “take it or leave it” blockchain design is the saviour of the financial industry, I’ll be doing our members a favour if I could explain why.

So we started picking away at what can perhaps be called the “blockchain bundle”:  the collection of services that blockchains provide to those who use them.

We concluded that a blockchain such as the ones underlying Bitcoin or Ethereum or any of the private variations actually provide at least five interlocking, but distinct, services.  And the right approach is to treat them as a menu from which to select and customise… different combinations, in different flavours, for different business problems.

CONSENSUS

The first, and most important, feature of blockchains – and the thing that is probably genuinely new in terms of scale and scope – is that they create a world where parties to a shared fact know that the fact they see is the same as the fact that other stakeholders see:

“I see what you see… and I know that what I see is what you see”

And, critically:

“I know that you know that I know”! 

And:

“I know that you know that I know that you know…”

And so on…

And it makes this promise across the Internet between mutually untrusting parties.  Sure: consensus systems and replicated state machines have existed for years but consensus systems at Internet scale, between untrusting actors, that work in the face of powerful adversaries? That’s a step forward.

In Bitcoin, the shared facts are things like: “What are all the bitcoin (outputs) that have not yet been spent and what needs to happen for them to be validly spent?”.  And the facts are shared between all full node users.

In Ethereum, the shared fact is the state of an abstract virtual computer.

But notice something interesting: there isn’t some law of nature that says the set of people who have to be in consensus is the whole world.  Bitcoin just happens to work that way because of its unique business problem.   If you don’t have Bitcoin’s business problem then be very wary of those trying to sell you something that looks like a Bitcoin solution.

VALIDITY

The second feature in the “blockchain bundle” is validity. Tightly linked to consensus, this feature is the one that allows us to know whether a given proposed update to the system is valid. It is how we define the rules of the game.  What does a valid “fact” look like in the system?  What does a valid update to that fact look like?

UNIQUENESS

The third feature in the blockchain bundle is its “uniqueness service”.   I can quite easily create two perfectly valid updates to a shared fact but if they conflict with each other then we need everybody who cares about that fact to know which, if either, of those updates we should select as the one we all agree on.  The “anti-double-spend” feature of blockchains gives us precisely this service and it’s hugely important.

IMMUTABILITY

The fourth feature in the “Blockchain Bundle” is often, if misleadingly, termed “immutability”: data, once committed, cannot be changed.

This isn’t quite true: if I have a piece of data then of course I can change it.  What we actually mean is that: once committed, nobody else will accept a transaction from me if it tries to build on a modified version of some data that has already been accepted by other stakeholders.

Blockchains achieve this by having transactions commit to the outputs of previous transactions and have blocks commit to the content of previous blocks.  Each new step can only be valid if it really does build upon an unchangeable body of previous activity.

AUTHENTICATION

The final critical feature in the “Blockchain Bundle” is authentication: every action in the system is almost always associated with a private key; there is no concept of a “master key” or “administrator password” that gives God-like powers.   This is quite different to traditional enterprise systems where these super-user accounts are prevalent and petrifying from a security perspective.

So what is the financial services business problem?

So why did I take us through this analysis?  Because it gets us to the heart of the distributed ledger domain: the thing that is genuinely new is the emergence of platforms, shared across the Internet between mutually distrusting actors, that allow them to reach consensus about the existence and evolution of facts shared between them.

So if that’s what this is all about, then what are the “shared facts” that matter in finance? What business problem would we need to have for any of this work to be of any use at all?

And this is the light bulb moment and the fundamental insight driving the entire Corda project:

The important “shared facts” between financial institutions are financial agreements:

  • Bank A and Bank B agree that Bank A owes 1M USD to Bank B, repayable via RTGS on demand.
  • This is a cash demand deposit
  • Bank A and Bank B agree that they are parties to a Credit Default Swap with the following characteristics
  • This is a derivative contract
  • Bank A and Bank B agree that Bank A is obliged to deliver 1000 units of BigCo Common Stock to Bank B in three days’ time in exchange for a cash payment of 150k USD
  • This is a delivery-versus-payment agreement
  •  … and so on…

The financial industry is pretty much defined by the agreements that exist between its firms and these firms share a common problem:  the agreement is typically recorded by both parties, in different systems and very large amounts of cost are caused by the need to fix things when these different systems end up believing different things. Multiple research firms have postulated that tens of billions of dollars are spent each year on this problem.

In particular, these systems typically communicate by exchanging messages: I send an update to you and just hope you reach the same conclusion about the new state of the agreement that I did.  It’s why we have to spend so much money on reconciliation to check that we did indeed reach the same conclusions and more money again to deal with all the problems we uncover.

Now imagine we had a system for recording and managing financial agreements that was shared across firms, that recorded the agreement consistently and identically, that was visible to the appropriate regulators and which was built on industry-standard tools, with a focus on interoperability and incremental deployment and which didn’t leak confidential information to third parties.  A system where one firm could look at its set of agreements with a counterpart and know for sure that:

“What I see is what you see and we both know that we see the same thing and we both know that this is what has been reported to the regulator”

That’s Corda.

How does Corda choose from the “Blockchain Bundle” Menu?

So now we understand the financial services requirement, we can look again at the “Blockchain Bundle” menu from above and outline the choices we’ve made.

CONSENSUS

A critical piece of the Corda philosophy is that our problem is to ensure that “I know that you see the same details about a shared fact that I see”.

But this does not mean that a third party down the road also needs to see it: our consensus occurs between parties to deals, not between all participants.

VALIDITY

Furthermore, in Corda, the only people who need to be in agreement about a fact are the stakeholders to that fact:  if you and I agree about something that pertains only to us then why should we care what some completely unrelated third party thinks?  And why would we even think of sending them a copy so they could opine on it? So, in Corda, we let users write their validation logic in time-tested industry-standard tools and we define who needs to be in agreement on a transaction’s validity on a contract-by-contract basis.

UNIQUENESS

Just like every other distributed ledger out there, we need to be sure that two valid, but conflicting, transactions cannot both be simultaneously active in the system.  But we also recognise that different scenarios require different tradeoffs. So Corda’s design allows for a range of “uniqueness service” implementations, one of which is a “traditional blockchain”. But it doesn’t need to be and, for our purposes, we also need implementations that make different tradeoffs under Brewer’s CAP theorem: in particular, some financial services use-cases need to prioritise consistency at the expense of availability in the event of a network partition.

IMMUTABILITY AND AUTHENTICATION

Here, Corda’s design departs very little from existing systems: our data structures are immutable and our building block is the exchange of digitally-signed transactions.

So Corda is very traditional in some respects – we directly apply the “authentication”, “immutability” and “uniqueness service” features of blockchains but we depart radically when it comes to the scope of “consensus” (parties to individual deals rather than all participants) and “validation” (the legitimate stakeholders to a deal rather than the whole universe or some arbitrary set of ‘validators’).

How is Corda Different?

Hang on?  Isn’t this the same pitch that every other blockchain firm is making? Not quite.

Notice some of the key things:  firstly, we are not building a blockchain.   Unlike other designs in this space, our starting point is individual agreements between firms (“state objects”, governed by “contract code” and associated “legal prose”).  We reject the notion that all data should be copied to all participants, even if it is encrypted.

Secondly, our focus is on agreements: the need to link to legal prose is considered from the start. We know there will still always be some disputes and we should specify right up front how they will be resolved.

Thirdly, we take into the account the reality of managing financial agreements; we need more than just a consensus system. We need to make it easy to write business logic and integrate with existing code; we need to focus on interoperability. And we need to support the choreography between firms as they build up their agreements.

Different Solutions for Different Problems

But… we should be clear.  We are not viewing Corda as a solution to all problems.  This model is extremely powerful for some use-cases but likely to be less well suited to others.  It’s why we continue to engage extremely deeply with all our partners who are working on complementary platforms in this space; we are not omniscient.  Moreover, there are still many significant design and research questions we have to resolve: there is still a great deal of work to do.

Furthermore, I have been deeply impressed by the quality engineering embodied in the many platforms that have passed through our labs and you will continue to hear about projects we are delivering on platforms other than Corda: different solutions for different problems is our mantra.  Indeed, those who have attended panels or workshops in recent months will have heard me saying this for some time now.

Corda does not seek to compete with or overlap with what other firms are doing:  indeed, we are building it because no other platform out there seeks to solve the problems we’re addressing.  That’s what makes this space so endlessly exciting.

What next?

In the coming weeks and months, you’ll hear more about Corda, about our initial projects and about its design.  We will also be gearing up to release the core platform as open source, possibly as a contribution to other endeavours.  Watch this space.

And… we’re still hiring: there is a great deal of work still to do!