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.


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?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!


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




Cost? Trust? Something else? What’s the killer-app for Block Chain Technology?

Could decentralized ledgers change the face of accounting?

When I speak to people about decentralised ledgers, some of them are interested in the “distributed trust” aspects of the technology. But, more often, they bring up the question of cost.

This confused me at first. Think back to where this all started: with Bitcoin. Bitcoin is deliberately less efficient than a centralized ledger! Its design adds really difficult engineering constraints to what we already had. How could this technology possibly be cheaper than what we already have?

And yet the claims keep coming. So perhaps this “cost” claim deserves closer consideration. Perhaps there are some scenarios where the “cost” camp might be right?


So much comment in this space talks about “distributed ledgers” or “decentralized ledgers”. But there is very little reflection on what we actually mean by “ledger”.

Investopedia has a good definition of a General Ledger:

A company’s main accounting records. A general ledger is a complete record of financial transactions over the life of a company. The ledger holds account information that is needed to prepare financial statements, and includes accounts for assets, liabilities, owners’ equity, revenues and expenses.

There are some key points here: “complete record of financial transactions”… “information that is needed to prepare financial statements”. I find this a useful definition because it captures two insights that will become important.

  • first, we use ledgers to record facts… things that the company has done, transactions it has entered in to.
  • second, the ledger is not an end-product; rather, it’s something from which we prepare other documents – our balance sheet, for example.

A worked example

So let’s work through an example of a balance sheet to test the “cost” argument.

In what follows, I’ll work through a really simple and not-representative example that constructs a balance sheet for a small firm – and asks if there are any opportunities to apply decentralized consensus technology to the problem.  (And, as will become painfully clear, I’m not an accountant…)

The world’s smallest and most naïve investment bank…

Imagine you had a fetish for being regulated and decided to start your own TINY investment bank. You persuaded your friends and family to invest £1m and opened the company.   You haven’t started trading yet so your accounts are really simple: you have put the £1m you raised in the bank (let’s say Barclays) and, since your friends and family own the firm, you also have £1m of equity – which represents their ownership of the firm. Let’s call it RichardCo.

Hang On – What’s a Balance Sheet?

In my mental model, a Balance Sheet is the financial statement you use as a snapshot of the firm’s financial position at a point in time:

  • What are all the things you owned at that point (your assets)?
  • And what are all the things you owe (your liabilities?).
  • If the difference is positive, great: this is your shareholders’ equity in the business. If it’s negative, it’s game over: you’re insolvent.

So the “balance sheet” for RichardCo on day one might look like this:

Balance Sheet 1

RichardCo’s simple balance sheet. There’s £1m in the bank and you record your shareholders’ funds on the liability side of the balance sheet. The “scroll” is the ledger.

By convention, we put the assets (the things you own) on the left and the liabilities (the things you owe) on the right. And we’ve captured a couple of likely entries from various ledgers that explain where the entries on the balance sheet came from.

Notice how we put the shareholders’ funds (the equity) on the “liabilities” side of the balance sheet. This is because the shareholders’ funds can be thought of as a “residual claim” on the company. If you shut it down (or were shut down), you’d have to sell the assets, use the proceeds to pay off everybody you owed money to and, whatever was left, would be the shareholders’. You’d be liable to pay it to them. So we think of the equity as a liability.

Now, like I say, we haven’t done any business yet. But, already, there’s some complexity here

Think about that £1m in cash. It appears on your balance sheet as an asset and you’ll have a record somewhere recording its receipt from your shareholders and another recording the fact that you paid it into the bank. (Actually, you’ll be using double-entry book-keeping and so you will have four entries in the ledger but let’s leave that to one side for now)

Now think about it from the bank’s perspective. They will also have a record. After all, they took it in as a deposit.  So it will also appear on their balance sheet – but this time as a liability. They owe it to you.

So there are multiple ledgers in two different organisations all recording the same pieces of information and two balance sheets that reflect the position:

  • Your balance sheet, recording the claim against Barclays: an asset
  • Barclays’ balance sheet, recording their obligation to you: a liability

Balance Sheet 2

Your £1m asset in the bank also appears on the bank’s balance sheet, as a liability.

Great – this is as it should be and it makes it possible for us to keep an eye on things. When it’s time to get your accounts audited, the auditor doesn’t just have to trust your ledgers. They can phone up the bank and get them to verify that their recording of the position matches yours. The fact you know this can happen acts as a disincentive to cheat in the first place.

If only banks really were this simple…

But, in reality, it’s far more complex than this.

In reality, banks aren’t funded primarily by equity… they also have a HUGE amount of debt…

So let’s imagine you have gone to some pension funds and borrowed £2m – you want to be prudent for now.

Youou decide to build out your broker-dealer arm first so you use the money you borrowed to buy some shares for inventory: £2m of IBM stock. That gets you about 20,000 shares, which you deposit at a custodian bank for safekeeping.

Let’s also imagine that you enter into some interest rate swaps with some other banks. Perhaps LCH.Clearnet, acts as central counterparty for all these trades.  And, brilliant news! Your derivatives positions have moved in your favour and it looks like you’re up £1m on them!

Great. So your balance sheet now looks like this.

Balance Sheet 3

Your balance sheet after borrowing £2m, entering into some derivatives contracts that move in your favour (£1m mark-to-market – MTM) and buying some IBM shares. Notice how Shareholders’ Funds (equity) has increased by £1m as your assets (the money owed to you by LCH) have increased in value, whilst your debt has stayed the same.

Now think about all the book-keeping at all the other firms

For every position on your ledgers that goes into creating this balance sheet, at least one other entity will also have a ledger that records the same position (from their perspective).

So you might end up with a picture like this:

Balance Sheet 5

Your (still very simple!) balance sheet will be reflected on ledgers and balance sheets all across the financial system.

And this picture isn’t the full story. Remember we said the clearing house stepped in and became your counterparty? So the other participants will, in turn, have their own ledgers on the other side of the clearing house. And your shareholders presumably have their own records. And so on.

Making sure all these ledgers are kept in sync: reconciliation

One of the many important control functions in a bank is to check regularly that all these ledgers line up – that your counterparties agree with you on what it is that each of you own or owe to each other.

But, interestingly, you only really need to agree your positions – not the valuations. You could, quite legitimately, come to different conclusions about the value of some positions. For example, let’s imagine that the pension fund thinks there’s a chance you’ll default on your loan. They will still have a record that you borrowed £2m but they may only value the position on their balance sheet as a £1.9m asset.

This is an interesting subtlety: the fact, as shown on the ledger, is that you owe £2m but the pension fund’s balance sheet may reflect their opinion that they’ll likely only recover £1.9m

Similarly, the fact of your derivatives positions is recorded on your (and LCH’s) ledgers. And you’ve probably agreed to pay (or receive) whatever cashflows their systems calculate. But how you value your overall position on the balance sheet could depend on a whole other set of factors.

So perhaps the picture actually looks like the one below: the “facts” that we need to reconcile between firms are those contained on the underlying ledgers, not the subjective valuations on the balance sheets:

Balance Sheet 6

In principle, we need to reconcile our ledgers to keep everybody accurate and honest. But it’s perfectly OK for the subjective valuations of some of the positions (as reflected on the balance sheets) to be different – such as with the pension fund here.

So, to simplify hugely, we could say that our problem is one of keeping all these disparate ledgers in sync:

Balance Sheet 7

The same picture as before but with the other firms’ balance sheets removed for clarity. Our problem is to make sure these ledgers always agree with each other when they record information about the same transactions.

So we see in the picture above that the facts that underpin my view of the world need occasionally to be checked against at least four other ledgers in other organisations and, in reality, many more.

Enter Decentralised Ledgers

So now let’s turn attention back to the world of decentralized consensus.

I said earlier that it’s hard to argue a decentralised ledger system like Bitcoin that replicates ledger data thousands of times can be more efficient.   But perhaps it (or something like it) can.

Imagine we’re living five or ten years in the future. Perhaps we have a securities block chain that records ownership of all securities in the world. Perhaps we have a derivatives smart contract platform that records (and enforces?) all derivatives contracts? Maybe, even, there will be a single, universal platform of this sort.

If so, perhaps all participants would have a full copy of this ledger.   And so now maybe we can redraw the picture.

Balance Sheet 8

A possible future: all firms record their external obligations and claims on a single shared, massively replicated ledger. Would this reduce (remove?) the need for systems duplication and reconciliation?

Sure – everybody still has a copy of the data locally… but the consensus system ensures that we know the local copy is the same as the copy everywhere else because it is the shared consensus system that is maintaining the ledger. And so we know we’re producing our financial statements using the same facts as all the other participants in the industry.

Does this mean we no longer need audit? No longer need reconciliations? Obviously not, but perhaps this approach is what is driving some of the interest in this space?

But notice: this is just a way of ensuring we agree on the facts: who owns what? Who has agreed to what? We can still run our own valuation algorithms over the top and we could even forward the results to the regulator (who could also, of course, have a copy of the ledger) so they can identify situations where two parties have very different valuations for the same position, which is probably a sign of trouble.

Of course, this is a very simplified example and the real-world is considerably more complex. In particular, some really difficult problems stand in the way of making this a reality:

  • Scale – think about how many transactions would be recorded
  • Security – imagine what would happen if somebody managed to subvert the ledger. This also has implications for who controls it, runs it and is allowed to connect to it. Bitcoin’s pseudonymous consensus system is unlikely to be appropriate here?
  • Privacy – do you really want everybody being able to see all your positions?
  • … and so on.

So I’m really not saying this is how things will pan out but I think it’s a useful thought experiment: it shows a potential use for replicated ledgers that might have utility but which doesn’t depend on being “trust-free” or “censorship-resistant”.

Perhaps this is what some of the other commentators in this space have in mind?


A simple model to make sense of the proliferation of distributed ledger, smart contract and cryptocurrency projects

Just when I think I understand the cryptocurrency/block chain space, I realize I didn’t understand anything at all

Four recent events have made me realize that I don’t understand this space anywhere near as well as I thought I did.   But that’s good: it means I’ve been forced to come up with a new mental model to explain to myself how all these projects relate to each other.

TL;DR: the two questions to ask about a “fiduciary code” requirement are: who do I need to trust and what am I trusting them about?

Who do I trust

A simple model to capture the essential differences between some consensus platforms

The rest of this article describes the four events that influenced me to draw it.

Event 1: Nick Szabo’s “The Dawn of Trustworthy Computing” Article

In his recent article, Nick Szabo introduces two really helpful terms to explain what makes systems like Bitcoin particularly noteworthy.

  • First, he talks about “block chain computers”. He defines these as the combination of the Bitcoin consensus protocol and strong cryptography to create the unforgeable chain of evidence for all data stored in the block chain data structure.   I think this formulation is useful because it shines a bright light on an obvious, but often overlooked fact: a “block chain” is just a data structure, utterly useless on its own. What makes the Bitcoin blockchain remarkable is the network of computers – and protocol they follow – that makes it so hard for any single actor, no matter how determined, to subvert it.
  • Secondly, he talks about “fiduciary code”: the code in an application that needs to be the most reliable and secure. For example, in a banking application, this is likely to be the core ledger: who owns what. He points out that a secure block chain computer is an extremely expensive piece of kit: you should only use it to secure that information that really needs it.

Event 2: Albert Wenger’s “Bitcoin: Clarifying the Foundational Innovation of the Blockchain” Article.

In this piece, Albert Wenger makes a really obvious-in-hindsight point: Bitcoin-like block chains are organizationally-decentralised – no one organization can control it but the entire point of the system is to build and maintain a logically-centralised outcome: a single copy of the ledger, which everybody agrees is the true single copy.

ArthurB uses the term “decentralized mutable singleton” to capture the same idea, I think.

And he echoes one of Szabo’s implicit points: a “block chain” is not something of value in and of itself. This insight is also important because it edges us further away from the idea that “decentralization” is some sort of end-goal or absolute target. I made a similar point in this piece on the “unbundling of trust” but Albert and Arthur have captured the key point far more succinctly.

Event 3: The Eris Launch

On Wednesday this week, Eris Industries held the launch event for their new platform. Tim Swanson has done a good job summarizing the Eris concepts. (Disclosure: I was invited to, and attended, the launch).

I’ll admit I still don’t fully understand it. But the general picture that’s forming for me is of a platform that allows you to build and maintain one of these “decentralized mutable singletons” but to specify precisely who is allowed to update it and under what conditions.

In essence: take the idea of a shared common state (Albert’s Arthur’s “mutable singleton”) but relax the constraint that the maintenance of it necessarily happens in a fully public, adversarial environment, for which something like a proof-of-work system may be required, and allow for the idea that the participants might be known.  [EDIT wrong name!]

Fine… but I think the Eris insight is where they go next. They suggest that if you had such a system then you might also be able to distribute the processing of application logic more broadly, too. And I think it’s the application logic they’re most interested in. Their documentation is full of talk of “smart contracts” and it’s perhaps no surprise that their founders are lawyers. In fact, maybe that’s why I don’t understand it as well as I’d like: lawyers just seem to speak differently. Maybe I need a translator.

And to be clear, the part I don’t fully understand just yet is why you need a “block chain” as the underlying data structure in this model, rather than something based on more general-purpose replicated database technology. But this may turn out just to be an implementation detail: so let’s see how they get on over time.  There seems to be a lot of content, reflective of a lot of thought, on the various Eris sites.

Event 4: I looked at HyperLedger in more detail

I had reason to look at HyperLedger this week and, combined with my study of Eris, it was this event that finally convinced me that my mental model of this space was far too simplistic.

Hyperledger calls itself an “open-source, decentralized protocol for the recording and transferring anything of value”. This is a bit like how I might have described Colored Coins or Ripple to people in the past.

But what makes Hyperledger different is that they allow the creation of multiple ledgers (one per asset per issuer) and each ledger can be configured to have different consensus rules – you don’t have to make the assumption of an adversarial open public environment… so some similar assumptions to Eris here, but with a ledger designed to track assets rather than business logic/contracts.

Where is this heading?

So I spent some time this evening trying to piece all of this together in my brain.

I’m pretty sure these projects all sit in Szabo’s “Fiduciary Code” space: they only really have value or make sense if the facts they’re recording are really important!

But they make different assumptions about the threat model they face – and some of these assumptions are very different to the ones against which Bitcoin was designed.  And they’re different to the assumptions underpinning some other prominent platforms, such as Ripple, which, through its use of validators and “Unique Node Lists” has a model, whereby you trust a set of known entities who, in turn, trust some other entities, and so on.

In addition, the facts these systems are recording are very different: ownership of a real-world asset on Hyperledger is different to ownership of a bitcoin on the Bitcoin ledger; a ledger-native asset has no counterparty risk, whereas a real-world asset needs an identifiable issuer. And they’re both different to a platform that potentially executes legal contracts.

So I tried to think of dimensions along which you might be able to classify these projects… and I came up with too many.

But it’s almost Christmas and I’m not to be deterred!   Is it really too much to ask for a model with just two dimensions, that doesn’t require a 3-D screen to render?! So I kept on going. And, finally, came up with something that looks so trivial, I worry it may be content free.   But here it is anyway.

I think the two dimensions that help me think about these projects are:

  • “Who do I trust to maintain a truthful record?”; and
  • “What do I need the record to be about”?

Here is the model I came up with.   It’s obviously not complete and you could put some projects in multiple boxes… but I think it captures the key distinctions.

Who do I trust

Another way to think about the increasingly confusing cryptocurrency/Block Chain space

But this is just a view. I’d really value comments… especially if I’ve missed something really obvious.

[UPDATE 2015-01-08 DISCLOSURE: Since publishing this post, I have become an advisor to HyperLedger, in a personal capacity]