Download all slides as a pdf.
Note: Due to time constraints on this 15 minute talk, I had to leave out pre-blockchain smart contracts, including work by Nick Szabo, Mark S. Miller, and Ian Grigg.
Transcript
It’s an honor to speak with you all. I’m Kate Sills. I’m a software engineer, and I’ve been in the blockchain industry since 2017. In other words, for the past seven or so years. I was the first hire at a company called Agoric where I built their smart contract framework, which is still used today.
I was asked to speak today on the topic of smart contracts. The problem in talking about smart contracts is that there are at least three different concepts that are being conflated when people speak of smart contracts. So I want to start by defining these concepts.
Ethereum Smart Contracts
Let’s start with how the Ethereum community defines smart contracts.
The 2014 Ethereum White Paper defines smart contracts as “systems which automatically move digital assets according to arbitrary pre-specified rules.” and gives the example of an account that has particular policies enforced in the code. For instance, person A can withdraw up to X currency units per day, but person B can withdraw up to Y per day.
Legal Contracts
In contrast, let’s look at the definition of legal contracts. I’m sure I don’t need to tell you this, but just for the sake of completeness, the Restatement of Contracts defines a contract as: “a promise or set of promises for the breach of which the law gives a remedy, or the performance of which the law in some way recognizes as a duty.”
Some people stop here, and they look at the examples of “smart contracts”, such as the account policy I just mentioned, and say, obviously smart contracts were just a terribly bad name, smart contracts have nothing to do with legal contracts, so let’s just rename smart contracts and move on.
These people are wrong. Ethereum smart contracts aren’t necessarily legal contracts, but they’re importantly related, and that’s what I’m going to be arguing today.
Computable Contracts
But first, let me add a third concept: computable contracts. Computable contracts are traditional legal contracts clearly specified enough to be written in code, and generally have nothing to do with blockchains. There are two main efforts that I’m aware of in computable contracts. The first is the CodeX Insurance Initiative at Stanford with Professor Oliver Goodenough and the second is Meng Weng Wong and Alexis Chun at the Centre for Computational Law at Singapore Management University.
Rule Ambiguity vs. Event Ambiguity
Before we move on, I want to point out something from computable contracts, which is that there are two kinds of ambiguity in contracts. Rule ambiguity is usually bad - that means we don’t know what the contract says should happen. Event ambiguity on the other hand can be good. It can be an beneficial shorthand, and sometimes it’s used to specify events that require human judgement to resolve.
Contract Law isn’t Just a Remedial Institution
Ok, so we’ve defined smart contracts, legal contracts, and computable contracts. I want to back up a bit and talk about the theory of contract law. Not the particulars of the current instantiation in the US, but the theory. Because I think this is where lawyers and people like myself start talking past each other.
In the paper Contracts Ex Machina, Professors Kevin Werbach and Nicholas Cornell state that “contract law is a remedial institution. Its aim is not to ensure performance ex ante, but to adjudicate the grievances that may arise ex post.”
While I believe this is an accurate description of what law students learn about contract law, I don’t think this is an accurate summary of the entirety of the institution of contracts. It’s just the part of the elephant that lawyers see day to day. To give an analogy, this is like having marriage counselors define marriage as the institution of arguing. There’s more to marriage than that, and the same is true of contracts.
Why do we use contracts?
So why do we use contracts? Here are some concepts from the subfield of law & economics. Again, I’m neither a lawyer nor an economist, so you may want to read the primary sources on these, but I think many of these points are self-evidently true.
So first, Yale Law Professor Anthony Kronman wrote one of my favorite papers of all time, where he talks about how people enforce agreements when there is no state enforcement and no legal remedy. He calls this state “transactional insecurity” - as Hobbes famously explained, in a transaction, whoever performs their share first leaves themselves vulnerable to misbehavior by the other party. In the paper, Kronman outlines 4 different mechanisms, one of which is collateral, which I’ll come back to.
The rest of these points I’ll have to leave for the discussion time, but I want to point out that the fact that unenforceable clauses are often included in contracts pretty directly indicates that they have some purpose other than legal remedy - since in that case there is no legal remedy. Interestingly, Professor Karen Levy makes this point as a critique of smart contracts, so we have two major critiques of smart contracts that contradict each other.
Transactional Insecurity Between Strangers over the Internet
So you might be wondering why I bring up this concept of transactional insecurity. I want to define a fourth concept related to smart contracts, legal contracts, and computable contracts: solutions (whatever they may be) to transactional insecurity, especially between strangers over the internet.
There are eight billion people in the world, and if we were to randomly choose someone to trade with, 96 times out of a hundred, that person would not be in the US. Historically, we haven’t worried about the risks of interacting with a person in the world, because we couldn’t reach them. Now, we potentially can. But yet, the chances of obtaining a legal remedy in a contract with a random person across the world are slim, especially if the amount at risk is small, and the cost of enforcement enormous.
This has resulted in three main outcomes: either we risk it anyways, or no interaction happens at all, or a private company takes on the burden of dispute resolution.
For instance, the website Fiverr has logo design services from people in Sri Lanka, India, the US, Pakistan, the UK – from all over the world. And as I’m sure you’re learning about in this class, they have their own enforcement mechanisms including in-house arbitration and reputation systems.
In many cases, this works great, but leaves both buyers and sellers at the mercy of the private company, and they may not be able to transfer their reputation to other platforms. And if the company disappears, so does their income. You’re also at the mercy of their platform and how they represent you.
What if we could bring these solutions out of the realm of private companies, and into the reach of everyone?
I want to make one last point on this - which is that I think people unfortunately very much discount the contributions of people in other areas and other countries. But I think nearly everyone has something to offer the world, and through better technology we start to see that. For instance, if Zoom didn’t exist, I wouldn’t be talking to you all now, because I’m on the west coast and you’re on the east coast. So there are these artificial barriers that prevent us from interacting with the large majority of people on the planet - but they are mostly things like language, location, difficulty of travel, lack of contract enforcement, lack of cultural understanding, and not intrinsic things like having nothing to offer each other.
Electronic Payment Systems
Let’s talk about blockchains and how smart contracts came to be. Bitcoin’s goal (now mostly forgotten in favor of speculation) was precisely to create an electronic payment system “allowing any two willing parties to transact directly with each other without the need for a trusted third party.”
In other words, it was to solve the problem of transactional insecurity. Pietro Ortolani has a very interesting paper in the Oxford Journal of Legal Studies, in which he highlights this idea. He says,
“Low-value electronic commerce transactions constitute a hostile environment for the traditional model… The costs and complexity of court enforcement proceedings are disproportionate to the values in dispute; From this point of view, mechanisms of self-enforcement can be seen an example of ‘legal Darwinism’: in order to survive in the environment of e-commerce, ODR systems must develop private mechanisms of enforcement which do not rely on any support from state courts and authorities.”
An Analogy for Bitcoin
To understand Bitcoin, let’s start with a bitcoin transaction. The most basic bitcoin transaction is just a statement saying I am sending money to a different account, and I will digitally sign this statement so that you know I authorized this transfer and not someone else. You can think of it a bit like signing a check.
There’s a lot to say about Bitcoin, but for our purposes, we can think of it as analogous to a public bulletin board that is append-only - transactions, like a paper check, are posted on it, but they can’t be changed or taken down. And if we sum up all the transactions, we can know how much each account has.
This is not particularly useful so far for solving transactional insecurity. We can digitally transfer money from one account to another, but payment is only one side of exchange, and we can’t enforce the promise of some future action. But Bitcoin has very basic “smart contracts” in the Ethereum sense!
Bitcoin Escrow
We can do simple escrow and dispute resolution just with Bitcoin, by using something called a 2 of 3 multisig. What this means is for the transaction to be valid, two of three predetermined parties must sign it.
Let’s take the Fiverr use case - let’s say I would like to pay someone in Pakistan to design a logo for me. So I prepare a transaction, but in this case, the transaction is only going to be valid if two of three people sign it.
In the most common case where everything goes well and I’m happy with the product and I am willing to pay, both the logo designer and I the buyer will sign the transaction, meeting the 2 of 3 threshold and sending the money to the logo designer immediately. But if something goes wrong, let’s say the logo designer never sends me the logo, or he sends me the logo and I wrongly refuse to pay, only one of us will sign, and we will need to bring in a predetermined arbitrator that we both agreed on, and they will add the second signature, either to pay the logo designer, or to give me my money back, as they decide. The important part is that the arbitrator never has control of the money and can’t ever steal it for themselves on their own.
Oracles
Bitcoin also introduced the concept of “oracles”. In the process of verifying a transaction, we can’t query anything, we can’t poll external servers. But, just as in the escrow example, we can have outside parties be required to sign transactions. So for instance, if I want to promise my money to my grandson after my death, I can require that bitcoin only be released if a third party says I’ve died, and thus signs the transaction. The third party could be a person using their judgment, or it could be a computer running code. We could also require k of n oracles to agree before the funds are released. Importantly, just as in the escrow example, the outside party doesn’t get any access to the funds themselves. They don’t get to set themselves as the recipient.
So let’s define an oracle as a third party entity that provides information about the outside world to blockchain code.
Ethereum
Ethereum came about when people started realizing that they wanted to track the transfer of more than bitcoin. First they started tagging certain bitcoin transactions as having specific meaning, this was called colored coins. This particular amount of bitcoin traced back should be seen as the transfer of property title. That was awkward, so Vitalik Buterin and others came up with the idea of providing a way to do more than basic computation. Instead of very basic things like Bitcoin Script, you could run code that was more like a regular programming language. You could start your own cryptocurrency just by writing some code that keeps track of account balances and transfers, and then adding that to the blockchain so that other people run it.
Ethereum’s Most Novel Feature: Escrow Without Opportunism
Importantly, you can transfer cryptocurrency of many kinds to code itself - not just an account controlled by a person. And that code could decide when the cryptocurrency would be released.
So Ethereum gave us something very important, a form of escrow in which code “owns” the digital assets until the code itself transfers the digital assets to someone else.
I just want to point out that this is entirely novel - as Anthony Kronman points out in his paper, whoever holds the collateral could potentially sell it, so it creates an opportunity for bargaining that causes problems in the trade:
By giving me collateral that is equal in value to the performance I have been promised, you create an opportunity for bargaining that I can exploit, if I am skillful enough, to appropriate the gain you expected to realize from our transaction” – Anthony Kronman, Contract Law and the State of Nature
Example of Escrow without Opportunism
Let me give an example. The Maker Protocol on Ethereum creates a cryptocurrency called Dai that is stable to the US Dollar.
So unlike the Argentine Peso
Or Bitcoin itself, which are both terrible as a unit of account, the kind of money that you might specify in a contract,
Dai has been surprisingly stable. If you look at the right hand side, the fluctuations are incredible small compared to Bitcoin and many world currencies. That dip there was when Silvergate and Silicon Valley Bank started having serious issues - and DAI recovered. I don’t own any DAI or any Bitcoin, for the record. I’m just impressed.
How the Maker Protocol Works
The Maker protocol is able to achieve this with smart contracts and price oracles. Users create smart contracts called vaults that they deposit their collateral into. Then they get the stablecoin DAI in return, and if the price of the collateral drops so that they are under-collateralized, they will be asked to add more. Or, their collateral will be sold to the public to pay off the debt. In essence, this is a collateralized loan with a stable currency with no one able to steal the collateral.
Digital Assets on a Blockchain: Intrinsic Value vs Representative/Referential Value
I want to get into the Q&A, but one additional concept I want to add here. When we speak of digital assets defined on a blockchain, we might be talking about two very different things. The first category is assets that have intrinsic value. Bitcoin’s value is self-referential. The second category is representative or referential to something in the real world, for instance a shipment of coffee. If the blockchain records aren’t updated at the same time that the coffee moves through the supply-chain, the information is going to be inaccurate.
False Dichotomies
Lastly, to conclude, I think there are false dichotomies everywhere in the smart contracts discussion. The issue is not that we have to pick between blockchain code or legal contracts with legal remedies in US courts. The issue is not that we have to choose between 100% immutable machine executed code and 100% human discretion. We have a variety of tools here, which include code running on a single person’s computer, code running on blockchains, amateur individual human arbitrators, expert and well-designed arbitration systems.
Thanks
Thanks so much again for the opportunity, I’d love to take your questions and continue the discussion
Have questions or comments on this presentation? Email Kate at katelynsills@gmail.com.