Tag Archives: smart contracts

Standard

Posted by

Posted on

March 30, 2015

Posted under

Bitcoin, Ripple, smart contracts

Comments

19 Comments

Bitcoin as a Smart Contract Platform

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

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

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

Bitcoin-like and Ripple-like systems

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

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

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

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

Incrementalism versus “Disruption”

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

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

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

Bitcoin as a currency might be to miss the point

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

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

Bitcoin is a smart contract platform

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

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

BitcoinSmCon4

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

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

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

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

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

BitcoinSmCon2

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

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

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

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

Why is it this complex?

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

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

BitcoinSmCon3

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

Smart Contracts?

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

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

So what?

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

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

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

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

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

Standard

Posted by

Posted on

March 5, 2015

Posted under

distributed ledgers, fedcoin, Ripple, smart contracts

Comments

28 Comments

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

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

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

FedCoin

Andolfatto’s FedCoin post

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

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

  • First, FedCoin would be issued by the central bank. That contrasts with most other digital cash systems, where the holder has a claim against a telecoms firm or a commercial bank. In those systems, you have to trust the central bank not to inflate away the currency (as you do here) but you also have to trust the commercial issuer not to go bust – or any deposit insurance scheme to bail you out if they do. A central bank digital asset doesn’t have that second issue.
  • Secondly, Aldolfatto suggests this currency could be issued on a distributed ledger. As he writes in an update to that post, many people have questioned why that might be necessary. Surely if you trust the fed enough to hold its currency, you trust it to run an accounting system!   However, I wouldn’t dismiss this suggestion just yet, as I’ll argue below.

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

So why am I writing about it now?

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

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

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

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

Bank of England

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

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

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

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

Central Bank Money for all

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

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

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

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

A solution looking for a problem?

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

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

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

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

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

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

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

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

But what does matter is the payment.

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

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

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

Too many issuers

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

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

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

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

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

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

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

But time will tell, as always.

Standard

Posted by

Posted on

February 10, 2015

Posted under

ledgers, smart contracts

Comments

35 Comments

A Simple Model for Smart Contracts

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

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

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

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…

Standard

Posted by

Posted on

December 3, 2014

Posted under

Bitcoin, identity

Comments

24 Comments

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.