CITP Blog - Formerly Freedom to Tinker
Log in

Blockchain: What is it good for?

– by

Comments

,

Blockchain and cryptocurrencies are surrounded by world-historic levels of hype and snake oil. For people like me who take the old-fashioned view that technical claims should be backed by sound arguments and evidence, it’s easy to fall into the trap of concluding that there is no there there–and that blockchain and cryptocurrencies are fundamentally useless. This post is my attempt to argue that if we strip away the fluff, some valuable computer science ideas remain.

Let’s start by setting aside the currency part, for now, and focusing on blockchains. The core idea goes back to at least the 1990s: replicate a system’s state across a set of machines; use some kind of distributed consensus algorithm to agree on an append-only log of events that change the state; and use cryptographic hash-chaining to make the log tamper-evident. Much of the legitimate excitement about “blockchain” is driven by the use of this approach to enhance transparency and accountability, by making certain types of actions in a system visible. If an action is recorded in your blockchain, everyone can see it. If it is not in your blockchain, it is ignored as invalid.

An example of this basic approach is certificate transparency, in which certificate authorities (“CAs,” which vouch for digital certificates connecting a cryptographic key to the owner of a DNS name) must publish the certificates they issue on a public list, and systems refuse to accept certificates that are not on the list. This ensures that if a CA issues a certificate without permission from a name’s legitimate owner, the bogus certificate cannot be used without publishing it and thereby enabling the legitimate owner to raise an alarm, potentially leading to public consequences for the misbehaving CA.

In today’s world, with so much talk about the policy advantages of technological transparency, the use of blockchains for transparency can an important tool.

What about cryptocurrencies? There is a lot of debate about whether systems like Bitcoin are genuinely useful as a money transfer technology. Bitcoin has many limitations: transactions take a long time to confirm, and the mining-based consensus mechanism burns a lot of energy. Whether and how these limitations can be overcome is a subject of current research.

Cryptocurrencies are most useful when coupled with “smart contracts,” which allow parties to define the behavior of a virtual actor in code, and have the cryptocurrency’s consensus system enforce that the virtual actor behaves according to its code. The name “smart contract” is misleading, because these mechanisms differ significantly from legal contracts.  (A legal contract is an explicit agreement among an enumerated set of parties that constrains the behavior of those parties and is enforced by ex post remedies. A “smart contract” doesn’t require explicit agreement from parties, doesn’t enumerate participating parties, doesn’t constrain behavior of existing parties but instead creates a new virtual party whose behavior is constrained, and is enforced by ex ante prevention of deviations.) It is precisely these differences that make “smart contracts” useful.

From a computer science standpoint, what is exciting about “smart contracts” is that they let us make conditional payments an integral part of the toolbox for designing distributed protocols. A party can be required to escrow a deposit as a condition of participating in some process, and the return of that deposit, in part or in whole, can be conditioned on the party performing arbitrary required steps, as long as compliance can be checked by a computation.

Another way of viewing the value of “smart contracts” is by observing that we often define correctness for a new distributed protocol by postulating a hypothetical trusted third party who “referees” the protocol, and then proving some kind of equivalence between the new referee-free protocol we have designed and the notional refereed protocol. It sure would be nice if we could just turn the notional referee into a smart contract and let the consensus system enforce correctness.

But all of this requires a “smart contract” system that is efficient and scalable–otherwise the cost of using “smart contracts” will be excessive. Existing systems like Ethereum scale poorly. This too is a problem that will need to be overcome by new research. (Spoiler alert: We’ll be writing here about a research solution in the coming months.)

These are not the only things that blockchain and cryptocurrencies are good for. But I hope they are convincing examples. It’s sad that the hype and snake oil has gotten so extreme that it can be hard to see the benefits. The benefits do exist.

 

Comments

5 responses to “Blockchain: What is it good for?”

  1. J

    will you write the post about the sentence of the previous column : ‘we’ll dive into the question of how different AI tasks are connected, and how to think about the Singularity in a world where task-specific AI is all we have’?

    Reply
    1. Ed Felten

      I’m jumping directly to writing a paper about this topic. Stay tuned for a post here when the paper is ready for public release.

      Reply
  2. Nicholas Bohm

    If a bank is to have the right to debit a customer’s account with an amount determined by the running of code on specified inputs, there must be a contract that gives it that right. One might say that outside every smart contract there is a dumb contract giving it permission to run.

    This raises an important question about the allocation of risk. What if the smart contract produces a result that the bank or the customer believes is not what was intended? If the dumb contract prescribes the required outcomes, but the smart contract delivers something else, then the bank is still bound by the outcome prescribed by the dumb contract and must make it right – the bank carries the risk of divergence. But if the dumb contract simply says that the parties accept the outcomes of running the smart contract, then the smart contract rules, whatever the parties expected. So the parties to a smart contract need to be smart enough to understand what it will do in every relevant eventuality. That may prove a tall order.

    Reply
  3. Ed Felten

    Generally “smart contract” systems don’t allow one party to unilaterally take money from another party. Instead, a new virtual “party” is created who holds the relevant money and dispenses it according to rules. So rather than taking money out of your account, instead a “smart contract” would be created, you (having satisfied yourself that the “contract” was properly configured) would give some money to the “contract”, and the “contract” would later pay the money to the bank, or return the money to you, depending on whatever rules were in its code.

    On the risk allocation question, you’re right that there is a risk that the code of a “contract” will have a bug, in the sense that the code might do things that the parties relying on it did not intend it to do, due errors in writing and/or vetting the contract’s code. It’s often a good idea to have a legal contract in place to deal with these situations. A good analogy is to a vending machine. There is an implied contract that you will get a drink if and only if you put in a coin. If you put in a coin and the machine fails to dispense a drink due to some mechanical error, you are still entitled to get a drink or get your coin back, but you’ll have to go outside the machine itself to get that compensation.

    Reply
    1. Nicholas Bohm

      Thank you. I’m doubtful that the law has yet caught up with the concept of a virtual party as you describe it. It understands artificial parties, of course, corporations being an obvious example. But corporations (and other artificial persons) require formalities to create them. The consequences of introducing a party into a transaction where the law does not recognise it as having legal personality might be unpredictable. The law would probably regard its acts and property as belonging to the legal person or individual most closely connected with it. This might produce unwanted consequences. Your vending machine example is helpful: the law will regard the customer as having rights against the operator – it’s a good example of offer and acceptance through a machine. Nobody thinks the machine is a person known to the law.

      I suggest that this is a field, like signatures, where lawyers and computer scientists will need to listen to one another carefully.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Categories