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.

Bitcoin and Blockchain: two revolutions for the price of one?

I gave a brief talk on Bitcoin and blockchain technology to an audience of non-specialists at a dinner last week.  It covers many of the themes I’ve explored on this blog before. But the short, fifteen-minute, format forced me to be brief and clear.  This is an edited version of the speech

A £20 note has an obvious, yet extraordinary super-power.   I can hand it to anybody in this room and £20 of value will be transferred instantly, directly, peer-to-peer, person-to-person. Settlement, with finality, in central bank money!  And nobody else need know.  And nobody can stop me.

Super20

Super £20!!   [I really hope there’s no law against posting photos of money…]

But this super-power only works at close distance.  If I want to transfer £20 of value to somebody in a different town or in a different country, I need to trust other people.  Sure: I could put the £20 in an envelope and post it.  But even then I’d have to trust the postal service.

Or I could use a bank.  But I’d be trusting them to be good for the money. And I’d have handed over control: if my name’s on the wrong list, the bank would be obligated to seize my funds. And if you’re on the wrong list, the bank will refuse to transfer the money to you…

“Digital” money is not the same as physical cash.

And the world’s financial plumbing – payments systems, correspondent banking, SWIFT, … – is a direct consequence of this observation: physical cash really is fundamentally different to every other form of money: only physical cash is a bearer instrument. And only physical cash can be transferred without permission – censorship-resistant.

Or so we thought.

Because a curious email to an obscure cryptography mailing list at the end of 2008 said something quite audacious. The email, from the hitherto unknown Satoshi Nakamoto heralded the arrival of Bitcoin and the advent of “purely peer-to-peer electronic cash”.

Super202

“A purely peer-to-peer version of electronic cash”

We all know the story of what happened next.

Except… what many people have missed is that the choice of the word “cash” in that email was absolutely critical and absolutely deliberate. What this email announced was the arrival of a digital bearer asset that is censorship resistant.  Digital cash.  A digital asset that you can hold outright, with no risk of confiscation, and which you can transfer to anybody you choose with no permission from anybody else.

And the funny thing is: the architecture of Bitcoin flows almost trivially (almost…!) from this requirement.  Proof-of-work, the peer-to-peer gossip network, mining, the mining reward, the blockchain.  The lot.  It’s as if the genius of bitcoin was to ask the question.

But why am I saying this in the summer of 2015? This exact same thing could have been said at any point from 2009 until now.  There’s nothing new here.

Except…

Nobody asks the obvious question:

Who actually wants a censorship resistant digital bearer asset?!

 Well… some people do, of course.  But none of them are banks or corporates.  At least, I’ve not yet met a bank that wants this.

So why are so many banks, corporates, VCs and startups spending so much money in this space?!

I think there are two completely distinct reasons and that that the world of “blockchain technology” is actually two completely different worlds, with different opportunities and different likely winners.  And those who don’t realise this might be about to lose a great deal of money.

First, let’s look at Bitcoin.

We should probably be realistic here.  Bitcoin is not the solution to Greece’s crisis and it won’t bring finance to the world’s poor.  But it turns out that censorship resistance is extremely valuable, even for people who don’t think they need it.

Because censorship resistance implies openness.

Anybody or anything can connect to an open network like Bitcoin to own and transfer value.  And anything that is open, standardised, owned by nobody and useful smells very much like a platform.  And we’ve seen how those stories play out.

But notice something else:  Bitcoin is worse than existing solutions for all the use-cases that banks care about.  It’s expensive. It’s slow. And it’s “regulatorily difficult”.  And this is by design.

So this makes it doubly interesting.

Because it means Bitcoin is probably worse than existing solutions for all the things most people and firms care about but vastly better for one single use-case (open access to value transfer) that could be very useful for some people.

Isn’t that pretty much the definition of a disruptive innovation?   Something that’s worse for existing use-cases but solves a niche use-case very well?

So, if this is true, we should expect to see adoption of Bitcoin come from the margins, solving marginal problems for marginal users.

But disruptive innovations have a habit of learning fast and growing.  They don’t stop at the margins and they work their way in and up.

So this is why I think so many of the big-name VCs are so excited about it.

So the incumbents should be keeping a very close eye on what’s going on.    If anything in this space is going to disrupt them, it will probably come from this world.  But it’s perfectly understandable that vanishingly few of them are actually engaging deeply in this world.

So if Bitcoin isn’t why banks are looking at this space, what are they looking at?  

How have so many people convinced themselves that there is something of interest here that is “separate” to Bitcoin or systems like it?

At this point, it’s customary to observe sagely that “of course, the real genius of bitcoin was the blockchain; that’s where the value is”.

But I’ve discovered something rather amusing.  If you push the people who say this, and ask them what they actually mean, most of them can’t!  And yet…   whether they understand why or not, they are actually on to something.

It comes down to how bitcoin delivers on the design goal of “censorship resistant” cash.

Imagine Bitcoin didn’t already exist and you were asked to design a system of censorship-resistant digital cash.  How would you do i?

Well… you couldn’t build it around a central database: the government could shut it down.  That doesn’t sound very censorship resistant.

And you couldn’t rely on a network of trusted people around the globe since law enforcement could simply collaborate to shut them down too.  And in any case, who would control the identity system that helped you be sure these people were who you thought they were in any case?

It turns out that the answer is quite unexpected… and it’s something I’d bet almost all engineers would consider completely mad.

The answer is that you get everybody who fully participates in the system to maintain a full copy of the ledger.   And every time somebody, anywhere in the world, spends some bitcoin, we’re going to inform everybody who’s maintaining this ledger and they’re going to store a copy of that transaction too.

Bitcoin essentially runs on a MASSIVELY replicated, shared ledger.  (The trick is in keeping it consistent, of course…)

It sounds insanely inefficient and expensive… and perhaps it is. But we also have to ask ourselves:  inefficient and expensive as compared to what?

And this leads us to the other world

Just look at the state of banking IT today…  Payments, Securities, Derivatives… Pick any one.  They all follow the same pattern:  every bank has built or bought at least one, usually several, systems to track positions and manage the lifecycle of trades:  core banking systems, securities settlement systems, multiple derivatives systems and so on.

Each of these systems cost money to build and each of them costs even more to maintain.

And each bank uses these systems to build and maintain its view of the world.  And they have to be connected to each other and kept in sync, usually through reconciliation.

Take even the simplest OTC derivative contract:  it is recorded by both sides of the deal and those two systems have to agree on everything for years.  Very costly to operate.

But what if…  what if these firms – that don’t quite trust each other –used a shared system to record and manage their positions? Now we’d only need one system for an entire industry… not one per firm. It would be more expensive and complicated to run than any given bank-specific systems but the industry-level cost and complexity would be at least an order of magnitude less. One might argue that this is why industry utilities have been so successful.

But a centralised utility also brings issues:  who owns it? Who controls it  How do the users ensure it stays responsive to their needs and remains cost-effective?

The tantalising prospect of the blockchain revolution is that perhaps it offers a third way: a system with the benefits of a centralised, shared infrastructure but without the centralised point of control:  if the data and business logic is shared and replicated, no one firm can assert control, or so the argument goes.

Now, there are lots of unsolved problems: privacy, performance, scalability, does the technology actually work, might we be walking away from a redundant (antifragile?) existing model? Who will build these platforms if they can’t easily charge a fee because of their mutualised nature?  Difficult questions.

But see:  this has nothing to do with funny internet money, bitcoin or censorship-resistant digital cash.  It’s a completely different world

Two revolutions for the price of one

So… the blockchain revolution is so fascinating because it could actually be TWO completely different revolutions…   both profound in their implications:

  • Censorship-resistant digital cash providing a new platform for open, permissionless innovation driven from the margins
  • And industry-level systems of record driving efficiencies for incumbents.

Neither of these are “sure things”… they are both high risk speculative bets… but they’re also very DIFFERENT bets…

[EDIT 2015-07-23 Gideon Greenspan has written a great piece that comes at this argument from a very different angle]

As ever, the thoughts and comment on this blog are mine alone and don’t represent the view of my employer….

A Simple Model for Smart Contracts

Everybody I ask has a different definition of a “smart contract”; Here’s mine.

I hear more and more people talking about “smart contracts” these days. But when you push them to define the term, the concept often dissolves in their hands.

This isn’t a new observation: Peter Todd made a similar point after sitting through a session at a workshop we both attended last year.

Indeed, I was almost certainly one of the many who failed to impress him that day 🙂

Now, of course, one answer is to simply point at the intellectual visionaries who foresaw this space decades ago. Nick Szabo’s Smart Contract piece from 1997 is a really succinct and helpful overview. And I really like Ian Grigg’s idea of the “Ricardian Contract”.  Szabo’s “vending machine” model is particularly helpful.

But these ideas predate the world of Bitcoin, blockchains and cryptocurrencies and so it’s not immediately obvious for new people in this space how to bridge the gap. Worse, there are multiple platforms out that purport to implement smart contracts. Indeed, you can argue that Bitcoin itself is actually a smart-ish contract platform. So it becomes even harder to distinguish between the concept and a specific implementation.

In this piece, I try to build a motivation for why something like a smart contract might be a nice idea and use that to produce my definition and model.

The Replicated, Shared Ledger

When I think about block chains and distributed ledgers, I start with what I think is the key innovation of Bitcoin: it taught the world how to transfer value at-a-distance with no trusted third party.   (Yes: I know some people take issue with this and it may not be 100% accurate – but I think it creates the right intuition)

Sure – we could hand physical money to each other face-to-face but, until Bitcoin, there was no way to send value to somebody on the other side of the world without having to trust centralized third parties: the postal service, banks and so forth.

It’s as if the traditional money-movement infrastructure of banks and payment systems had been reimagined as a flat peer-to-peer network of actors. Perhaps moving from the picture on the left to the picture on the right:

SmartContracts1

Bitcoin opened the possibility of peer-to-peer electronic value transfer, in contrast to today’s system of banks, central banks and payment systems.  [I use these Banks merely as examples; I’m not trying to imply they’re doing anything in this space!]

But what this (very naïve!) picture misses is precisely how systems like Bitcoin achieve their claims.

The answer is that Bitcoin-like systems are built on things that I’ve started calling “replicated, shared ledgers”. That is: every full participant in the network has a full copy of the transaction ledger and the “magic” of the system is in how it makes sure that everybody’s copy stays in step with everybody else’s.

So, perhaps the correct picture is this one on the right below, where each participant is shown as having access to the same shared, replicated ledger:

SmartContracts2

The trick of Bitcoin and other decentralised consensus systems is in how they ensure everybody has a copy of the ledger that they know is in step with everybody else’s

Great – leaving aside questions of scalability and so forth, we can see that this architecture can work: if everybody has the same copy of the ledger as everybody else then you no longer need central entities to keep track of who owns what (or who owes what to whom). Instead, you know that when your ledger gets updated to record a change of ownership of an asset then everybody else’s does too.

We need to distinguish between what the ledger records and how it does it

A great deal of the debate and competition in this space is focused on how this ledger is structured and secured. Bitcoin’s mining algorithm? Ethereum’s system? Ripple’s consensus algorithm? What these debates often miss is that these are all “how” questions: how is the ledger secured? How does the consensus process work? How are bad guys kept at bay?   And they’re all different because the platforms make different assumptions about the nature of the threat they are likely to face.

But, for this article, it’s useful to forget that side of things for now and, instead, ask yourself: what does this ledger record? What is it used for?

What does this ledger record?

In one of my recent posts, I explored how this concept of a “shared, replicated ledger” could have application well beyond currency. My point was that once you know for sure that your view of the world is the same as everybody else, it opens up new possibilities in entirely unrelated areas, perhaps even accounting. Ian Grigg has written about this and firms such as triplentry are exploring it today.

One of the driving thoughts here is: if I know that everybody “sees” the same things as me then perhaps I don’t need to spend so much money building my own custom ledgers and perhaps I don’t need to spend so much money auditing and reconciling with everybody else… the ledger does it for me.

OK – so perhaps a shared, replicated ledger could take cost and duplication out of today’s commercial systems.

So where else do we have duplication?

One area is in business logic. There are countless examples in business where two (or more) parties to a contract each independently write computer systems that model the terms of that contract. I sometimes get accused of only talking about banking examples so here are some non-banking examples of what I mean:

  • Large online retailers probably have a system that checks the bill they receive from their delivery companies is correct: have all the negotiated discounts been applied?
  • Large grocers negotiate complicated rebates from their suppliers, based on volumes in a period and plenty of other factors. You can be pretty sure that both sides of those contracts have developed very sophisticated models of the contract in computer code
  • A surprisingly large number of consumer insurance policies in the UK are sold through brokers. These brokers typically use software platforms provided by third party firms. These third-party platforms usually have their own implementations of each insurer’s pricing model: it is not unusual for a single insurance product to be represented in three or more completely independent code bases!

What unites these scenarios and countless others like them is that each party needs an independent means to calculate the value owing (or owed) under the contracts. They can’t realistically trust the other side. So logic dictates that they each have to build their own system. This might be wasteful and drives a need for reconciliations and so forth.

But think back to what I said above: a replicated, shared ledger has the property that everybody knows that everybody else is seeing the same thing without one side having to trust the other side to be scrupulously honest.

So imagine, now, that your ledger could also run computer code.   Here’s what you could do:

  • When you negotiate an agreement with somebody, you also agree on a representation of that agreement in computer code
  • You agree what information sources it will use for external data and how disputes will be resolved
  • You both examine the code in detail to confirm there are no secret backdoors or sneaky loopholes. And you perform testing to check it yields the right answers for the various inputs your provide to it.
  • Satisfied that it does what you want it to, you both sign it and deploy it to the ledger.

And now you have something really interesting: neither of you have to go to the effort of reimplementing the terms of the contract in your own systems: you both know that this single piece of code satisfies both your purposes.   And because it is running on this shared, replicated ledger and using it as its source of information, you can both be sure that whatever the program outputs will be the same for both of you.

Indeed, supervisory authorities, in time, may come to insist that this is how some business is done.

But we can go even further

So far, I’ve outlined a fairly mundane scenario: a computer program that represents the agreement between two or more parties.

But remember: we’re imagining a world where this program runs on the shared, replicated ledger…. the shared, replicated asset ledger.

What if this program could interact with that ledger?   The program could take control of assets on the ledger and you could even send assets to the program. So it’s no longer just a computer program, it’s an economic actor in its own right.

Imagine we’re in the grocery scenario: you could imagine the grocer paying its suppliers by sending payment to this computer program. The program could calculate how much rebate is likely to be due, send the difference to the supplier as payment for the goods but temporarily hold on to the rebate – since we’ll only know for sure at the end of the month what the true discount percentage should have been. At this point, the contract could send the right amount of remaining funds to each party.

It’s as if this program isn’t just a computer program: it’s an actor in its own right. It responds to the receipt of information, it can receive and store value – and it can send out information and send out value.

It would be just like having a human who could be trusted to look after assets temporarily and who always did what they were told.

And this idea is what I think people mean when they talk about Smart Contracts.

The diagram below is my model for this: a piece of code (the smart contract), deployed to the shared, replicated ledger, which can maintain its own state, control its own assets and which responds to the arrival of external information or the receipt of assets:

SmartContracts4

My mental model for a smart contract: a computer program that runs on a shared, replicated ledger, which can process information, and receive, store and send value.

So much for the theory

So that’s the essence of it, I think. Perhaps more formally, my definition might be that:

A smart-contract is an event-driven program, with state, which runs on a replicated, shared ledger and which can take custody over assets on that ledger.

But that’s just my working definition.  And there are lots of conceptual issues. I summarise some of them here, merely as signposts for further study (and future posts)

  • Injecting Real-World State
    • Smart contracts rely utterly on the quality of the information which is sent to them. “Oracles” and “n-of-m” schemes can help. But where I think additional thought is required is in what happens when things change: what happens if information sources go away, if previously independent sources merge, if new and better sources emerge?
  • Modelling
    • There may prove to be examples of business problems that can be modelled in multiple ways – e.g. directly as assets on a ledger or as contracts. Perhaps good practices need to emerge for the “right” way to model different types of real-world phenomena
  • Dealing with bugs, errors
    • Have you ever written a computer program without bugs? So how would one fix a smart contract once deployed if the bug is clearly in the favour of one of the parties?
    • Could this also be the early days of a new profession? Just as lawyers can earn big money finding loopholes in contracts, will there be a cadre of “engineer-lawyers” looking for loopholes in smart-contracts?
  • Liquidity
    • If assets are under the custody of a smart contract, they are, by definition, not available to anybody else. This could change the economics of various businesses.
  • Legal validity
    • Does a smart contract have the same legal force as a “real” contract? What happens if the output of the contract is incompatible with law or a court finds it to conflict with the English-language version of the agreement? Does it depend, in part, in how the ledger is secured?
  • Privacy
    • Most shared, replicated ledgers are public. I don’t know many retailers who want their deals with their suppliers to be public knowledge
  • Technical
    • Does the underlying technology work satisfactorily? Does it scale? And so on
  • … and much more

But I’m pretty sure smart people in the community are looking at all of these things. So perhaps the real test is: what are the compelling business scenarios that will drive adoption/experimentation in this space?

If you’ve reached this far, well done. I’d urge you to study the writings of Szabo, Grigg and countless others on this… they’ve covered this space so much better than me…

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?

Ledgers

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]