A Simple Model for Smart Contracts

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

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

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

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

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

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

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

The Replicated, Shared Ledger

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

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

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

SmartContracts1

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

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

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

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

SmartContracts2

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

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

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

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

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

What does this ledger record?

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

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

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

So where else do we have duplication?

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

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

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

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

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

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

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

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

But we can go even further

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

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

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

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

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

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

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

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

SmartContracts4

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

So much for the theory

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

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

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

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

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

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

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

Could decentralized ledgers change the face of accounting?

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

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

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

Ledgers

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

Investopedia has a good definition of a General Ledger:

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

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

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

A worked example

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

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

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

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

Hang On – What’s a Balance Sheet?

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

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

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

Balance Sheet 1

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

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

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

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

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

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

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

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

Balance Sheet 2

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

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

If only banks really were this simple…

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

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

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

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

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

Great. So your balance sheet now looks like this.

Balance Sheet 3

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

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

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

So you might end up with a picture like this:

Balance Sheet 5

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

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

Making sure all these ledgers are kept in sync: reconciliation

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

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

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

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

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

Balance Sheet 6

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

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

Balance Sheet 7

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

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

Enter Decentralised Ledgers

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

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

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

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

Balance Sheet 8

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

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

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

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

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

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

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

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

 

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

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

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

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

Who do I trust

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

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

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

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

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

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

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

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

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

Event 3: The Eris Launch

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

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

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

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

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

Event 4: I looked at HyperLedger in more detail

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

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

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

Where is this heading?

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

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

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

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

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

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

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

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

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

Who do I trust

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

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

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

Identity and The Blockchain: Key Questions We Need to Solve

What are the architecturally-significant use-cases for identity?

Some of the most interesting uses for cryptocurrency technology in finance are securities processing, supply chain finance and derivatives operations.   These are areas where there should be almost total automation but there is, in reality, still large amounts of manual processing, rework, reconciliation, complexity and endless opportunity for confusion and dispute.

To help think about how blockchain technology could play a role, I suggested the “trust bundles” concept as a way to think about which aspects of a given business, such as securities exchange and settlement, could be moved onto a decentralized consensus system – and what benefits might accrue.

However, there’s a big problem that needs to be addressed before many of these opportunities become realistic. That problem is identity.  The anonymity (or pseudonymity) of Bitcoin may be great for some use-cases but it doesn’t help a firm accused of paying a “crypto dividend” to a terrorist if they have no way of proving they didn’t!

So let’s imagine we’re living in the future… Smart property technology means that securities can be issued and traded on a blockchain-like system and smart contract technology has allowed us to move all derivatives contracts onto a global platform.

What identity problems would we need to have solved for that future to come true?

Smart Property Issuance

Imagine you’re an investor. You have a Smart Property wallet. Perhaps it contains multiple cryptocurrencies, some bank-issued fiat currencies and your equity portfolio, safely secured with a multi-signature scheme.

You decide you want to add some IBM stock to your portfolio. So you instruct your wallet to place an order on a decentralized equities exchange.

What do you place the order for?

What do you physically type into the user-interface to tell it you want IBM stock and not somebody else’s stock?

It would be nice if you could simply type “IBM”.

But how would that work? We’re in a decentralized world, remember. We’ve “unbundled trust”. So how should the wallet interpret “IBM”? Which asset on the decentralized ledger represents the “real” IBM?   A Namecoin-like system doesn’t help if a “cryptosquatter” took the IBM name before the real IBM did.

And, in any case, what do you mean by “IBM”?

Intuitively, you probably mean something like: “The big American IT company based in Armonk, New York that had 2014 revenues of about $100bn and is a component of the Dow”.   Or something like that. But how to capture that intuition in a way that a decentralized network can interpret?

And how to distinguish the security you want from something similar (and legitimate) issued by somebody else? And, of course, how to distinguish it from a security issued by a fraudulent third party who is trying really hard to fool you into buying their product?

Identity 1

In a pseudonymous world, how do I distinguish “real” blockchain assets from scams?

One really unimaginative way would be to do what we do today: just decide to trust somebody to do the mapping for you.   Tell your wallet that you trust Bloomberg or Markit, say, to maintain a directory and you’re done. This would be an oracle service, in effect.

But this is a new point of centralization. Whoever controls that list can extract a rent and they are a source of risk: what happens if their database gets hacked or a rogue employee changes the records? Maybe having multiple oracles is the way forward.

Alternatively, perhaps we can use the internet X.509 Certificate system as a model. But even that would require some thought: you don’t want your webmaster issuing a $1bn bond!

What does it mean to be an issuer?

But we also need to think about it from the perspective of the issuer and this is altogether more difficult.  To keep things interesting, let’s use a currency example this time.

Imagine we’re still in the future and I am a customer of Citi with a $1M balance. I could ask Citi to issue a token on the blockchain representing this balance and send it to my wallet. My balance in my Citi account would be converted into ownership of a token representing $1M USD.      (I shouldn’t need to state it but I will:  I chose Citi purely as an example. I have no insight into their plans, if any, in this space!)

Identity 2

Richard is a Citi customer. Citi converts Richard’s balance into a “CitiUSD” token on a blockchain and sends it to Richard’s “1RICHRD” address

So I would now be a holder of a 1M CitiUSD token, owned by my “1RICHARD” address.  Note that this is essentially what happens when I use a gateway on the Ripple system but let’s assume we’re on a blockchain system for now to keep things consistent.

Aside: imagine if all banks did this… we could have CitiUSD, ChaseUSD, BarclaysGBP all issued on the same platform. Perhaps they’d trade at different prices based on market perception of their credit-worthiness? Prices as a function of CDS spreads perhaps?

Now, Citi would know exactly who I was: I was already a customer, remember, and they needed to know my blockchain address to issue the token to me.

But think about what happens next. I now have full control of this token.

So I could send it to anybody else in the world. And that person would now own a token representing a claim of $1M against Citi. Let’s imagine I bought a house from Charlie and paid using my CitiUSD tokens, sending them to his blockchain address, 1CHRLIE

Identity 3

I “pay” Charlie with my CitiUSD tokens. So Charlie now owns the claim on Citi. But Citi had no part in this transaction…

What would Citi think about this?   Who is “1CHRLIE”?? Are they already a customer? If not, how do they know if “1CHRLIE” is a “good guy” or not? Is Citi obliged to pay $1M upon presentation of the token?

More trickily, what happens if the token has passed through the hands of a “bad guy” at some point between issuance and redemption?   Sure – the initial owner of the token might be OK – and the person presenting the token some time later for redemption might also be OK. Perhaps we do know that 1CHRLIE is Charlie and that Charlie is a Chase customer and we’ve doubled checked with Chase. But do we need to know who has held the token in the intervening steps?

Identity 4

Do we need to know the identities of everybody who has ever owned a token?

What if one of the intermediate owners was 1TRRST, aka “Terry the Terrorist”?

You can be pretty sure we do need to know something about them.    Good luck if you try to tell your regulator that these tokens are “bearer assets” that are morally equivalent to cash!

So, leaving aside the possibility that we just don’t go down this road at all, what are some of the options for making this work?

I think there are two broad options:

Option 1: Ex-Ante Prevention – The Issuing Bank “Co-Signs”

This option is pretty simple. You change the model so that these assets are not bearer assets. Holders of Citi tokens need to get Citi to co-sign any blockchain transactions that move the asset. So Citi gets the chance to vet the recipient and check they’re happy owing them money.   You can think of this as “ex ante prevention”.   It would work, of course, but it would heavily constrain the usefulness of such a system.

Option 2: Ex-Post Prevention – The Bank Won’t Pay Up Unless You’ve Behaved Yourself

This option is more interesting. You can send the token wherever you like, but if you want to redeem the token for real USD, the bank will ask you to prove that everybody who ever owned it was a “good guy”. If you can’t prove a clean ownership history then the token is worthless; the bank won’t pay up.

Leaving aside the question of what we mean by “good guy” and the natural worry that this could give banks an excuse to renege on their commitments, how might you do it?

First, let’s cover off the obvious option.   The obvious option is simply to say: “We’ll only redeem a token if its ownership chain consists only of Citi customers”. Or perhaps you could extend it and say: “We’ll only redeem a token if its ownership chain consists of customers of the following banks”.   The latter approach might pave the way for an industry “register” that maps bank identifiers to blockchain addresses. Again, we’re back to centralization and the very real risk of a “balkanization” of the system: you would effectively have “white” addresses and “black” addresses – those that can hold banking-system assets and those that cannot.

If several of my readers are about to explode in outrage, bear with me because this isn’t what I’m proposing…. Happily, there could be another way.

“Identity is the New Money”

I was fortunate last week to attend Consult Hyperion’s “Digital Identity” unconference at Barclays Bank’s “Escalator” venue in East London.   Our host, Dave Birch, encouraged the audience to really exert themselves to think deeply about questions of digital identity. It gave me the motivation I needed finally to read his book, “Identity is the New Money”. I recommend it. It’s short, snappily written and made me think.

One of his key themes is that we’re thinking about identity all wrong. Most of the time we think we need to know who somebody is, what we actually need to know is something about them:

  • A bartender doesn’t need to know your name; they just need proof you’re over 18.
  • A UK doctor doesn’t need to know what town you were born in to know if you’re entitled to free healthcare.
  • … and so on

Similarly, and at a very conceptual level(!), what an issuer of USD tokens on a blockchain needs to know is probably something like:

  • The actor who controls an address is a legal person…
  • … and this person has a US bank account…
  • … and somebody has studied this person’s identification documents closely and has no concerns about them…
  • … and whoever is making these statements about them is trusted by the issuer of the tokens (say Citi)

Now, I say “conceptual”, because AML, KYC and CDD regulators might not see things this way yet but let’s keep going…

What these concepts all have in common is that they have this idea of a “certifier” – somebody or something that:

  • Is trusted by the issuer
  • Ties something I have (my face or my blockchain address) to something I am (“over 18”, “a holder of a US bank account”, etc)

If you trust the certifier then you can trust that somebody proving ownership of the face or the address is over 18 and a holder of a US bank account, etc.

What does a bank need in order to be satisfied?

So now let’s return to our currency example.   Remember the problem we’re trying to solve: If I am Citi, I want to be sure that anybody who has ever held one of my tokens is somebody I am allowed to transact with.

So how could we achieve this without a centralized database? Well, imagine Charlie is a customer of Chase.

  • Let’s assume Chase knows who Charlie is and is satisfied that Charlie is a good guy.
  • So if Charlie can prove to them that he controls a particular blockchain address, they might be willing to issue him with a “certificate”
  • This certificate might say: “I am Chase. Here’s my proof. I know who is the owner of address 1CHRLIE…. That person is a US Citizen and, as of 3 December 2014 was a retail customer, with a good account history and no warning signs on his account”

And perhaps I could get a certificate from Citi that says they think I’m a “good egg” and one from the UK government confirming I’m a UK citizen:

Identity 5

Could asset issuers use certificates from third parties they trust to satisfy their regulatory and other “client due diligence” requirements?

So now we have something really interesting.

An issuer can set down their conditions when they issue the asset.  They could say something like: “I will redeem this asset at par if the redeemer can prove that they and every intermediate owner was a US citizen with a KYCd US bank account. I will accept proof from any FDIC insured bank”.

So if I was considering buying a CitiUSD token from somebody, I no longer care who they are. I just care that they possess one or more certificates that comply with the conditions that were specified in the definition of the asset. My wallet software could even check it automatically for me.

And when somebody wants to redeem the token, they simply return it to Citi, with the chain of certificates and Citi can immediately tell that the token has only been in the hands of people with the attributes it specified.   No need to reveal my identity to anybody and no central third parties we need to trust.  If somebody does need to figure out the identity, they can get a court order and the certifier will reveal it.

Reality is more complex. In particular, how to stop a black market in certificates? e.g. a “mule” obtains a certificate for a blockchain address and then turns over the certificate and the address’s private key to a bad person. A difficult problem to solve but probably not unsurmountable.

But the underlying principle is absolutely crucial: if we’re moving to a world where trust is unbundled and control is decentralized, we need to rethink identity. Anchoring it in a diverse set of “certifiers”, who attest to the linkage between something I have (a blockchain address? My face?) and something I am (British, Over 18) surely has to be the way forward.

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

A simple explanation of Bitcoin “Sidechains”

Could sidechains be the enabler of “semi-decentralised” Bitcoin products and services?

An important paper was published this week:

Sidechains

If you’ve followed Bitcoin for any time, you’ll know this is a seriously eminent group of authors

It describes a way to build “pegged sidechains”. Sidechains themselves are not new – the idea, and how to build them, has been discussed for some time and the key breakthrough was outlined earlier in the year. But this paper gives more detail on the concept and has attracted a lot of comment.

But what are they? And why should anybody care?

A mental model for Bitcoin

The key to understanding most innovations in the Bitcoin space is to make sure you have the right mental model for how Bitcoin itself works. It turns out that most people I speak to don’t really understand how it works and, as a result, have a faulty mental model.

To help with this, I came up with an analogy for Bitcoin earlier in the year, based on thinking of Bitcoin “unspent transaction outputs” as parcels of land. Some people hated the analogy but I still think it has value :)

But in this piece, I’ll skip the analogy and net it down to the basics.

First, clear your head of anything related to money, currency or payments. And clear your head of the word ledger, too. The mind-bending secret of Bitcoin is that there actually isn’t a ledger! The only data structures that matter are transactions and blocks of transactions. And it’s important to get this clear in your head if sidechains are going to make sense.

When you “move” Bitcoins, what you’re saying is:

  • Hello everybody… I’d like to move these specific Bitcoins, please.
  • Here is the proof that I am entitled to move them
  • And here is how the recipient will, in turn, prove that they are entitled to move them.

three pictures

The critical three parts of a Bitcoin transaction

There are several important points here:

  1. Bitcoins are not perfectly fungible… when you move (or spend) them, you’re spending some specific bitcoins
  2. In order to spend them, you have to prove you’re entitled to do so. And you do that by providing the solution to a challenge that was laid down when they were sent to you in the first place. This challenge is usually just: “prove to the world that you know the public key that corresponds to a particular Bitcoin address and are in possession of the corresponding private key”. But it can be more sophisticated than that.
  3. When you send Bitcoins somewhere, you lay down the challenge for the next owner. Usually, you’ll simply specify that they need to know the public and private keypair that correspond to the Bitcoin address the coins were sent to. But it can be more complicated than that. In the general case, you don’t even know who the next owner is… it’s just whoever can satisfy the condition.

Keep saying the three steps to yourself until they’re etched on your memory!

Fine. So the “grammar” of a Bitcoin transaction is clear:   “Here are the coins I want to move, here’s the proof I’m entitled to and here’s what the recipient must do, in turn, if they want to spend them”.

This transaction is published into the network, it will eventually find its way into a block and, after other blocks have been built on top, everybody can be pretty sure it won’t be reversed and the world moves on.   What more do you need?

The core Bitcoin “grammar” works just fine, mostly…

This three-part structure to a Bitcoin transaction works well and it turns out that you can do some really interesting things with it.   For example, you can use the “not-entirely fungible” feature to “tag” coins. This is the basis of the “Colored Coins” and “Smart Property” worlds.

But there are problems, such as:

Block interval

Bitcoin’s block interval is ten minutes so it takes about five ten minutes on average for a new transaction to find its way into a block, even if it pays a high fee. This is too slow for some people so they have experimented with alternative cryptocurrencies, based on the Bitcoin code-base, which employ quicker block intervals   [UPDATED 2014-10-27 to correct my embarrassing misunderstanding of mathematics…]

Transaction Structure

The “three-part” transaction structure is very general but it only allows you to transfer ownership of Bitcoins. Some people would like to transmit richer forms of information across these sorts of systems. For example, a decentralized exchange needs a way for participants to place orders. Projects such as Mastercoin, Counterparty, NXT and others either build layers on top of Bitcoin or use entirely different codebases to achieve their goals.

Transaction Transfer Conditions

I said above that you can build sophisticated rules into Bitcoin transactions to specify how ownership is proved. However, the Bitcoin scripting language is deliberately limited and many ideas in the Smart Contracts space are difficult or impossible to implement. So projects such as Ethereum are building an entirely new infrastructure to explore these ideas

One-size-fits-all security model

It doesn’t matter if you’re moving $1bn or 0.01c across the Bitcoin network, you get the same security guarantees.   And you pay for this in fees and time.   What if you were prepared to trade safety for speed?   Today, your only real option is to send the coins to a centralized wallet provider, whom you must trust not to lose or steal your coins. You can then do all the transactions you like on their books, with their other customers and you never need touch the Bitcoin blockchain. But now you lose all the benefits of a decentralized value-transfer network.

One-size fits all doesn’t help if the size doesn’t fit you!

Now, making experimental or rapid changes to Bitcoin is very risky and so change happens slowly. So if the one-size-fits-all architecture of Bitcoin doesn’t suit a particular use-case, you have a problem. You either have to use an entirely different cryptocurrency (or build one!). Or you have to use (or build) a centralized service, which brings new risks.

This is very inconvenient. It creates risk and fragmentation and slows the build-out of products, services and infrastructure.

Centralised Wallet Providers as a “poor-man’s sidechain”?

But there’s an interesting observation we can make. Think about what happens if you send Bitcoins to a centralized wallet such as circle.com for safekeeping.

  • You send your coins to a particular Bitcoin address
  • They appear inside your circle wallet and are out of your control on the blockchain.
  • At some point in the future, you might send your coins back out of your circle wallet to a Bitcoin address you own
  • You now have control of some coins on the Bitcoin blockchain again!

From the perspective of the Bitcoin network, Circle is a black box.   You had some coins… you sent them to a specific address…   some stuff happened that Bitcoin couldn’t see…. And at some point later, you had control of some coins again.   It’s as if those coins had been moved from Bitcoin to somewhere else and then back again.

Here’s the Sidechains insight

The key idea behind the sidechains concept is:

What if you could send Bitcoins not only to individuals, addresses and centralized services but to other blockchains?

Imagine there is a Bitcoin-like system out there that you’d like to use. Perhaps it’s litecoin or ethereum or perhaps it’s something brand new.   Maybe it has a faster block confirmation interval and a richer scripting language. It doesn’t matter.   The point is: you’d like to use it but would rather not have to go through the risk and effort of buying the native tokens for that platform. You have Bitcoins already. Why can’t you use them?

The sidechains ideas is this:

  • Send your Bitcoins to a specially formed Bitcoin address. The address is specially designed so that the coins will now be out of your control… and out of the control of anybody else either. They’re completely immobilized and can only be unlocked if somebody can prove they’re no longer being used elsewhere (I’ll explain what I mean by this in a minute).   In other words, you’ve used the core bitcoin transaction rules I described above to lay down a specific condition that the future owner – whoever it ends up being – needs to fulfil in order to take control
  • Once this immobilisation transaction is sufficiently confirmed, you send a message to the other blockchain – the one you were wanting to use. This message contains a proof that the coins were sent to that special address on the Bitcoin network, that they are therefore now immobilized and, crucially, that you were the one who did it
  • If the second blockchain has agreed to be a Bitcoin sidechain, it now does something really special… it creates the exact same number of tokens on its own network and gives you control of them.
  • So it’s as if your Bitcoins have been transferred to this second chain. And remember: they’re immobilized on the Bitcoin network… so we haven’t created or destroyed any…. Just “moved” them.
  • You can now transact with those coins on that second chain, under whatever rules that chain chooses to implement.
  • Perhaps blocks are created faster on that sidechain. Perhaps transaction scripts are “turing complete”. Perhaps you have to pay fees to incent those securing that sidechain. Who knows. The rules can be whatever those running that sidechain want them to be. The only rule that matters is that the sidechain agrees to follow the convention that if you can prove you put some Bitcoins out of reach on the Bitcoin network, the same number will pop into existence on the sidechain.
  • And now for the second clever part. The logic above is symmetric. So, at any point, whoever is holding these coins on the sidechain can send them back to the Bitcoin network by creating a special transaction on the sidechain that immobilises the bitcoins on the sidechain. They’ll disappear from the sidechain and become available again on the Bitcoin network, under the control of whoever last owned them on the sidechain.

sidehcains_ex

Sidechains use the standard bitcoin “three-step” transaction to immobilise bitcoins whilst they’re “on” the sidechain

So, to repeat, we’ve used standard Bitcoin transaction functionality to move coins out of reach and we then prove to a second, unrelated chain, that we’ve done this.  And when we’re done, whoever owns them on the sidechain can do the same thing and send them back to the bitcoin network.

So developers get the opportunity to experiment with different types of cryptocurrency rules without needing to create their own currency.

And it now becomes possible to do some very interesting things in the Bitcoin space.

Step back from the details for moment and consider what’s been described.  We now have a way to move coins from Bitcoin onto another platform (a sidechain) and move them back again.   That’s pretty much what we do when we move them to a wallet platform or an exchange.  The difference is that the “platform” they’ve been moved to is also a blockchain… so it has the possibility of decentralised security, visibility and to gain from other innovation in this space.

For example, one could imagine a sidechain that is “mined” only by one company. That would be identical to a single-company wallet, but with full visibility of transactions.

Going further, you could imagine a sidechain that is mined by 100 different companies in a loose federation. Not totally decentralized, but harder to censor or subvert than if it were just one.

And there are lots of other possibilities. The key is that you can build these experiments and products and services without also needing to create a new currency or fall back into the old centralised style.

So when I look at sidechains, I’m looking at them as an architecture for building semi-decentralised products and services for Bitcoin that were simply impossible before.

Now there are some serious issues with the scheme. Peter Todd has raised doubts about how secure it might be and it might require a one-off change to Bitcoin.

But it’s early days.  I’m looking forward to watching this space develop

Cryptocurrency products and services will determine adoption of the currency – not the other way round

The critics of Bitcoin-the-currency are right… but only in the sense that the motor-car was a poor imitation of a horse…

I had a light-bulb moment this week. It was triggered by a panel I sat on at Sibos, hosted by the wonderful Adam Shapiro from Promontory Financial Group.

My argument to the audience was the one I usually give: they should simply ignore the currency use-case: it’s the least interesting thing about Bitcoin. They should, instead, look at it as a platform for decentralized value-exchange and focus on the opportunities this enables.

Sibos TV

The panel discussion isn’t online but you can see us debate the issues on Sibos TV.

I then returned to the warm embrace of the Innotribe room and thought little more of it.

I thought little more, that is, until I returned home on Friday and went for a run. I took the opportunity to catch up with a few podcasts, one of which was Dave Birch’s interview with Jeffrey Robinson, author of BitCon. (Aside: everybody I know thinks I’m weird for listening to economics and FinTech podcasts when I run. I can’t be alone… surely?!)

It is fair to say that Jeffrey is not a fan of cryptocurrencies. And he makes some well-aimed shots at the heart of the “Bitcoin is a useful currency” argument in the podcast. For example, he points out that vanishingly few retailers actually accept it, despite the hype (they, instead, receive dollars from BitPay or Coinbase instead).

Now, one could take issue with Robinson’s arguments (he’s very confused on some technical aspects and the Boston Fed does see some evidence that consumers pay marginally less when using Bitcoin rather than payment cards).

But surely this is to miss the point. Whether or not cryptocurrencies are superior than today’s currencies for today’s payment problems isn’t really interesting.

It’s like saying that the automobile is a terrible way of pulling a plough.

Cryptocurrency technology will succeed only to the extent that it enables new products and services that were previously impossible or unimaginable.

And here’s the light-bulb moment: most of the really interesting use-cases turn out to need a payment mechanism – and having a currency and payment mechanism built into the platform turns out to be really, really useful.

Causation runs in the opposite direction to what everybody seems to think: it is new products and services that will drive adoption of the underlying currency. Not the other way around.

Two interesting viewpoints

Perhaps you think I’m setting up a strawman…? Happily, there have been two separate posts this weekend describing what some of these applications might be. So let’s check…

First, Chris Dixon offers some ideas for native Bitcoin apps. If I’m being critical, I thought they were somewhat pedestrian – they all seem to be answers to the question: “if Bitcoin the currency was widely deployed, what could you do with it?” – which I think is the wrong way to look at this. It has causation in the wrong direction.

But Adam Ludwin at Chain.com also blogged on this topic. And his argument is more compelling to me. He acknowledged that we really can’t anticipate where this will go – but he highlights ideas like smart assets and so forth as promising areas of research.

So can we flesh this out some more and identify additional examples?

When the audience takes photos and makes notes, you know they’re excited by the topic…

I hosted five startup CEOs on the Innotribe stage at Sibos on Monday and it’s interesting to me that the demo that created the most excitement was Yoni Assia’s demo of colored coins. He showed the (fake!) example of a large US bank issuing IBM stock on the blockchain so that it could be traded and transferred without the need for the plumbing we take for granted in the securities processing world. I think he used the CoinPrism platform. And it’s worth also checking out ChromaWallet.

coloredcoins

Using the Colored Coins concept to issue, track and transfer securities on a blockchain.

I spoke to various attendees over the following days and this topic clearly excited them. The demo had helped them move from an intellectual, but shallow, understanding of the concept to one that helped them envision a future where custodians, clearing houses, exchanges and brokers work in a completely different way. I’ve written about decentralized securities processing here and seeing it in a live demo made it real for people.

Now the interesting thing is: this use-case has nothing to do with currency. The Bitcoins are just being used as a transport layer. All the intelligence and disruptive power is at higher layers of the stack.

The key insight: what is the best payment mechanism for colored coins?

But now… ask yourself a question: imagine this platform gained adoption. In what currency – and using what mechanism – would participants pay each other?

Sure – you could use whatever you like. But the interesting thing is: if you paid in the native currency of the platform – Bitcoin in this case – some very special possibilities arise. For example, you can use the Bitcoin scripting system to make binding bids and offers without needing a central exchange. And you can achieve atomic swaps of currency for securities – delivery versus payment – without needing a custodian.

So suddenly, a “currency” which may indeed have limited utility for today’s developed markets for today’s problems suddenly becomes utterly superior for this new use-case of decentralized asset exchange.

Now, I should point out that not all of this infrastructure yet exists so I’d advise readers to read an interesting paper by Mark Friedenbach and Jorge Timón on how to modify the underlying Bitcoin system to support it. (My thanks to Ian Grigg for the pointer). In passing, I think these systems also need two other critical pieces of infrastructure:

  • An identity and reputation system: how do I know an issuer of IBM “stock” really is who they say they are? And how do I know they are authorized to make the statement? The complexity here goes beyond narrow concepts of corporate identity
  • What rules are needed to underpin this? Which legal precedents?

But I think it’s examples such as this will lead us to a world of 1) unanticipatable products and services, for which 2) the optimum payment mechanism is the native token of the platform.

To repeat: new apps will drive cryptocurrency usage… not the other way round.

So what are some other potential use-cases?

I’d classify the example above as Smart Property.   I think there are at least two others:

The Economy of Things

I wrote recently about the work we at IBM are doing around the economic model of the Internet of Things. The work is focused on the underlying architecture through which trillions of devices can discover, connect and collaborate. But what would happen if these “things” needed to transact with each other? Wouldn’t the most obvious payment vehicle to use be the native token for the platform? (Usual disclaimer: I raise this as an open question… it’s not a statement of direction or intent by IBM)

Indeed, one potential example of this has already been studied in Switzerland. A recent paper by Dominic Worner and Thomas von Bomhard examines “Exchanging Data for Cash with Bitcoin” – one could easily imagine “things” paying each other for access to trusted data feeds in other scenarios too.

Smart Contracts

Vitalik Buterin’s presentation on Ethereum was a highlight of the first day at Innotribe this week. And I thought his host, Dan Marovitz, showed excellent judgement in allowing him to talk at length and in significant technical depth about his vision. The audience of senior bankers seemed to be completely rapt.

etherscript

Using Ethereum in a world where the there’s been a breakdown in trust between children and the tooth-fairy

At the core of the Ethereum concept is the idea that real-world relationships and contracts can often be reduced to deterministic rules that can be executed by a neutral, unimpeachable platform. And these contracts often (not always) involve the exchange of economic value, usually in the form of the native currency of the platform.

Now… I have some reservations about Ethereum… it is so ambitious and so audacious that I worry that it might prove to be unbuildable – and I note that real-life isn’t always reducible to deterministic rules….   But, as Gavin Andresen has argued, it might be possible to achieve much of what Ethereum aims to do on top of the Bitcoin platform itself. At which point, the world of smart contracts would drive usage of Bitcoin-the-currency.

And I’m sure there are more…

So where next…?

It’s still early days, of course. But the lesson I learned this week was that we need to get away from the sterile “Bitcoin the currency” versus “Bitcoin the platform” debate. Instead, we should consider how one drives the other… and how it’s the platform that is likely to drive the currency, not the other way round.