Real Talk About Ethereum

Turing completeness ain’t all it’s cracked up to be

Mandatory image of the Joker burning vast amounts of money…

Alan Turing was a genius and a hero and suffered immeasurably for who he was. He is known for many things, one of which is the concept of a Turing Machine. This hypothetical invention was the simplest computer you can possibly imagine: space to store information, and something that could read it, write to it, and perform operations based on what it’s there. It is the simplified model of every computer we have now.

Ethereum is often described as being “Turing complete”. This a powerful property… it lets you do “anything”. Power, meet responsibility.

Turing completeness on its own is only theoretically useful. Brainfuck is technically Turing complete, but nobody cares. It’s not the underlying Turing machine that matters. It’s the tools that allow you to communicate ideas and goals to it matter. Language and environment are everything.

Different languages have different failure modes. Some languages, like C, have great access to hardware, awkward syntax, and hard compilation constraints. Once compiled, C code can crash and is notoriously prone to buffer abuse vulnerabilities, but it’s also fast, and once it’s working, it’s reliable. Javascript, on the other hand, is more susceptible to runtime exceptions. Its common security vulnerabilities usually come from the browser interactions (as opposed to directly language-related), like cookie abuse, XSS, etc.

An all-too-common bug in Ethereum smart contracts is: “oops, someone stole your money”.

Solidity, the canonical language that compiles down to EVM bytecode, is a lovely language that borrows a lot of syntax and features from modern languages. It’s easy to read and learn. When I started researching this article, I was looking for a “smoking gun” — a language feature to blame for the hundreds of millions of dollars being stolen or frozen. It would have been so easy to say “avoid delegatecall, and you won’t get burned”. Sadly, this is not the case. Unfortunately, the tl;dr as far as I can tell is: “software is hard, financial software is really hard”.

I’m aware of three catastrophic bugs in Solidity code — the DAO hack and two vulnerabilities in the Parity multi-sig wallet software. We’ll cover each of them, they are each highly informative.

The DAO was vulnerable to a “recursive spend attack”. Essentially, you could clear it out if you repeatedly instructed it to send you “your” money. If you sent a command to remove money while it was trying to fulfill your previous command, it wouldn’t ever get to the part of the code that updated your balance… wups. You can read about the super-interesting details elsewhere. Because of the other structures of the DAO, your stolen proceeds had to sit, immobile, for about a month before you could cash in. During this window, Ethereum executed a hard fork, preventing the stolen ETH from being sold or transferred again. Without this security precaution in the DAO code, it would have been much harder to reverse this hack in a hard fork.

The first Parity vulnerability came from the fact that an initialization-only method was accidentally publicly available, and did not check to see if it was being called during initialization. This method set the list of owners, so you could tell any vulnerable wallet that you were its rightful owner in one call, and transfer the sum total out in the next function call. Gory details here. The second Parity vulnerability was that the core component that all other Parity wallets referenced could be killed by anyone, rendering all dependent wallets useless and frozen.

Both of the Parity bugs came in part from splitting functionality between a library and the actual wallet contract. My initial response was “why would you have complex modules in financial code”? The answer is simple — it’s cheaper that way. Big smart contracts are more expensive than small ones, and so people are financially incentivized to have smaller contracts.

A penny saved in gas is a gajillion dollars stolen, apparently.

But I don’t think it’s really fair to put it that way. I think everything can have growing pains. Really, the only thing that Ethereum can be faulted for is of getting too big too quickly… there is so much pressure to get things out the door that there just isn’t enough time to do things in a really careful, deliberate, and secure way.

All that being said, I think most of the “blockchain hype” is probably overblown. With upgradeable smart contracts (which are understandably the norm), you wind up having the same trust issues that you had with traditional server/client architectures. Does the given smart contract really benefit from being decentralized? If so, you simply have to put in the time to make it secure, on the first try, and not try to hedge your bets with “upgradeability”. If someone says “trust the code” and the code includes a little variable that points to “the real contract”, and that variable is editable by a specific individual… you’re asking me to trust that person, not the code!

Other than a few ERC20 tokens, and Ether itself, I haven’t run across any ideas that really benefit from being on the blockchain. Some of them are almost comically terrible, but most of them would work just fine on their own, private, tailored blockchains. Anybody trying to sell you on some on-chain Ethereum microtransaction token doesn’t understand (or is ignoring) gas mechanics. Transactions are cheap for now, but not free. Blockchain IoT is a joke — on-chain certification just isn’t worth it. Any time there is a trusted party (see: most upgradable smart contracts), you’re sunk — just run the code on their servers! Most of these trusted parties wind up running full Ethereum nodes instead, which are insanely more expensive than just regular-old web-app servers.

I hasten to add that I am not down on the ideas of “blockchain” in general! Blockchain thinking enables new, never-before-seen use cases. It’s just that most of the initial “it’s like Pinterest, but on the blockchain” ideas are just downright silly. There are clearly a lot of people hoping to hop on a fast-moving bandwagon, and a bunch of inexperienced newly-rich people, and gullible VCs who fall for the cryptographic word-salad. We’ve got a lot of early-phase fluff and garbage to get through before we earn the right to really transform our world. It’s hard to think of the great idea first! It helps to let a few (hundred) bad ideas fail in order to flesh out the underlying technology.

Honestly, it’s unclear to me that there is any real need for a widespread, global, Turing-complete blockchain (Ethereum). I don’t think that the world is ready for code-is-law, and it’s had enough of whatever-some-guy-says-is-law. Imagine a world where the DAO started as a private blockchain run by the developers who were starting it, it could still increase in value, and eventually “go public” when the founders stop having 51% of the stake (or hashpower). Why fork the entire universe in order to fix a problem with 15% of it? Why should the entire world confirm some transaction between my lightbulb and my neighbor’s photovoltaic array? I think the fundamental value proposition of Ethereum (to be a platform for build global, decentralized applications) is awesome in the weighty sense of the word. However, this platform is guaranteed to get more congested and expensive. It’s unclear to me that there’s a “scaling solution” — the whole point is to have global consensus, why invoke that when it’s not necessary?

Building on the lessons learned by Ethereum and Bitcoin, it should be possible to put the crucial features together, enable cross-chain communication and trading, and build out a system of compatible libraries and protocols that let people craft solutions to their specific problems. Bootstrapping things in an environment where billions of dollars are sloshing around seems reckless.

I’m always trying to learn, though, so if you know of an Ethereum project that leverages the insane power of the platform in a way that doesn’t rely on trusted parties, either in the code or implicitly, I’d love to hear about it!