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

Could decentralized ledgers change the face of accounting?

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

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

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

Ledgers

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

Investopedia has a good definition of a General Ledger:

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

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

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

A worked example

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

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

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

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

Hang On – What’s a Balance Sheet?

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

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

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

Balance Sheet 1

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

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

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

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

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

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

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

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

Balance Sheet 2

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

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

If only banks really were this simple…

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

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

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

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

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

Great. So your balance sheet now looks like this.

Balance Sheet 3

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

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

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

So you might end up with a picture like this:

Balance Sheet 5

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

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

Making sure all these ledgers are kept in sync: reconciliation

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

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

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

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

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

Balance Sheet 6

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

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

Balance Sheet 7

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

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

Enter Decentralised Ledgers

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

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

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

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

Balance Sheet 8

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

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

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

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

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

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

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

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

 

The “Unbundling of Trust”: how to identify good cryptocurrency opportunities?

Decentralization and centralization are two ends of a continuum. Look for opportunities to disaggregate “bundles of trust” to identify good opportunities in the cryptocurrency space

There are so many potential uses for cryptocurrency technology. But how do you know if any of them are good ideas? Blockchain-mediated financial exchange? I have a good feeling about that one. A bank-sponsored local currency system for small businesses? My sense is that it’s probably a terrible idea. But short of going out and building it, how would you know?

So are there any test you can apply beforehand to figure out if a blockchain is a good technical solution for a given problem?   And can you turn a bad idea into a good idea?

It’s a topic that comes up regularly when I present to audiences on Bitcoin and cryptocurrencies. Here are some slides I often use in these discussions. Slide 15 is where I discuss this topic.

Slides I sometimes show when presenting on cryptocurrencies. These represent my views, not IBM’s. But they are Copyright IBM. Please do not reproduce without asking permission first.

For me, the key to deciding if an idea is good enough is the one I’ve summarized on page 15 of the deck: this space is all about decentralization and if your problem isn’t about centralization then this technology may not be for you.

That may sound obvious. But internalizing this point is the key to understanding what a good cryptocurrency use-case looks like. And how to turn a bad one into a good one. Because even if your problem looks centralised, there may be portions that don’t need centralised trust and unbundling those components could be the key to doing something valuable. Here’s what I mean…

Go back to the beginning: what problem was Bitcoin designed to solve?

Bitcoin was invented as an answer to a decades-old question:

How do you come to consensus about some facts with a large group of people when you don’t know each other and some of you are cheating?

In Bitcoin’s case, the “facts” are “who owns what?”

And one answer to that question is, of course: “we all agree to trust somebody (e.g. a bank) and now we don’t need to trust each other”. But the obvious problem is: you have to trust the bank and that’s a potential point of failure. The breakthrough of Bitcoin was in showing us how to answer this question in a way that doesn’t require us to trust any single third parties.

We say the system is “decentralized”, as a shorthand for this concept.

(As an aside, I explained Bitcoin from first principles in this post on how the counter-intuitive genius of Bitcoin is that it works by going slow! For those who want to go even deeper, I share a way to think about the confusing “Unspent Transaction Output” concept in Bitcoin through an analogy of land.)

This is why Bitcoin is often positioned as being a decentralized equivalent to the centralized banking system:

decent1

Bitcoin allows us to agree who owns what without having to know each other or trust anybody else. This is the opposite of the traditional system where everybody has to trust their bank

Bitcoin-as-envisaged isn’t what we have

But there’s a problem: Bitcoin-as-envisaged isn’t what we have today. Phenomena such as mining centralization and the use of SPV Wallets mean that Bitcoin isn’t completely decentralized. It’s not currently a problem but one can already see its effects. For example, some miners refuse to mine certain types of transactions. The effect on average confirmation time for these transaction types might be marginal but it exists, nevertheless.

So Bitcoin-today is somewhere in between. It’s not 100% decentralised yet nor is it centralized.

decent2

Bitcoin today is neither fully decentralized nor is it centralised

So it seems reasonable to consider that centralization may actually be a continuum rather than an either/or phenomenon:

decent3

Are centralization and decentralization actually two ends of a continuum?

This way of thinking can be helpful because it allows us to think about other innovations in this space, such as Smart Property.

Smart Property

I’ve written in the past about a decentralized securities systems being built “hidden in plain sight”. The key idea here is that you can use blockchain platforms (like colored coins or counterparty, etc) to track the ownership and transfer of real-world assets. What distinguishes these platforms from Bitcoin itself is that they have to bridge to the real world: the asset could be a bond with a corporate issuer, being kept safe by a custodian bank, for example.  So there are several real-world entities on whom you depend.

I’ve written about how smart property allows these two roles to be merged (the issuing company could do both) but somebody has to do it – let’s just call them issuers.

So this system has points of centralization (the issuers) and points of decentralization (the ownership tracking and exchange). So perhaps it sits somewhere here on the continuum:

decent4

Perhaps there is value in different “degrees” of decentralization for different business problems

You can have more than one type of decentralization in a single service

But it’s actually more interesting than that. Because not only do smart property systems sit somewhere on the decentralization continuum, the key point is that different parts of the systems sit in different places:

  • the ledger, exchange and transfer system use the underlying Bitcoin consensus system – so they’re all pretty decentralized. No need to depend on any trusted third parties.
  • But you do, of course, have to trust the issuer.  That part of the proposition is centralised

So the important thing about smart property systems is that the all-or-nothing “trust bundle” is unbundled: you need to trust a specific issuer but the ledger, exchange and transfer functions are decentralized in their operation.

The unubundling of trust

And I think that’s what gives decentralised consensus systems some of their power: you can now break down products and services into their constituent elements of trust and implement each one with the most appropriate degree of centralization. For smart property, perhaps the picture looks something like this:

decent5

Different degrees of decentralization can exist within the same service: trust is being unbundled

So what?

Of course, none of this tells us whether smart property or cryptofinance is a good idea. But it is a way to think about whether a particular service is doing anything particularly novel.   Think about it the other way: if somebody proposes a cryptocurrency business idea that doesn’t meaningfully unbundle any trust in an existing service, is it actually doing anything valuable?  Likewise, take any real-world centralised service and ask yourself: what are all the things I need to trust for this to work? Which components have to be centralised? Which could be decentralised? Does that lead to lower risk? Lower cost? More opportunities for competition? Reduced friction for consumers? If the answer is “yes” to those questions then you could have an interesting proposition on your hands.

Unbundling trust in payments

A similar analysis works for systems like Ripple. Ripple’s architecture is more distributed than the traditional payments systems but less so than Bitcoin (at least as envisaged) so perhaps we may place it somewhere like this on the scale:

decent6

Ripple is another example of a “trust unbundling”

But, just like in the Smart Property example above, in the Ripple system there is a “trust unbundling” going on: the ledger is fairly decentralized in its operation whilst you necessarily need to trust a specific gateway.  So it actually looks like this:

 decent7

Different degrees of decentralization can exist within the same service: trust is being unbundled

To see why this is important, recall how current payment systems work. I wrote a simple explanation of it here. As the article shows, you have to trust a lot of moving actors and the point is that you have to take this as a bundle… it’s all or nothing. You trust all those parts of the system or you can’t achieve your objective.  With a Ripple-like system, you only trust the minimal set of actors you have to – namely, the banks who issued liabilities.  Everything else can be decentralised to some degree.

Unbundling trust in contract execution

One last example: a similar argument applies to financial contracts. Projects like Ethereum (and Counterparty!) are exploring the decentralized modeling and execution of law. Gavin Andresen has written about how something similar could be achieved on the base Bitcoin platform.

You can think of this in terms of “trust unbundling” too: the decentralized platform ensures the integrity of contract execution and you can use n-of-m oracles to provide reliable external data. You only trust who you have to, to the minimal degree possible.

Using “trust unbundling” to turn bad ideas into good ideas..?

So now we can put this model to the test. Does it help us spot the silly ideas? Even better, does it help us turn the silly ideas into good ideas?  [UPDATE 2014-11-15 this section was heavily reworked)

Antonis Polemitis commented on an earlier version of this article:

Here’s what I think he means:

A better airline miles system?

As Antonis points out, airline miles systems are highly centralised: the airline is the issuer, redeemer, owner of the ledger, setter of the rules and controls everything else too.

So imagine an airline were to announce that their new airmiles programme was to be based on a fork of Bitcoin. Perhaps they would create their own Blockchain, issue the miles on top, secure it themselves and distribute wallets to all their customers. Brilliant…  an airline miles programme with all the benefits of Bitcoin!

Really? From a consumer perspective, surely this system would be indistinguishable from a traditional system and what is the argument that says it would be better in any meaningful way?

But take a step back and think about airline miles again and think about the trust bundle. Which parts of the system require you to trust the airline?  Issuance and redemption of the miles, for sure.  And setting of the scheme rules.  But storage, exchange and trade doesn’t need to be done by them.

And perhaps there’s a cost saving for airlines if they offload that work to a decentralised network and a benefit for customers if it gives them additional utility – perhaps new ways of swapping miles between competing programmes to accumulate enough points to book a flight?  Some very interesting possibilities emerge if multiple airlines base their systems on the same platform or if third parties can build new services on top of a platform like this.

Suddenly you might have something interesting: an interoperable, multi-provider airline miles storage, transfer and redemption platform. Now it could be a terrible idea – these schemes only work because most miles are never redeemed, after all! But the thought process is important: who are users expected to trust to use your service?  And what are they trusting them for?  What if a component was decentralised? What new possibilities would that enable? What risk could it mitigate?

Now the real world is more complicated than this. But the key insight remains:

  • if your cryptocurrency idea requires users to trust only you, you’re missing the point
  • but if there’s something in the value proposition that can be usefully decentralized or shared with others, you could be on to something