by David Gerard
Dr. Strangelove is the best-known story of an unstoppable smart contract going wrong, immune to human intervention. The US has sent nuclear bombers to the Soviet Union that can only be recalled with a code that nobody has; if any bombs hit, these will trigger the Soviet Union’s deterrent, an unstoppable doomsday device that cannot be dismantled or disarmed, and will explode on any attempt to. The real-life version’s consequences are not as drastic, but the misguided thinking is the same.
Fortunately, most of the worst real-world smart contract proposals are infeasible; what they’re actually used for is “honest Ponzis” and ICO tokens.
So who wants smart contracts, anyway?
There are five groups of people who want smart contracts:
Computer programmers who don’t have an aptitude for social or legal conventions, but do have an aptitude for programming, so they’d like social and legal conventions to work a bit more like that.
Anarcho-capitalists who want to replace the government with a small DOS batch file. (Particularly ones who are also in the first group.)
Businesses who want to automate away dealing with customers, but still take their money.
People selling you flim-flam with a thin veneer of technology on top, who have, as we’ve noted, found rich pickings in smart contracts for ICOs.
Innovative entrepreneurs who have come into conflict with the traditional legal system previously, and would like something deterministic enough that they can take your money and escape through the cracks. (See also group 4.)
Legal code is not computer code
Szabo is a computer scientist who has studied law, and has advocated a role for smart contracts in public law, with due caution.330 However, others want to take the idea much further.
Some advocates speak of replacing lawyers and judges with computer code,331 as if this is an obviously good idea; there are even anarcho-capitalists who seriously posit replacing most functions of government with a computer program.332 Others speak of completely autonomous corporate entities, doing deals with real money and goods without even the possibility of outside interference.333
Computer programmers work in an area where everything can be determined cleanly and clearly, if only in principle. So using computers to sort out all those annoying grey areas in human interaction is tempting: if you don’t understand law (which involves intent) but you do understand code (which does precisely what you tell it – though maybe not precisely what you meant), then you may try to work around law using code.
The trouble is that this conception of smart contracts is based on a severely limited understanding of how contracts, the law and social agreements work. It concentrates on a technical form that can be put into computer code. It doesn’t address the social meaning of what a “contract” is, the changeable contexts real-world contracts operate in, how they’re fulfilled in practice – or how you fix them when things go wrong.
With conventional contracts, if there isn’t a reasonable human at the wheel, you can in fact go to court. Not all contracts are legally enforceable. In the worst case, a government can pass new law making a severely problematic variety of clause unenforceable.
Smart contracts work on the wrong level: they run on facts and not on human intent – but legal contracts are a codification of human intent. Human intent is inexact, but contracts assume they will be running on human minds in the context of human institutions, for human purposes.
A conventional contract, even one specified as precisely as possible, will have disputes and changes in circumstances, and resolving these will often involve ascertaining what people were thinking at the time and what the world outside the contract was doing. The purpose of law is not to achieve philosophical or mathematical truth, but to take a messy reality and achieve workable results that society can live with.
Even Vitalik Buterin has acknowledged that for smart contracts to work as advertised, we would need to create a human-equivalent artificial intelligence to understand what people meant the contract to do334 – what people were thinking at the time is a key issue in resolving many a contractual dispute. “Intent is fundamentally complex.”
The oracle problem: garbage in, garbage out
In software testing, an oracle is any mechanism that determines if a test has passed or failed. The oracle problem is how to do this without costly human intervention.
This usage was adopted for smart contracts, where the oracle problem is to determine whether a real-world condition in a smart contract has been met.
Unless you just want to shuffle tokens inside your smart contract platform, at some point you’re going to need to interact with the outside world. Your contract has to know if a shipment has not just been delivered but is what you ordered, or if a given piece of work has been done to a satisfactory standard. This will frequently involve unavoidable trust in human judgement.
And remember: garbage in means garbage out. You may set up incentives against false data – but what about accidental errors, or disputed data, or unavailable data? Or, as Matt Levine from Bloomberg points out: “My immutable unforgeable cryptographically secure blockchain record proving that I have 10,000 pounds of aluminum in a warehouse is not much use to a bank if I then smuggle the aluminum out of the warehouse through the back door.”335
Technology and business journalists writing about non-cryptocurrency use cases for smart contracts never seem to mention that their “trustless” system will still involve trusting humans wherever it touches the physical world. You may have a tamperproof system for running contract code, but the inputs have to come from outside this secure space.
A common proposal is to outsource your oracle to a prediction market – humans betting on predictions – that is also on your blockchain, such as Augur. Somehow, the outcome of a bet is supposed to substitute for direct knowledge of an event having happened or not, with sufficient confidence in the process to let it affect your money. If your question isn’t popular enough to attract sufficient uninvolved wagers – it would often be worth it for one party to just bribe the bettors – you will still have the oracle problem in determining whether the event has in fact occurred. You can’t get rid of the human element by adding another layer of indirection – it’s oracles all the way down.
(Augur has openly bragged that they think running on a blockchain means they can dodge US government regulation on gambling and derivatives, which led to the shutdown of previous prediction markets, despite being a single company with known principals.336)
Immutability: make your mistakes unfixable
The value proposition of “immutability” is that nobody can mess with your contract once it’s been deployed. The common pitch to musicians, for example, is that the big record label will have to pay you as it says in your contract, quickly and automatically.
But in practice, immunity to human interference is as serious a problem as Bitcoin transactions being irreversible. The standard example of a real-world smart contract is a car that stops working if your payment fails.337 Or its Internet connection fails. Or there’s a software bug. Unstoppably, immune to human intercession or changes in circumstances.
In the real world, circumstances change out from under you. How many musicians have been so pleased with the first contract they signed, and understood it themselves so well, that they’d never want one dot of it altered? Including by, say, later court proceedings.
The most famous attempt at an autonomous corporation immune to interference, The DAO, crashed and burned when it turned out to have a security hole that couldn’t be fixed in time and got hacked, as detailed later in this chapter.
The eventual fix for The DAO hack demonstrates the other problem with smart contracts: the “immutable” system containing the smart contract was suddenly considered changeable the moment the big boys risked losing enough money.
(Szabo’s original 1994 paper noted the need to allow human intervention, though by 2014 he was fully into smart contract
s on a blockchain with no human intervention possible.338 He didn’t offer any comment on the 2016 failure of The DAO.)
Immutability: the enemy of good software engineering
Smart contracts make no sense as software engineering. You need a perfect bug-free program – but humans are really bad at coding without error. Programming to this extreme quality level is done by organisations like NASA for spacecraft, and it’s hideously slow and expensive. (Everyday businesses would find a floor full of lawyers both cheaper and more effective.)
A much-touted advantage of smart contracts is that the code is public, so anyone can check and verify it before engaging with it. The problem is that it is extremely difficult to tell precisely what a program might possibly do without actually running it.339 Even if you do see any obvious (or exploitable) bugs, nobody can fix them once the contract’s been deployed – your bugs are immutable.
Then there’s the question of what’s an error and what’s deliberate. In the wider world of security programming, we have the Underhanded C Contest, a competition to write deceptive programs that look like they just have a bug: “you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should perform some specific underhanded task that will not be detected by examining the source code.”340 The Ethereum community is also running one for Solidity, to encourage security awareness.341 If you think people have trouble with loopholes and traps in conventional contracts …
Smart contracts rely on the program being perfect and not having any bugs. But they also rely on the language (e.g., Solidity in Ethereum) being perfect and not having any bugs. And the platform the language runs on (e.g., the Ethereum Virtual Machine) being perfect and not having any bugs. You can deploy fully-audited code that you’ve mathematically proven is correct – and then a bug in a lower layer means you have a security hole anyway. And this has already happened.342
Ethereum smart contracts in practice
If you suspect that spending crypto-currencies on virtual thrones for non-existent kingdoms is illegal in your jurisdiction, please avoid participating (and complain to your political representatives).
– chain-letter automatic Ponzi scheme “King of the Ether”343
For decades, smart contracts were just an interesting hypothetical. When blockchains came along, smart contract advocates were very interested in the blockchain’s immutability. There were some smart contract experiments on Bitcoin, but Ethereum was pretty much the first practical platform for writing and running computer programs on a blockchain.
Humans are bad at tasks requiring perfection. But when programming errors have drastic consequences, the usual approach is to make it harder to shoot yourself in the foot: functional programming languages, formal methods, mathematical verification of the code, don’t use a full computer language (avoid Turing completeness), and so on. Szabo wrote up some requirements and a simple example language in 2002.344
This is particularly important when you have multiple smart contracts interacting with each other – massively concurrent programming, with unknown possibly-hostile programs calling into functions of yours.
Ethereum ignores all of this. Its standard contract language, Solidity, is a procedural language based on the web programming language JavaScript – to make it as easy as possible for beginners to write their first smart contract. It contains many constructs that mislead programmers coming from JavaScript into shooting themselves in the foot.345 It is ill-suited and hazardous for concurrency (e.g., the Solarstorm vulnerability346), despite this being a specific intended use case.
There are endless guides to writing a secure smart contract for Ethereum, but most Ethereum contracts ignore them, with the obvious consequences.347
Smart contracts on Ethereum are worse than even non-financial commercial code; as of May 2016, Ethereum contracts averaged 100 obvious bugs (so obvious a machine could spot them) per 1000 lines of code.348 (For comparison, Microsoft code averages 15 obvious bugs per 1000 lines, NASA spacecraft code around 0 per 500,000 lines.)
Since cryptocurrency enthusiasts had already self-selected for gullibility, the very first smart contracts they wrote were chain letters, lotteries and automatic Ponzi schemes. These ably demonstrated the requirement for coding correctly, first time, every time:
The casino whose pseudorandom number generator had the random seed in the code, so anyone could recreate the precise sequence of random numbers.349
The GovernMental Ponzi was going to pay out 1100 ETH, but due to a coding error this required more gas than the maximum possible gas for a transaction. The ether is now stuck there forever.350
Many schemes which ran out of gas due to bugs, e.g., King of the Ether.351
Rubixi Ponzi: Errors in the code, copy-and-pasted from other contracts, allowed anyone to become the owner and take the money.352
A Ponzi which would pay out only to the creator of the scheme because of what looked to casual inspection of the code like a typo in a variable name.353 No doubt just an accident, I’m sure.
Automated Ponzi schemes are not nearly as fashionable in 2017; most of the effort goes into smart contracts for managing ICO tokens. However, as The DAO showed, the coding quality is as good as ever.
The DAO: the steadfast iron will of unstoppable code
You just learned chemistry and the first thing you built was a giant bomb and you can’t understand why it blew up in your face.
– brockchainbrockshize, /r/ethereum354
Not content with their existing sales of Internet fairy gold, some Ethereum developers at German blockchain startup Slock.it came up with an even more complicated scheme: The DAO – a Decentralized Autonomous Organization, with “The” as part of the name. This was a smart contract on Ethereum which would take people’s money and give it to projects voted on by the contributors as worth funding: a distributed venture capital firm.
The DAO’s Mission: To blaze a new path in business organization for the betterment of its members, existing simultaneously nowhere and everywhere and operating solely with the steadfast iron will of unstoppable code.355
Bold in original. I’m sure there are no obvious problems there that jump right out at you.
The DAO launched on 30 April 2016, got massive publicity and became the biggest crowdfunding in history up to that time, with over $150 million in ETH from 11,000 investors in DAO tokens. Fourteen per cent of all ether was in The DAO. It was the most prominent smart contract of all time, achieving considerable mainstream press coverage. It proceeded to illustrate just about every potential issue that has ever been raised with smart contracts.
The DAO’s legal footing was uncertain, and widely questioned. Selling tokens in The DAO closely resembled trading in unregistered securities – particularly when DAO tokens themselves hit cryptocurrency exchanges – and the SEC had come down on similar schemes in the past. There was no corporate entity, so it would default in most legal systems to being a general partnership, with the investors having unlimited personal liability, and the creators and the designated “curators” of the scheme likely also being liable.
Shortly before the go-live date, researchers flagged several mechanisms in the design of The DAO that would almost certainly lead to losses for investors, and called for a moratorium on The DAO until they could be fixed.356
Worse, on 9 June a bug was found in multiple smart contracts written in Solidity, including The DAO: if a balance function was called recursively in the right way, you could withdraw money repeatedly at no cost. “Your smart contract is probably vulnerable to being emptied if you keep track of any sort of user balances and were not very, very careful.”357 This was not technically a bug in Solidity, but the language design had made it fatally easy to leave yourself wide open.
The DAO principals decided to proceed anyway, Stephen Tual of Slock.it confidently declaring on 12 June “No DAO funds at risk follow
ing the Ethereum smart contract ‘recursive call’ bug discovery”358 … and on 17 June, a hacker used this recursive call bug to drain $50 million from The DAO. And nobody could stop this happening, because the smart contract code couldn’t be altered without two weeks’ consensus from participants. The price of ether promptly dropped from $21.50 to $15.
(Tual posted on 9 July a hopeful list of reasons why the attacker might give all the ether back, just like that. Because it would be in their rational self-interest.359 This didn’t happen, oddly enough.)
Ethereum Foundation principals discussed options including a soft fork or a hard fork of the code or even of the blockchain itself, or a rollback of the blockchain. The community wrangled with the philosophical issues: the whole point of smart contracts was that they couldn’t be fiddled with. This contract had been advertised as “the steadfast iron will of unstoppable code,” but it appeared only the hacker had read the contract’s fine print closely enough.360 Some seriously debated whether this should even be regarded as a “theft”, saying that code is law and intent doesn’t matter (unlike in real-world contracts operating in a legal system, or indeed in fraud law in general). Others argued that the market integrity of the Ethereum smart contract system required that incompetent contracts, which The DAO certainly was, had to be allowed to fail.