Posted by

Posted on

July 23, 2015

Posted under

Comments

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.

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

“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….

Posted by

gendal

Posted on

July 5, 2015

Posted under

balance sheets, Banking, blockchain, distributed ledgers, shared ledgers

Comments

20 Comments

A Simple Explanation of Balance Sheets (Don’t run away… it’s interesting, really!)

Shared ledgers could be revolutionary but do we need to share a mental model for banking to make sense of it all?

What would be your first instinct if your friend were to tell you they had £1m in the bank? To congratulate them on their good fortune? To suppress a pang of jealousy?

Wrong, wrong, a million times WRONG!

The only acceptable first instinct is to shout loudly at them: “No! You fool! You don’t ‘have’ a million in the bank. You have lent a million to the bank. They owe it to you. How could you reveal so casually that your mental model of banking is so wrong?!”

If your first instinct was the correct one then you need read no further; there is nothing for you here. But, for everybody else, you could be missing something really important. And this could matter: as I’ve written repeatedly, we could be witnessing the emergence of shared ledger systems in finance – blockchains, if you prefer. And they will be used to record obligations of – and agreements between – firms and people of all sorts. A more complex (and larger) example of this, if you like:

The four-column model of shared ledgers

To make this work, we’re going to have to get a lot more precise about how we think about financial relationships. And I’m pretty sure it all comes down to having a clear mental model for balance sheets.

What is a balance sheet?

Imagine you were starting a bank. You’d want to put a system in place to keep track of the finances: how much cash do you have in the vault? To whom do you owe money? How much have you lent out? And so on.

The basics are not rocket science and there are only two key reports at the heart of this: the balance sheet and the income statement (aka the P+L).

They exist to answer two important questions:

What do I own and how much do I owe? This is what the balance sheet tells you. Think of it as a point-in-time snapshot.
How did I do in the last period? That is what the income statement tells you. Think of it as the story for how you got from last year to this year.

In this piece, we’ll look at the balance sheet, because I think it’s the one you need to understand to make sense of where shared ledger technology could be going.

And the good news is: a balance sheet is simple… it’s just a two column table:

You write all the things you own – your assets – in one column
You write all the things you owe – your liabilities – in the other column.
If you own more than you owe, the difference belongs to your shareholders: their “equity” is what makes it “balance”.
If you owe more than you own, then you’re bankrupt (“insolvent”):

A balance sheet only has two important columns: what you own and what you owe.

Let’s open a bank!

So now let’s imagine you’re ready to start your small bank, “GendalBank”. Your friends think it looks like a good bet so they’ve agreed to contribute towards the £1m you need to get it up and running in return for shares.

£1m to start a bank?! As you can tell, my example is going to be very unrealistic indeed…

It may be obvious but I’ll say it anyway: they have no right to ask for this money back… it’s not a loan. But if you closed the company down, anything that was left after you’d paid off all your employees, suppliers and lenders, etc., would be returned to the shareholders.

So what they really have is a residual claim on the company. That’s what equity is. And when you look at it this way, it’s obvious that equity is a liability of the company: GendalBank has an obligation to return what’s left over to the shareholders if it ever closes down.

So GendalBank has been set-up and the shareholders have handed over their £1m. How would we draw up a balance sheet to reflect all this?

GendalBank’s balance sheet after the shareholders have paid for their shares. (Pedants: please forgive me… I omitted the trailing apostrophe on “Shareholders’ funds”. I don’t have time to update ten diagrams… but I can assure you the mistake pains me more than you)

It’s as exactly as we’d expect. Your new bank has £1m in cash – maybe you’re holding it in a vault or perhaps you’re holding it at the Bank of England. But, either way, this cash is now GendalBank’s… it doesn’t belong to the shareholders any more; it belongs to the company. It’s the bank’s asset now. It can use that cash for whatever it likes. So we note it down in the assets column.

And remember what the shareholders have paid for: a residual claim on the company. Well, there are no other claims on the company right now, so we record a liability to the shareholders of £1m. If we closed down right now, they’d be entitled to be paid £1m.

It bears repeating: bank capital is a liability. And this turns out to be a really useful thing to know. Because it allows you to spot charlatans at a thousand paces… any time you hear somebody talking about capital as if it were an asset of the bank (“holding more capital” is a great giveaway) then you know they don’t know what they’re talking about…

(I can’t help thinking making statements like that opens me up for all kinds of ridicule when the faults of this piece are identified…)

Great… so now we buy some IT equipment and an office with some of that cash. So perhaps the balance sheet looks like this at the end of the first week:

We use some of the cash to buy some equipment and an office, etc

To keep things really simple, I’m going to assume the bank has no expenses. I did say this was a very unrealistic example! So we’ll assume we own the office and that there are no employees to pay. This is just to avoid having to look at the income statement for now.

And now we’re open for business… time to make some loans…

Bob walks in off the street and asks to borrow £100k because he’s planning on buying a very nice car at the weekend. He looks a trustworthy sort so we make the loan.

And now another really interesting happens: we create money out of thin air…

Our loan to Bob has created money out of thin air!

Now Bob hasn’t withdrawn any money yet – he’s not buying the car until the weekend, remember. But look at how counterintuitive the balance sheet has become.

Look first at the asset side: we still have £500k cash, of course: he’s not drawn anything out yet. And we see the £100k loan to Bob. That’s our asset since Bob is obliged to pay us back £100k in the coming months and years. That’s a valuable promise to hold – it’s an asset of the bank, for sure.

Aside: just as above, I’m making some massive simplifications here, not least that I’m completely ignoring interest rates and discount rates, etc. Humour me 🙂

And now look at the liability side: it records that we owe £100k to Bob. That’s fair enough. If he looks at his account, he’ll see £100k there that he can withdraw whenever he likes. As far as he’s concerned he thinks “has £100k in the bank”.

So we have £500k of our own cash – either in the vault or at the Bank of England. And Bob thinks he has £100k “in the bank” as well.

Hang on… what’s going on? Did we just turn £500k into £600k by updating a spreadsheet?! Or does this mean that £100k of the £500k is now Bob’s? Or what?

The way to understand this of course is to observe that the £500k is our asset , whereas the £100k is Bob’s asset – and our liability. They’re not the same thing at all and it makes no sense to compare them in this way.

And so here’s another way to spot a charlatan: if you ever hear somebody talking about bank deposits as if they’re assets of the bank, you know you can safely ignore anything that person says… As this example makes clear, bank deposits are liabilities… and you have to be careful around them… because customers have the annoying habit of asking you to give them the money so they can spend it on something. And, to do that, you’d better have enough cash (on the asset side of your balance sheet, remember) to be able to honour that request.

This is what people mean in this context when they discuss “liquidity” – do you have enough cash or stuff you can quickly turn into cash to meet withdrawal requests from your customers?

Aside: in many ways, this conundrum is the absolute heart of banking: how to manage the problem of issuing short-dated liabilities (e.g. demand deposits) whilst holding longer-dated assets (e.g. one-year car loans). There’s even a name for it: maturity transformation. It obviously relies on not all “depositors” wanting “their” money back at the same time and so is inherently unstable.

But it turns out we do have enough cash on hand. So we get to live another day.

And this could go much further…. We could make lots of loans. As long as not everybody wants to take out money at once, maybe we’ll be OK. Let’s imagine lots of other customers plan to make some big purchases in the future and borrow some money from us. This is what the balance sheet would look like immediately after we’d made those loans but before any of them had withdrawn any of the cash:

We make lots of loans and make the balance sheet bigger and bigger…

What happens if the people who borrowed the money from us want to draw out the cash? They presumably borrowed the money for a reason, after all…

Well, that’s probably OK too, at least in “good times”. Let’s say they ask to withdraw £5m between them. There’s the minor problem that we don’t actually have £5m in cash… we only have £500k. But that’s OK… provided we’re not bust – that we’re solvent – and people believe we’re solvent, perhaps we can borrow the cash temporarily from somebody else – maybe the central bank.

So that’s what we could do:

We borrow £5m cash from somewhere else and use it to pay the depositors who want cash. Notice “deposits” have reduced by £5m and loans from other banks have increased by the same amount. The asset-side of the balance sheet is unchanged in this example.

Of course, another thing we could have done was sell some of the loans to somebody else for cash. And that would have also reduced the size of the balance sheet… since we’d only have £5m loans remaining on the asset side.

But it’s counterintuitive, isn’t it? We set up a bank that is making lots of loans and we’ve not yet taken a single deposit!

Indeed, it’s even weirder… we’ve created deposits seemingly out of thin air by the very act of making these loans. Where else did Bob’s “deposit” come from except from the fact that we made a loan to him? And it turns out this is a really important point. The Bank of England, no less, argues that this mechanism is the primary way money is created in the modern economy. Everything you were taught at school about how banks need to take in deposits in order to make loans isn’t actually true… But let’s leave that debate for another day…

“Deposits”

I once wrote a piece explaining how payment systems work. I was blown away by the response: hundreds of thousands of hits, huge numbers of them from people at banks. Clearly: this stuff isn’t as obvious as perhaps it should be.

One of the key points I made in that post was the one I was hinting at above: it makes no sense to say you’ve “paid money into the bank” or that you have “money at the bank”. There’s no jar in the back office containing your money, with your name on the front. Instead, when you “deposit” money with a bank, what you are actually doing is lending it to the bank. It ceases to be yours and that cash becomes an asset of the bank. It becomes theirs, to do with as they wish. In exchange, they make a promise to you: to give you cash in the future if you ask for it. You acquire a claim on the bank.

So let’s see how that works. What happens if and when somebody finally does make a deposit?

Let’s imagine Alice has just sold her house for £500k and needs somewhere to park the cash for a few days:

We have an extra £500k on hand as a result of a £500k deposit from Alice.

So this works as we’d expect: we record the fact that we owe £500k to Alice – our liability – and that we have an extra £500k in the vault (or with the Bank of England) – our asset.

OK, OK, Enough! What does this have to do with distributed ledgers?!

Well done for getting this far. Why have I written so many words and laboured so many points? Because, and as I argued recently, we could be moving to a world where agreements and obligations between firms are recorded on a shared ledger at the level of an industry or market, rather than on private systems maintained separately by each of the players.

And, if this is true, we’re going to need to represent the idea that Alice has a £500k deposit at GendalBank or that Freddie has borrowed £500k from “OtherBank”. And this is only going to work if everybody building this systems has a deep, intuitive sense that “deposits” should be modelled as “claims against an identifiable entity” and that £500k at GendalBank is fundamentally different to £500k at OtherBank and so on. I think we need to be thinking in terms of a “four-column model” of “issuer”, “holder”, “assetID” and “quantity”:

Will the “four-column” model be the core data structure of the shared ledger world? (This is not an original idea to me: the concept is at the heart of systems like Ripple, Stellar and Hyperledger, amongst others)

Perhaps more importantly, once you start thinking about things in this way, it becomes possible to see the outlines of how the future state could work.

One can imagine a world where the bank still records that it owes some money to its customers but the shared ledger is the place that records precisely who those people are. This is fundamentally different to using the shared ledger as a mirror (or mirroring it to the bank’s own ledger) – it’s more akin to seeing the shared ledger as a partial subledger.

And it might perhaps be something that gets adopted to different degrees by different firms.

Perhaps GendalBank just uses the shared ledger to record some balances. So we update GendalBank’s system to say that it owes £5m to somebody but that it’s the distributed ledger that records to whom. And we see on the distributed ledger (above) that these people are Charlie and Debbie. So the total (£5m) is recorded in both places but only the shared ledger keeps track of the fine-grained detail. So it becomes a logical sub-ledger for some deposits (“DistLedger below) whilst the bank’s own ledger is used to record other facts.

Perhaps GendalBank only uses a shared ledger to record details of some accounts (“DistLedger”) and continues to maintain others locally.

OtherBank, by contrast, might go further and move pretty much everything to the distributed ledger – both records of its liabilities and assets. So OtherBank’s internal ledger is extraordinarily simple: it just records the value of assets and liabilities managed externally on the shared ledger:

OtherBank has “outsourced” or moved all processing to the shared ledger

So what?

Let’s look at the shared ledger again:

Imagine you’re Charlie. If you have the ability to read/write to this shared ledger, you could pay away your claim against GendalBank to any other user of that ledger without having to go through any of GendalBank’s systems. We’d have decoupled the deposit-taking and lending functions from the record-keeping, accounting, payment and trading systems.

If you were OtherBank, you could sell your loan to Freddie to somebody else and the business logic might move with the loan (the “smart contract idea): previously illiquid assets might become tradeable under this model. As I keep saying, this space is about more than just payments, after all.

Now, obviously: there is a lot of detail here that I’ve not even touched on. The reality is going to be so much more complex than this.

But hopefully this sketch shows some possibilities for where this could be going. And, like I said earlier, none of this will happen unless we get everybody to the same page with the right mental model for how banking works…

Appendix: Aside on Regulation… what stops us going completely mad with this?

I can’t write a piece on bank balance sheets without talking about risk. And a legitimate question is: if my analysis above about how loans are made and deposits are created is correct, what’s to stop us going completely mad and taking in huge amounts of deposits or making huge numbers of loans? Don’t irresponsible banks tend to get into trouble and need to be bailed out? Well, yes they do. And there are (at least) two very different things that can go wrong.

Illiquidity

The first problem banks can face is one of liquidity. Imagine lots of customers want their money back at once and the bank doesn’t actually have enough cash on hand. What happens?

As discussed above, the bank might be able temporarily to borrow the cash from somebody else. But what if nobody wants to lend it to the bank? They’d be suffering from illiquidity: the value of their assets exceeds their liabilities, so they’re not bust… but they can’t meet their obligations to repay people. Oops!

In most countries, the central bank will step in in such scenarios and temporarily lend the money to the banks. Indeed, we might say that the ECB’s “Emergency Liquidity Assistance” programme for Greek Banks was an example of this: on the assumption (pretence?) that the Greek banks weren’t bust, the ECB lent increasing amounts of Euros to the Greek banks to support deposit outflows.

From a regulatory perspective, rules such as the Basel Accord’s “Liquidity Coverage Ratio” is an attempt to force banks to hold enough cash (or cash-like instruments) on their balance sheet for forseeable withdrawals.

Insolvency

Another problem banks can run into is insolvency – being bust. It’s easy to see how this could happen:

Imagine that some of the people to whom you’ve lent money lose their jobs or their companies go bust and you suddenly realize there is no way they will ever be able to repay their debts to you.

Let’s say £2m of the loans you’ve written become unrecoverable. So you “write down” the loan book from £10m to £8m… since you now know you’ll only ever recover £8m.

Now your assets are worth £9.6m. But your liabilities haven’t changed. You still owe £10.6m to your customers and the banks you’ve borrowed money from.

You owe more than you own. Game over. Good bye. You’re insolvent.

Your losses on loans mean your assets are now smaller than your liabilities. You’re bust

But notice something really interesting…. If you’d only lost £500k on your loans, you’d have been OK because your assets (£11.1m) would have still been greater than your liabilities (£10.6m):

… but if you only lost £500k on the loans you’d have been OK

So you can lose some money on your assets and be OK. But if you lose too much, you’re in trouble. What determines how much you can afford to lose? The answer is capital – shareholders’ funds.

You got away with the £500k loss but not the £2m loss because of your capital. Your shareholders took the hit. Before the bad debts came along, their residual claim on the company was worth £1m. A £500k loss takes their claim down to £500k. But in the £2m bad case above, the loss was greater than the “loss-abosrbing” cushion of £1m provided by the capital and that’s why you went bust.

And so this is why regulators are so fixated on capital: the more the bank is funded by capital rather than deposits or debt, the more resilient the bank is when they make losses on their assets. Capital can be written down to absorb losses on assets in a way that debt can’t. It’s why you hear so much talk about “capital ratios” and the like: what percentage of your assets should be financed by capital rather than debt?

But notice: the bank is in no sense “holding” capital. You hold assets and capital is not an asset… Instead, think in terms of capital being a mechanism through which the bank is funded.

And these phenomena can interact: if you are illiquid, you might need to sell lots of assets a “firesale” prices, turning a liquidity problem into a solvency problem.

[Update 2015-07-05 My description of insolvency is *very* simplified, as Ken Tindell has noted here… https://twitter.com/kentindell/status/617719608875872256]

Posted by

gendal

Posted on

June 10, 2015

Posted under

blockstream, sidechain

Comments

9 Comments

Quick notes on Sidechains “Elements”

I’ve written a lot recently about the potential of replicated, shared ledgers that are private/semi-private. For example, I suggested that industries with duplicated systems across firms might get benefit from adopting this technology. But I also keep an eye on what’s happening in the Bitcoin world. So the Blockstream “Elements” launch caught my attention this week.

I wrote about the idea behind sidechains late last year and so it’s interesting to see parts of the vision turn into real code. Back then, I said that a way to think about this is as a system that lets you “move” bitcoins from the Bitcoin blockchain onto another bitcoin-like system and back again in a way that doesn’t harm the Bitcoin network and doesn’t require you to trust a central entity like a Bitcoin exchange.

Why would you want to do that?

First, it could be a good way to prototype proposed changes to the core Bitcoin protocol with lower risk: the change could first be implemented and tested on a sidechain, a relatively safe environment. And, should the new system work well, those who needed the feature could transfer their coins to that sidechain, knowing they could bring them back again in the future.
Secondly, and looking further ahead, this approach could also provide a migration path for existing bitcoin holders to a new version of the network – offering an alternative to a hard-fork.

It’s an attractive idea and one can intuitively sense why it could be valuable. Of course, the idea is not perfect. Developers such as Peter Todd, have argued that sidechains would be vulnerable to attack under various circumstances. But, leaving that to one side for now, what was announced this week and what does it mean?

Sidechains Announcement

What follows is deliberately brief in order to share thoughts quickly:

A sidechain is now up and running and accessible from the Bitcoin testnet.
The sidechain can be thought of as “just like Bitcoin” (or just like Bitcoin testnet) but with several additional features, or “elements”.
These elements include features such as “confidential transactions” and “relative locktime” (full details here and I explore two in a little more detail below)
A mechanism for moving coins to and from the sidechain is up and running… but this mechanism currently relies on a network of semi-trusted oracles, or “functionaries”, to validate the return of coins to testnet. This is because the necessary changes to enable this in a decentralized fashion do not yet exist in Bitcoin and one should remember there is no guarantee such a change would ever happen
The sidechain is also currently secured by this network of functionaries”. I understand this is a temporary situation but one could argue it means the distinction between permissioned and permissionless ledgers could be becoming somewhat blurred. Preston Byrne of Eris Industries has said something similar.
The code is open source so other people could set up their own sidechains and run their own functionaries.
In what I think could be a smart move for gaining mindshare, blockstream have signed up several universities with Bitcoin projects/programmes, such as MIT and Princeton to run these “functionaries”.

Elements

The individual features being explored initially have been called “Elements”

Of particular interest to my readers might be Confidential Transactions and Issued Assets.

Issued Assets is an attempt to add support for Colored Coins-style assets to the core protocol. This is the one feature that is not yet deployed to the sidechain but it is also one of the most intriguing. I’ll be watching for comment from those projects in the coming days.

Confidential Transactions are a very clever application of cryptography to hide the value of transactions whilst still allowing them to be fully validated by the network. If this works well, it could be a partial solution to the confidentiality issue faced by Replicated, Shared Ledgers.

The fundamental characteristic of these systems – both permissioned and permissionless – is that multiple copies of the ledger are maintained and that these copies are widely distributed. Without features like Confidential Transactions (or related technology such as ZeroCoin or ZeroCash), these systems may be unsuitable for those with confidentiality and privacy requirements. Do you want everybody in the network knowing your positions?

Based on what I’ve read so far, I’m not sure this is a full solution – financial firms care about more than just the value of transactions – but it’s a good start.

Next Steps

The test for me in coming weeks will be the extent to which non-Blockstream developers engage with this and other sidechains. I’ll also be paying particular attention to the Bitcoin Dev mailing list to see if any debate begins about making changes to the core protocol to allow decentralised pegging to work directly. [Update 2015-06-11 to correct pegging terminology. Thanks to joeykrug for the correction]

Posted by

gendal

Posted on

June 8, 2015

Posted under

Bitcoin, blockchain, replicated shared ledger

Comments

30 Comments

Towards a Unified Model for Replicated, Shared Ledgers

Don’t Say The “B Word”!

I’ve come to the conclusion that saying “blockchain” has become unhelpful. It just confuses people. It means too many different things to different people and so it’s almost impossible to have a conversation in this space without talking past each other. So, as I argued in this piece on permissionless ledgers and this piece on permissioned ledgers, it can be useful to talk in terms of replicated shared ledgers – since I think this gets to the heart of what unifies – and separates – these two worlds.

Shared: because multiple actors can read or write to different parts of the ledger
Replicated: because everybody who needs a copy can have a copy, rather than relying on a powerful central entity

In this piece, I try to bring it all together – to explain why we should be thinking about permissionless ledgers as a classic example of disruptive innovation and how I think banks could think about permissioned ledgers in the interim.

In what follows, I build up the model below from its constituent parts:

A unified model of permissioned and permissionless ledgers?

Permissionless Ledgers: Censorship Resistance

Let’s be clear: the breakthrough of Bitcoin was to create the closest system yet of “digital cash” – something that you can own outright and transfer to anybody else without permission. Its design flows naturally from that objective:

Bitcoin’s design follows directly from its objectives. Its replicated, shared ledger is designed to enable the existence of a censorship-resistant digital bearer asset

As I argued here, it’s little surprise that bankers and regulators look at it with deep suspicion! However, there’s a good reason why the smart observers aren’t dismissing it: censorship resistance implies an open, neutral platform that could be a driver of permissionless innovation:

Censorship-resistance enables permissionless innovation in digital ownership

So, it’s not a surprise that we’re seeing innovation and experimentation in the fields of value transfer – such as micro-micro payments (nanopayments?) for video content – and in the recording and execution of agreements. This is, almost but not entirely, exclusively being driven by people from outside the traditional financial sector. They’re taking a platform that is, in most meaningful ways, slower and more expensive than today’s financial system and using it for novel purposes.

I think the smart firms are keeping an eye on this because they know how stories like this end:

“Disruptive innovations usually find their first customers at the bottom of the market: as unproved, often unpolished, products, they cannot command a high price. Incumbents are often complacent, slow to recognise the threat that their inferior competitors pose. But as successive refinements improve them to the point that they start to steal customers, they may end up reshaping entire industries” (The Economist)

Permissioned Ledgers: Industry-Level Systems of Record

Notwithstanding the promise – or threat – of permissionless systems, I sense that many financial firms are looking closely at permissioned systems, by which I mean technologies that allow multiple firms to run a private, shared ledger of some sort. What most people fail to ask is: why?! If you don’t have censorship-resistance as your business objective, why are you looking at this space at all?

The answer, I argued, in this piece is that replicated, shared ledgers can also solve a different problem: if you’re in an industry where multiple firms all run similar systems to keep track of records (account balances? derivatives positions? orders?) then you’re probably carrying cost you don’t need: everybody is paying to maintain these duplicated, non-differentiating systems. And, because they’re all slightly different, you need to reconcile them with each other all the time to make sure they agree.

So the argument for applying replicated, shared ledger technology to this problem is that you could mutualise the cost of running and securing a single logical ledger, copied across your firms so you each have your own copy and so aren’t reliant on a powerful central entity for access. So nothing to do with censorship-resistance and nothing to do with cryptocurrencies. The idea, instead, is to move from each firm having its own systems of record to having systems of record at the level of the industry:

Is the promise of permissioned ledger the possibility of industry-level systems of record without a powerful central gatekeeper?

But we can take this thought-process further. Imagine such a platform existed: perhaps a replicated shared ledger that recorded all inter-bank balances or recorded all derivatives positions between firms. What we would effectively have is a transaction processing system for that industry: if we all agree that this shared ledger is authoritative for records (e.g. who owes what to whom) then could we not also agree that this ledger is something to which we could deploy code that describes our agreements? Could this industry-level ledger also host inter-firm business logic? How much cost and complexity might that remove from firms?

Is a common ledger between firms the enabler for a common transaction processing platform for an industry?

And this is where, I think, the two worlds – those of permissioned and permissionless ledgers – come back together:

Unifying the worlds of permissionless and permissioned ledgers

In the permissionless world, some of the most interesting developments are happening at the level of transaction scripting and smart contracts. The Ethereum project is the most obvious example, of course, but even projects like Streamium are showing how Bitcoin features can be used to create interaction models that simply aren’t possible on today’s financial platforms.

Similarly, and as I argued above, the driver of innovation on permissioned ledgers might be the migration of inter-firm business logic from individual firms to a shared ledger between firms: think of code that represents an agreement between two firms, that executes “on” a ledger, which can take custody of assets on that ledger and execute in response to external events: if both firms have signed it off in advance, suddenly they don’t need all the cost and expense of their own systems. I wrote about this idea in my piece on smart contracts.

So we see that the two worlds of replicated, shard ledgers – permissioned and permissionless – might actually be leading us to the same place: a world where business logic for money – automated fiduciary code, if you like – is deployed to a shared ledger and run autonomously.

Perhaps the permissioned and permissionless worlds aren’t as different as they seem?

Posted by

gendal

Posted on

May 12, 2015

Posted under

Bitcoin, blockchain, strategy

Comments

23 Comments

Blockchain is where banks have the most obvious opportunity. But you ignore Bitcoin at your peril

Nasdaq’s recent announcement shows you need a strategy for both

I have argued for some time that the world of “blockchains” is actually two worlds: the permissionless world of “bitcoin-like systems” and the permissioned world of “ripple-like systems”. The reason we so often talk about them together is because they share a common architecture: the “replicated, shared ledger”.

But they solve very different problems. Tim Swanson has written about the permissioned-ledger world and my last post gave an argument for why banks, in particular, should be paying close attention to them.

But this observation can be dangerous if people believe they are building a “blockchain strategy” for their firms when they are actually focusing only on the permissioned world.

As this exchange between Jerry Brito of Coin Center and Michael Casey of the Wall Street Journal shows, Nasdaq’s recent announcement of a blockchain experiment is noteworthy because they are explicitly building on Bitcoin, using a colored coins protocol, not on one of the permissioned/closed ledgers:

@mikejcasey are they using Bitcoin-inspired blockchain technology or "the" blockchain?
—
Jerry Brito (@jerrybrito) May 10, 2015

I have no inside information into this project. But it should give pause to any who had dismissed bitcoin-based platforms as being irrelevant to finance use-cases.

Forget Bitcoin at your peril?

As I argued in my last post, the world of permissioned ledgers is pretty easy to think about: if you’re in a market where multiple firms in the industry are all building and maintaining undifferentiated systems that do pretty much the same thing – and they have to be reconciled with each other – then it can make sense to replace them with a single system that you all share. But if you’re concerned about having a single central operator then these new blockchain technologies give you an option that didn’t previously exist: you can implement the common infrastructure on a replicated, shared platform that you all help secure/maintain and so mutualise the effort of maintenance rather than delegating it to a separate entity.

But, all too often, the analysis starts and ends there and disregards the “bitcoin-like” world. To see why this could be dangerous, we need to go back to the beginning.

The first nine words of the abstract to the Bitcoin whitepaper tell you everything you need to know to understand its architecture:

Everything you need to know to understand Bitcoin

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

Those nine words seem innocuous but they have profound implications and explain why so many people still steer quite clear of it. The key is “electronic cash”. What can you do with cash that you’d need to emulate in an electronic version?

First, cash is a bearer asset. The only way somebody can take away the money in my pocket is by confiscating it from me. Nobody in a central bank can “delete” my cash whilst leaving everybody else’s untouched.
Secondly, cash is a peer-to-peer instrument: I can pay you directly. There are no third parties we need to rely on, assuming we’re physically co-located

There’s a phrase for this set of requirements: censorship resistance. A true system of digital cash can only work if it is censorship resistant. And Bitcoin’s architecture does a pretty good job of achieving this through a very novel architecture. I sketch out some of the details for interested readers at the end of this article.

There’s just one tiny problem…

Censorship resistance is not an objective that is shared by most governments, regulators, banks or most individuals! No wonder there is so much controversy around the system. Perhaps it’s just easier for respectable firms to steer well clear.

And it gets worse when one observes that Bitcoin is worse than existing digital money in pretty much every significant way! It’s slower, it’s more expensive to operate, its value jumps all over the place and it’s really hard for consumers to use safely. So ignoring it is perfectly understandable.

But it could also be a mistake.

Permissionless Innovation

Because it turns out that censorship-resistance implies an even more interesting property: permissionless innovation.

“Permissionless innovation”—the general freedom to experiment with new technologies and business models—has been the secret sauce that fueled the success of the Internet and the digital economy

Think back to the design goal for the bitcoin system: electronic cash. And how that implied a need for a censorship-resistant bearer asset. These scary properties from a regulatory and banking perspective imply some very interesting properties from a technical perspective: this is the world’s first asset that can be held by anybody or anything and transferred to anybody or anything without needing permission.

Why could that be interesting? Let me sketch three simple scenarios:

The Internet of Things

How do you do KYC on a fridge? Do you really want your washing machine having your credit card details on file? Perhaps the future of machine-to-machine payments is one where the machines hold their own assets on an open system. Sure: you could build a permissioned payments system for device-to-device payments but the simplicity and open-access nature of Bitcoin could mean that it’s just easier to do it that way.

Firms for whom payments are a secondary concern

We often make the mistake of viewing this space through the eyes of incumbents. It can be useful to put ourselves in the shoes of others. For example, imagine you’re building a business for which getting a bank account and payment processing services would be difficult. Maybe you plan to operate in tens of countries. Or perhaps payments are a secondary concern for one of your use-cases… you just need a quick and easy way to make and receive payments. Sure… you could go through the process of getting a merchant account, signing up with a payment processor, proving compliance with various security standards. Or you could just use something with no barrier to adoption: bitcoin may have lots of problems but at least you can be up and running in seconds.

Second-order use-cases

Perhaps the most interesting future scenario is one where bitcoin isn’t used for payments at all. Instead, the security and censorship-resistance of its platform is seen as having value in and of itself – perhaps for notary services in the first instance – recording facts about the outside world – and so Bitcoin becomes nothing more than the token you need to own in order to purchase the services of the network. It becomes an app-coin, if you like.

Why we need to keep an eye on the Bitcoin world

I accept that none of these use-cases is particularly compelling as I write this piece. There are lots of great counterarguments for all of them. But that’s partly the point: if any of these were obvious, nobody would be dismissing it.

And this is why I find the Nasdaq example so interesting. Using the inherent security and open-access of the Bitcoin system to “carry” representations of real-world assets – “colored coins” – is an old idea*. And it also fits into my “second-order use case” category above.

Now, Tim Swanson and others have written convincingly about many theoretical issues with the idea but we now have a brand-name firm experimenting for real and we’ll hopefully all learn from the exercise in time.

So, sure: bitcoin raises all kinds of conceptual, legal, technical and philosophical questions. But it would only take one of these scenarios to drive some adoption and, very quickly, bitcoin might cease to be a sideshow. And, given that its core design goal of censorship-resistant digital cash has such disruptive potential – good and bad, this possibility alone is reason to keep an eye on it. Dismissing it entirely could be a big mistake.

Coda: How to build a system of digital cash

Note: you don’t need to read this section to understand the main argument of this piece.

Recall the implications of a true digital cash system: censorship resistance. This drives some very strong implications for anybody trying to design such a system:

First, you simply can’t have the concept of an issuer in such a system: the issuer could selectively choose to honour only certain claims.

So, if you can’t have an issuer of the currency on such a platform, it will have to be native to the platform. Hence Bitcoin as the currency unit and the interminable debates about why it has value and what that value should be, if anything.

If you want true electronic cash, there can’t be an issuer. So the asset has to be native to the platform

Secondly, you can’t have an identifiable operator or processor for such a system, either: they could choose to block certain transactions and their central database would be an obvious target for those seeking to exert control. So this means you need to have lots of actors providing the processing services and they need to be able to join and leave. And they probably also all need their own copies of the ledger – we can’t have a single central one, after all:

If you want true electronic cash, its ledger will have to be massively replicated and you’ll need a large pool of “processors”

Thirdly, you’ll need to pay the processors. You obviously can’t pay them with “real” money (since the issuer of that money could simply refuse to allow payments to be made to processors who refuse to co-operate with them). So you’ll need to pay the processors with the platform’s own asset:

If you want true electronic cash, the processors will need to be paid in the currency of that platform.

The breakthrough of bitcoin was figuring out how to put these building blocks together: how to ensure sufficient scarcity of the currency unit? How to keep the multiple ledgers synchronized? How to ensure the processors’ incentives are aligned with those of the users of the system? And so on.

There’s more than one way to talk about it

Of course, this isn’t the only way to think about the system. If you’re still interested, here’s my attempt to explain how it works by imagining how you could invent digital cash using an email system.

*Disclosure: I am an adviser to a colored coins firm (ChromaWay) in a personal capacity, albeit one that uses a different architecture to the one apparently being explored by Nasdaq

Posted by

gendal

Posted on

April 27, 2015

Posted under

distributed ledger, replicated shared ledger

Comments

56 Comments

How to explain the value of replicated, shared ledgers from first principles

“Digital currencies” aren’t needed to explain why distributed ledgers are important.

In this post, I develop an argument for replicated shared ledgers from first principles. It is intended to be an “education piece” aimed at those, particularly in the finance industry, who prefer explanations of new technologies to be rooted in a description of a real-world business problem rather than beginning with a description of a purported solution. So, in this piece, you’ll find no mention of digital currencies, etc., because it turns out you don’t need them to derive an argument for distributed ledger technologies!

(Note to regular readers: see the end of the piece for some context)

We’ll start with banking systems

Start by thinking about today’s banking systems. In what follows, I use a bank deposit and payments example. But the same logic applies everywhere you look, as I’ll argue later.

Let’s imagine a world with three banks: Bank A, Bank B and Bank C and two customers, Customer A and Customer B. Each bank runs their own IT systems that they use to keep track of balances. This is a world very much like today.

So Bank A’s systems record the balances for Bank A’s customers, Bank B’s systems record the balances for Bank B’s customers and so on.

Perhaps the picture looks something like this:

Balances at three banks for two customers.

Two immediate observations jump out:

First, look at Banks A and B. Bank A’s systems record that it is owed £1m by Bank B. And Bank B’s systems also record this fact: they record that Bank B owes £1m to Bank A. So the same information is recorded twice, by two independently developed, maintained and operated systems. And in other domains, this duplication is much greater and more expensive, as we’ll discuss below.
Secondly, look at Customer A. They are owed money by banks A and C and are overdrawn at Bank B. Put another way, Banks A and C owe money to Customer A. Who records this fact? Banks A and C! We take this situation for granted but it does seem very odd that Customer A has to trust both that the bank will be good for the money and that the bank’s records will be accurate. That feels like a conflict of interest, if ever there was one…

So we have two interesting phenomena: deposit-makers have to trust their banks to be good for the money and to account for things correctly. And the banks themselves have to spend a lot of time and money developing systems that all do pretty much the same thing – and then spend even more time and money checking with each other to make sure their systems agree on common facts.

Even in our simple example, there are potentially 7 separate matching entries to be verified.

Banking “facts” are usually recorded by at least two different entities and an expensive process of reconciliation is needed to make sure each party’s view of the world is the same

It’s not just bank deposits. Securities and Derivatives Markets have the same pattern

This story is about bank deposits. But exactly the same story could be told about securities systems and derivatives systems. Indeed, in the latter case, the problem could be even worse: not only do we need to be sure everybody agrees on who has done which deals with whom, we also need to be sure that their systems agree on the resulting obligations that arise – they also have to agree on the business logic.

Think about how many near-identical systems exist across the financial landscape, each one working slightly differently and producing ever-so-slightly different results that have to be investigated and resolved. It’s hugely expensive.

Back to the banking story

But let’s focus on the banking example for now.

You can do something really interesting with the five ledgers we’ve been working with. You can write them a different way, with all the same information stored in a single table, rather than spread across five different tables:

The five separate ledgers on the left can be written, exactly equivalently, as the single table on the right – and vice versa. You can derive one from the other. The only difference is that the table on the right has an extra column so we can record both the issuer and the holder of a claim .

In other words, rather than having a partial view of the world held by each bank, we could have a single table that records everything and achieve the same outcome.

So why not just have a single banking ledger for the world?

This raises an interesting question. If it’s so expensive and complicated for each bank to run its own system that contains its own narrow view of the world – and then have to check it matches the other systems where the facts overlap – why not just pay somebody to run a single ledger that everybody agrees will be authoritative?

After all, as we showed above, any bank that wanted to could easily derive its own view of the world from this mega-table, completely trivially.

Of course, we’d have to give thought to how to mediate access to the ledger – who is allowed to observe or update which records – but we know how to do that… and it’s not an impossible problem.

Are you mad?!

Now, it is tempting to say that such a thing would be insane: imagine how powerful would be the firm who ran such a system. And imagine the catastrophic implications for the world if there was a system outage! Perhaps the expensive, error-prone, but fundamentally decentralised and robust (anti-fragile?) system we have today is a price worth paying.

But this means an interesting question arises: what if there a way to achieve the benefits of a globally shared system but without having to grapple with the difficult political question of how to control an all-powerful operator or how to deal with the risk of an outage of such an important, central piece of infrastructure?

Perhaps we can achieve this…

The Replicated, Shared Ledger

Remember what we achieved in the diagram above: we created a single table that could describe all bank balances and which was inherently shared: different actors had different permissions to update different parts of it.

But the worry in the section above was that a shared global ledger would be controlled by a single powerful entity and that this centralized system could be a systemic risk. So can we make two tweaks to the model?

First, why not replicate the ledger massively. So, rather than one copy, have lots of copies. Perhaps one copy at every bank. So now there isn’t a single point of failure. We would have to worry about how those copies are kept in sync, of course, so this isn’t an unambiguous “win” but having copies at each bank might also make integration with existing infrastructure somewhat easier, too. Perhaps this would also help ease adoption.
Secondly, why not have those who participate in the system – maybe just the banks or maybe their customers too – also be jointly responsible for maintaining and securing it. We know who everybody else is in this world, after all, so we know whom to punish if they cheat. So we replace a single powerful entity with a model where everybody contributes to the system’s security.

If so, perhaps the picture would look like this:

If a single copy of the global, shared ledger is undersirable or risky, then replicating it to all the participants could give the best of both worlds. Now the problem becomes one of automatically keeping the systems in sync rather than manually reconciling and dealing with breaks.

The picture above looks superficially like the one I drew at the start of the article. But there’s a critically important difference. In this model, all participants have a copy of the ledger but only have the right to amend entries pertinent to them. So it is both replicated and shared.

And so this is why I call this concept the “replicated, shared ledger”. I think this wording is better at evoking the right mental model than “distributed ledger”, for example.

And depending on whether you want to model balances, other assets or even agreements between parties, there are startups working on a project. I wrote a piece last year that attempted to make sense of the various players out there – and many more have emerged since then.

“Smart Contracts”

It it worth paying particular attention to the idea of adding business logic to this concept: so that the “facts” being recorded aren’t just who owns what but actual agreements between parties.

This opens up the intriguing possibility of “smart contracts”: a world where derivatives counterparties agree that a shared piece of code represents the agreement they have made with each other and they execute it on the shared, replicated ledger – perhaps completely eliminating the need to build, maintain, operate and reconcile their own proprietary derivatives platforms? Maybe even allowing the code to take custody of assets on the ledger, to manage cashflows and margin automatically?

Outstanding questions

But I should stress that this approach raises lots of technical questions: it’s not an unambiguously good idea. For example, do we know that the underlying replication technology works as described? Under all plausible threat scenarios? How can we be sure that one bank (or customer) can’t see (or amend…) another’s information? How much data would such a system hold? Would it scale? Is it really a good idea to model legal agreements in code rather than English?!

Conclusion

There do appear to be multiple examples of expensively duplicated systems in multiple areas of the banking system. The idea of a shared ledger holds promise, with replication by participants being a mechanism to reduce risk and mutualise its operation. But whether this argument holds in practice needs to be tested. So I fully expect to see more and more experimentation by banks and others in the coming months and years.

Thank you: I’m extremely grateful to Lee Braine for input/review of the logical argument in this post

Note to regular readers

For the avoidance of doubt, in the piece above, I was not talking about Bitcoin – I’ll post a separate follow-up that attempts a derivation for Bitcoin’s design given some plausible real-world requirements; this post is about the domain I sometimes call the non-“Bitcoin-like-world”, as defined in this post)

Posted by

gendal

Posted on

March 30, 2015

Posted under

Bitcoin, Ripple, smart contracts

Comments

19 Comments

Bitcoin as a Smart Contract Platform

Distributed Ledger Platforms may be Getting All the Hype but the architecture of Bitcoin is more sophisticated than many people realise

I was a guest of the Financial Services Club Scotland last week. I presented an update on the world of cryptocurrencies to an engaged and well-informed audience in the library of the Royal College of Physicians.

I reprised my current theme that the world of “blockchains” is really two distinct worlds – the world of Ripple-like ledgers and the world of Bitcoin-like systems – that happen to be united by a common architecture, the Replicated, Shared Ledger. This unifying concept is based on the idea that each participant has their own copy of the entire ledger – and they trust the “system” – whatever system that is – to ensure their copy is kept in sync with everybody else’s. The differences are about what the ledger records and how it is secured.

Bitcoin-like and Ripple-like systems

Broadly speaking, Ripple-like systems are focused on the representation of “off-system” assets and are secured by identifiable entities. Systems like Ripple, Hyperledger and Eris are broadly in this world, I think. The security model of these systems is based on knowing who the actors are: if somebody misbehaves, we can punish them because we know who they are!

Bitcoin-like systems are more focused on “on-system” assets and are secured by an anonymous pool of actors. Bitcoin and Ethereum are broadly in this space, I think. The security model here is based more on game-theoretic analyses of incentive structures: the goal is to make it overwhelmingly in the actors’ financial interests to do the “right” thing.

There is, of course, some ambiguity since all platforms have some notion of “smart contracts” – or otherwise recording real-world agreements, as well as asset ownership. But this makes intuitive sense. If your platform is concerned with real-world assets and agreements then you necessarily need some concept of identity (who are the issuers?). And if you’re reliant on the performance of real-world actors, why not also rely on them for the overall system security? Likewise, if the whole purpose of your platform is to create and manage a new asset that can be controlled/subverted by nobody, then giving identifiable entities the power to control your security would seem to defeat the point!

Different design goals, different implementations. And the value of such systems to banks, corporations or individuals is, ultimately, an empirical question. I imagine 2015 will be the year where we discover many of the answers.

Incrementalism versus “Disruption”

But I went further in my talk. I observed that these two worlds also differ in one other respect: the Bitcoin-like systems could be disruptive to existing institutions if they gained widespread adoption, whereas Ripple-like systems seem, to me, to be far more closely aligned to how things work today and are, perhaps, a source of incremental innovation.

If this observation is correct, then firms looking at this space probably need to assess the technologies through different lenses. The question for banks for Ripple-like systems is: “how could we use this to reduce cost or improve our operations” whereas the question for Bitcoin-like systems is: “how would we respond if this technology gained widespread adoption?”

And to answer the last question, one must be sure to really understand what the system under analysis really is!

Bitcoin as a currency might be to miss the point

For me, it is a mistake to think about Bitcoin solely as a currency. Because the Bitcoin currency system is a masterclass in mirage: underneath the hood, it’s a fascinating smart contract platform.

Or, as I said at the Financial Services Club, every time you make a Bitcoin payment, you’re actually asking over 6000 computers around the world to run a small computer program for you… and your only task is to make sure that the computer program returns “TRUE”. Within the Bitcoin community, this is well-known, of course. Indeed, the work done by Mike Hearn and others to document the platform’s capabilities has been around for years. But I find most people in the broader debate are unaware that the platform is pretty much built on this capability – it’s not an add-on.

Bitcoin is a smart contract platform

I wrote a piece last year offering an intuition for how Bitcoin works, in terms of land. My point was that the fundamental building block of the system is the “unspent transaction output”, or UTXO. The UTXO is what you get when somebody “pays” you some Bitcoin. The “output” of their transaction is the money they paid to you. And whilst it sits in your “wallet”, it is, obviously, unspent. Hence “unspent transaction output”.

So you can think of the current state of the Bitcoin system as being a huge pool of UTXOs: all the payments that have been received by Bitcoin users that they have not yet spent:

Every payment that has not itself been spent is modeled in the Bitcoin system as an “unspent transaction output”. In general, each UTXO can only be spent by the owner of the “address” to which it was sent (not always, and this is the point; see later). And each UTXO has an identifier (the transaction it appeared in and its position in the list of outputs of that transaction) and a value: how many Bitcoins are represented by that UTXO.

But what people often miss is that these UTXOs are actually tiny little computer programs that live on the ledger, control access to bitcoins and run in response to specific incoming events. Smart Contracts, if you will. And the only way you get to spend the money controlled by that contract is if you can provide some input data that allows every node on the system to execute the program and check that it returns “TRUE”

If you can make the program return “TRUE”, you get to say what happens to the funds. If you can’t, then you don’t.

So, when you want to spend your money, here’s what you do:

Your wallet software writes a little computer program for you and then sends it into the bitcoin network. It effectively says to the network: “Please run this little program I’ve just given you. Then please find a program (“smart contract”?) on the platform with this ID for me. When you’ve done that, feed the output from my program into program you just located”. So this is a two step process: you provide your own little program… and the output of that is fed to the UTXO program that you want to spend.

The way you spend money in Bitcoin is to ask the platform to run a small computer program that you provide and feed the output of that program to the “smart contract” that is storing the funds you want to spend. If you can make this second program run successfully, you get to spend the money. In Bitcoin terminology, the program you provide is “scriptSig” and the UTXO program is “scriptPubKey”. Your goal is to provide a “scriptSig” whose output can be fed into “scriptPubKey” to make it return “TRUE”

So what are these little programs? In the common case, they’re really simple. The “UTXO program” simply says: “provide me with a digital signature that proves you own the key associated with the following Bitcoin address (and please also prove that you know the public key that corresponds to the bitcoin address)”. That’s why it’s called the “scriptPubKey”.

And the program you provide is just a way to ensure the bitcoin system sends this proof into the scriptPubKey program in the right way. It’s a way of providing a digital signature. Hence it’s called the “scriptSig”

If you don’t know the private key then you can’t generate the right signature and so you can’t create the input necessary to get the smart contract (scriptPubKey) to run successfully and you don’t get to spend the funds. So this, seemingly complex model, is just a way to ensure that the only person who can spend money at address 1abcde… is the person who knows the private key… exactly as we would want.

Why is it this complex?

But notice how powerful this is… because the other thing you do is tell the system to replace the existing scriptPubKey program with one or more new programs. And this is how your payment is modelled in the system. You pay somebody by creating a new program (a new scriptPubKey) that only they will be able to execute successfully. In this way, you can pay different people or send change back to yourself. The program that only you can run is replaced with ones that only the payees can run. And, in this way, the value has been passed from you to them.

So the result is that the original program living on the ledger is replaced by one or more new programs. In the usual case, one or more of these new ones will be associated with somebody else’s bitcoin address so only they will be able to control it. You have, in effect, paid them that money since the funds are now under their control

Paying somebody in Bitcoin is the same as replacing the program you control with ones they control. In this diagram, the funds you controlled have now been split between two new recipients. Only they can spend those funds.

Smart Contracts?

So what does this have to do with smart contracts? The key is that the model I outlined above is quite generic. The programming language is (just about) powerful enough to implement some interesting business logic that goes beyond “Richard paying money to Bob”. For example, you can write a program that will only return “TRUE” if you provide proof that you know the private key to multiple bitcoin addresses. This is a way to model “a majority of Board Directors must jointly sign before these funds can be spent”, perhaps. The Bitcoin “contracts” wiki page goes into far more depth.

However, the reality is that the capabilities of the platform are actually quite constrained – and I think this explains a lot of the interest in other platforms, such as Ethereum. However, it should be noted that Gavin Andresen has argued that Bitcoin’s limitations need not be a constraint.

So what?

Some might argue that it’s not necessary to think about Bitcoin in this way. But I think that would be a mistake. Because, while lots of people are getting excited about the potential of smart contracts for business, we’ve had a sophisticated smart contract platform running quite successfully for over half a decade, in the form of the Bitcoin network.

Sure – it’s very limited (that’s why systems like Ethereum are getting built). But it might be a mistake to bet that it won’t evolve.

Ultimately, my point is this: even if there’s a low probability of success for a potentially disruptive system, it surely makes sense to understand everything possible about what that system can actually do…

[Disclosure – I provide advice to Hyperledger in a personal capacity.]

[Update – 2015-03-30 Typos and replaced first diagram… I accidentally included an older version that used random IDs for UTXOs that looked like bitcoin addresses, which was very confusing…]

Posted by

gendal

Posted on

March 5, 2015

Posted under

distributed ledgers, fedcoin, Ripple, smart contracts

Comments

28 Comments

A Central Bank “cryptocurrency”? An interesting idea, but maybe not for the reason we think

The retail use-cases get all the press… but the killer-app for digital central bank money might be smart contracts

This post on a concept called “FedCoin” by David Andolfatto of the St Louis Fed raises the really interesting possibility of a world with central-bank-issued digital assets which can be held by a broad range of people.

Andolfatto’s FedCoin post

The core idea is essentially a variation on the digital cash theme: a digital bearer asset that is redeemable for dollars. So, on the surface, just like m-pesa but for dollars, right?

Not quite. Because Andolfatto’s FedCoin idea has two important differences.

First, FedCoin would be issued by the central bank. That contrasts with most other digital cash systems, where the holder has a claim against a telecoms firm or a commercial bank. In those systems, you have to trust the central bank not to inflate away the currency (as you do here) but you also have to trust the commercial issuer not to go bust – or any deposit insurance scheme to bail you out if they do. A central bank digital asset doesn’t have that second issue.

Secondly, Aldolfatto suggests this currency could be issued on a distributed ledger. As he writes in an update to that post, many people have questioned why that might be necessary. Surely if you trust the fed enough to hold its currency, you trust it to run an accounting system! However, I wouldn’t dismiss this suggestion just yet, as I’ll argue below.

Robert Sams has an intelligent and thoughtful analysis of the overall idea.

So why am I writing about it now?

It’s not just the US: what about the Bank of England?

No sooner had the FedCoin idea been discussed and dissected, the Bank of England published its 2015 “Research Agenda”: a paper summarizing all the questions they plan to examine this year.

Turn to page 31 and guess what… there’s a section on Digital Currencies. If you haven’t read it, I urge you to do so. Because it doesn’t say what one might expect it to. Most official papers on “digital currencies” are influenced by Bitcoin and talk about volatility, monetary questions, the tedious question of whether cryptocurrencies pass the “money test”, regulation and so forth.

This paper doesn’t. Instead, it follows the same line of reasoning as Andolfatto and focuses directly on the question of what a central bank-issued digital currency might mean. And the paper does something really valuable: it lists a set of questions that anybody planning to do something in this space would have to answer.

The Bank of England’s Research Questions for a Central-Bank-issued digital currency

And these are important questions. Imagine something like FedCoin was built and you were able to hold a digital asset that represented a claim on the Bank of England or the Federal Reserve. The implications for commercial banks could be huge: why would you lend your money to (aka “deposit with”) a retail bank if you could hold the same money in a counterparty-risk-free form?

So the commercial banks would probably have to compete for your deposits with higher interest rates. But wouldn’t that make them more risky and more likely to fail? So perhaps the central bank would have to charge you to hold their digital asset (a negative interest rate?) to encourage you not to hold too much of it and lend the rest to the commercial banks. But now the digital “cash” isn’t the same as physical cash…

And there’s another question. If everybody has access to central bank money, then why do we need payment systems? I wrote a simplified explanation of how money moves around the banking system a while back – and the noteworthy thing about it is that pretty much all of the payment infrastructure in the world exists because most money isn’t central bank money. If you imagine a world where everybody holds central bank money, suddenly the picture begins to look a lot simpler…

Do you need need most payment systems in a world with only FedCoin…?

There’s more… Do we really want people having access to unlimited amounts of digital bearer assets denominated in GBP or USD? Do central banks have the culture, systems and experience to oversee such a scheme and spot misuse, fraud and crime?

So perhaps a hybrid implementation, would emerge where consumers have to nominate a “sponsoring” commercial bank, which provides safekeeping services, has oversight responsibilities and, perhaps, has the ability to block suspicious transactions?

Who knows. And I should stress that I don’t think anybody is proposing a system like this in any case…. These are research questions. But it suggests that the BOE questions are a very good starting point for thinking about these issues.

A solution looking for a problem?

But there’s a small issue: this intellectual exercise is fascinating but is a central bank digital currency actually needed? With a few notable exceptions, depositors don’t tend to lose their deposits when commercial banks fail. (But businesses and other large depositors often do…) And aren’t capital rules and prudential supervision designed to solve that problem in any case?

**Remember I said the “distributed ledger” aspect of FedCoin was interesting…**

Think back to the Andolfatto piece. He mused about building “FedCoin” on a distributed ledger. On its face, that doesn’t seem to make much sense.

But if we open the topic of distributed ledgers, it also brings Smart Contracts into play. In my recent piece on the topic, I suggested a definition for a smart contract as follows:

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

Implicit in my definition was that these “assets” could be native assets to the ledger (e.g. Bitcoin). But , more likely, they would be representations of real-world assets: GBP tokens issued by Barclays or HSBC or Coop, say.

For example, you could imagine consumers paying £50 a month into a “mobile phone insurance smart contract” and, if they can provide proof that they’ve lost their mobile phone, the smart contract will pay out enough money to replace the phone, using the funds that have been paid in by all the policyholders.

Perhaps the “proof” would be in the form of a “proof of purchase”, signed by a retailer and an “attestation of loss”, cosigned by the policy holder and a police officer. The details here don’t matter too much.

But what does matter is the payment.

How would you write a contract like this so that it could be sold to as many consumers as possible? They probably have accounts with different banks and, if we imagine a world of distributed ledgers, they’d all be holding different tokens: GBP-Barclays, GBP-Coop and so on.

Which tokens should an insurance contract accept from its customers? Only tokens issued by “safe” banks? Which ones? Who controls the list? What about a £1000 IOU from me? Would the smart contract accept that? What about a £1000 IOU from a billionaire?

What happens when the contract pays out? If you had paid in GBP-Barclays, how would you feel about receiving an arbitrary mix of GBP assets when you made a claim, based on whatever happened to be in the pool at the time?

Writing a smart contract that deals with GBP issued by multiple issuers gets complicated very quickly…

Systems like Ripple solve this problem by explicitly modeling the idea of an asset and its issuer. 50 GBP-Barclays is different to 50 GBP-HSBC and Ripple is built on that insight. So you could certainly configure the contract to trust some issuers but not others.

But it gets complicated. What happens if one of those issuers gets taken over? Goes bust? Who updates the list of “trusted” issuers in the smart contract?

And now, scale the problem up to the institutional side of the world, where the sums involved in derivatives contracts are enormous. Suddenly the identity of the issuer really matters.

And this is where I think a central bank digital currency could make sense on a distributed ledger. It would clear away all that complexity.

You could simply write the contract to demand payment in the central bank token. Policyholders would have the responsibility of converting other GBP assets into the central bank issued asset.

Now, perhaps this wouldn’t be a problem in real life – maybe you could just write the smart contract to only accept GBP-Barclays, say, and insist customers of other banks convert into Barclays tokens in order to use the contract. But having a counterparty-risk-free representation of fiat currencies on these smart contract systems feels like it could be extremely useful.

But time will tell, as always.

Posted by

gendal

Posted on

February 10, 2015

Posted under

ledgers, smart contracts

Comments

35 Comments

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.

Conclusion of smart contract discussion: no-one has a clue what a smart contract actually is, and if we did it'd need oracles.

— Peter Todd (@petertoddbtc) December 5, 2014

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:

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:

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:

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…

Posted by

gendal

Posted on

January 15, 2015

Posted under

Bitcoin, consensus, ledgers

Comments

29 Comments

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:

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

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.

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:

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:

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:

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.

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?