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.
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.
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.
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.
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).
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”
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.
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?
- 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?
- 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 Transactions
- 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!
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|
A very clear and transparent way to communicate technology to the world at large.
Much of the approaches explained here conjure up thoughts of a few similar workings in the Semantic Web of linked data.
There are also elements that are similar or that relate to mechanisms in Business Process Management systems and Enterprise systems.
But all in all, there is no doubt that Corda is a clear piece of technology that can be as effective in its domain as open source Blockchain technologies will be effective in theirs.
Much respect to you sir. I Wish you success and fulfillment in all your hard work.
I hope you won’t mind The Rat pointing out that the key criteria for any succesful implementation of a new proposal is clearly its system network security.
By moving away from the highly secure and already existing and proveable bitcoin blockchain, Corda is putting its faith in a proposal, as yet untried in ‘real life’, that realies on a trusted centralised verification security model. If anything has shown us as “true” in recent times it is that hacking is always one step ahead of a central administrations ability to completely protect itself . Whilst I understand that there may be limited applications within financial institutions and banking where Corda may have some superficial appeal, systems can (and are) being built on top of the bitcoin blockchain that give client confidentiality AND security.
The Rat does however wish you well, and is looking foward to the coming commercial adoption of Corda and seeing just how this security challenge will unveil itself for the brave initial participants . 🙂
After reading this, everyone should understand the magnitude of change that’s in front of us. Very soon, we’ll have some very powerful tools at hand. Then the business innovation begins.
“allowing multiple Consensus Services on the same network, including consensus service clusters running different consensus algorithms”
Corda Consensus Services? or Notary Clusters? Multiple? It is a pity that the article is vague about this crucial aspect of the Corda blockchain. What are these services exactly? And who/what provides them? How does it work and how could it be overruled by a power or adversary?
We are especially interested in ways where no intermediate has any influence on the consensus.
Thanks @Timo… completely agree!
@rotimiorims – thanks.
@BitcoinRat – thanks for the comment. I agree completely that much of the current debate will be resolved in due course through the evidence of deployments and adoption. And I do hope this piece didn’t come across as promoting an “either/or”… as those who’ve followed my blog for some time will know I’m a massive fan of bitcoin – its architecture is a work of genius and I’ve been heavily influenced by it. It just happens that I see a whole pile of problems and opportunities that need solving and for which I think Corda’s design is singularly well-suited. But there are also a pile to which it’s not. We built it because we saw an unmet need and a gap… ie there’s a reason it looks different to all the other platforms out there (including bitcoin): those platforms _already exist_ and do a fine job of solving the problems they were designed to solve! But there are also _other_ problems, for which they are not the best solution. There’s space for a lot of approaches 🙂
@henk. take a look at the corda whitepapers (intro and technical). linked from corda.net. Given your requirement, it would seem that you would be most interested in our forthcoming byzantine-fault-tolerant notary clusters. Still a work-in-progress but you can track progress on the relevant branches in our repo (github.com/corda/corda)
Thanks for your reply Richard. Fully appreciate that the bitcoin blockchain isn’t applicable to many usages currently being undertaken within traditional Banking (but ‘the times they are a-changing’ as The Rat has been expounding for some time ?)
Also appreciate your positive comments on bitcoin ! It’s not going away… 🙂
Thanks for this article. As a blockchain layman, this most certainly provided me with a very good understanding of the goals of Corda.
The simplistic example leads me to believe that there are very wide-ranging use-cases where this can be applied. Marbles rolling around in my head as I write.
I have also taken your advice and am reading the intro as well as the technical whitepaper.
However, I have some questions I was hoping you can clarify for me (hope they are not too elementary):
1. Does Corda run on a private network implementation? I assumed so, but wasn’t entirely sure.
2. From an implementation perspective, I’m not quite sure how this is achieved, so this question is perhaps picking on your brain a bit — in a example, for a solution involving central banks, there will be a bunch of nodes running in each and every central bank. if so, what would prevent a particular central bank from launching multiple nodes, thereby gaining a potential majority foothold? is it possible that a particular central bank has more weight in the consensus process?
3. I wonder if it would be of benefit to other enterprises to have a c# fork of this solution. the thinking I have around this is that a large number of organizations I deal with run only on Microsoft stack and software. thoughts?
I have lots of questions but will refrain from asking them until after I’ve read the documents. I will be keeping a close watch on Corda as it looks very interesting.
Hi Lawrence – sorry for such a slow response. Quick answer:
1) Yes – intended to be run between identifiable parties. The network can be over the internet but connections are encrypted and all parties are expected to present certificates to each other to prove membership
2) The number of nodes doesn’t factor into the consensus process. Consensus as to whether a transaction has been confirmed/committed or not is the responsibility of notary clusters… and participants in the system have to agree which notary clusters they trust…. and which specific nodes in the clusters… so if you set it up so that the world’s central banks were running a notary cluster jointly, each of them would participate using their identity certificate… and because there’s only one Bank of X, they could only present one identity, no matter how many nodes they ran
3) Great question. We’re in the process of stablilising the wire format, at which point non-Java implementations will be possible.
You should join our slack! slack.corda.net A tonne of good debate on there that I think you could contribute massively to.
thanks for your reply Richard,
#1 does answer the question of whether it runs on some known chain network — it does not.
#2 tells me that the current implementation looks a possible 1 bank 1 cert scenario. is this design currently the way it is among central banks? my simple head tells me that banks with more leverage can exert more influence, but perhaps this is what corda aims to remove?
I will join in the slack channel to further educate myself on this — thanks for the tip.
Aw, this was a very nice post. In thought I want to put in writing like this additionally – taking time and precise effort to make a very good article… however what can I say… I procrastinate alot and by no means seem to get something done.
Hi , I have a questions
If Albert refuses to pay for 10 $ to Richard , How dose Corda process this case?
@xiaomo in the scenario above, it doesn’t. The example here is about how to record the existence of the agreement (the bet) and manage it through its lifecycle. This is deliberate. You could extend the example and have each side pay their side of the bet up-front, effectively into an escrow arrangement… and have Corda release the winner’s payment and transfer the loser’s to them. But a surprisingly large number of real-life scenarios don’t work that way: it’s a feature, not a bug, that the loser could fail to pay. (I know that sounds mad when written, but the alternative is pre-funding every deal, which is impractical in many real-life scenarios. So Corda supports both models)
I have a question about the Ledger ?
Where dose it seat in this analogy? (is it the list of transaction?)
if yes how does Corda manage that you each user see only the transaction to him?
Nice article, thanks for the posting.