In bits we trust(?)

The Ethereum DAO hack has rocked the Blockchain world in the last few days, calling into question the security of Ethereum (the #2 Blockchain technology after Bitcoin) and with it the notion of smart contracts in general. Technical details of the hack can be gleaned here and for some background you can check out the very (too?) slick DAO website here.

In short, the DAO was the most hyped application of Ethereum (which is still in beta, mind you) and which garnered ~$150 million worth in Ether in funding, and was touted to be the first example of a distributed organization governed by code rather than people. It got tons of press and that exposure makes this failure all the more embarrassing. The hack exploits a bug in the code of the DAO and has allowed the attacker to drain $50 million worth of Ether (Ethereum’s base currency) from the DAO. It’s worthwhile to note that the hack affects the DAO but not the underlying Ethereum Blockchain, which remains secure as far as we know.

Instead of dwelling on the DAO’s failure and the possibility of a fork to save the lost ether (lots of chatter and Schadenfreude on reddit on the topic right now), I’d like to take the opportunity to focus on some lessons we might learn and suggestions for moving forward.

Too smart for our own good

The idea of smart contracts sounds extremely appealing: contracts that trigger actions on their own when predetermined conditions are met and whose terms are as hard and concrete as computer code and published to the Blockchain for all the world to see. No more hiring expensive lawyers to debate what that comma means, no more getting papercuts flipping through 5 inches of riders and addenda, no more yelling on the phone arguing about whether or not certain criteria were met.

This is a romantic notion that appeals particularly to computer scientists, for we see the world through our computational lens and are inclined to view laws and contracts as nothing but programs written in fluffy natural language. Stripping away the fluff and crystallizing the underlying intent in code, removing all ambiguity, seems like the natural next step.

In reality, the fact is that crystallizing the intent of contracts and laws into code is extremely difficult. Even moderately complex contracts are difficult to formalize and that complexity opens the door to misimplementation.

One approach to dealing with this is by flipping the picture on its head: we can hold the code to be the contract, and hold that there are no guarantees except what the code provides for. This was the position of the people who created the DAO, at least before it was attacked. But that is a sandy foundation for a financial network: if we really believed that, then there has been no exploit, the DAO is functioning as it was intended to, and we should pat the lucky chap who now has $50 million extra worth of ether on his back. How many people could you convince to use a network with that philosophy?

Beyond malicious hacks, this position also means that contracts cannot be patched when bugs are discovered. After all, maybe the reason that I accepted a contract in the first place was because I had spotted a bug and intended to use it to my advantage. By patching the contract you’re changing our original agreement.

It seems therefore that we must separate the implementation of a contract as represented by code from the abstract content or meaning of the contract, and that the former can and should be adjusted to reflect the latter if any significant discrepancy arises.

Of course, the content/meaning of a contract is often not totally well-defined, which means we’re not completely escaping the world of natural language and human ambiguity. This seems unavoidable (especially given the next point about dealing with the real world), but even with this caveat smart contracts via the Blockchain retain some advantage: automatic execution, public auditability, and improved (if not always complete) precision.

Reality bites

A much more important problem is the fact that contracts live in an extremely complex and uncertain environment: the real world. If you’re a programmer, you know that writing programs for complex environments is much harder because the number of things that can go wrong grows dramatically. While we know we’re supposed to think about all the corner cases and figure out all the contingencies, the fact is that even in a relatively well-understood environment like a computer network we often forget or fail to add in all the error checking and handling that’s needed to make a system truly robust.

Now compare that with the chaotic mess that is the real world, where unexpected things happen regularly that you couldn’t hope to have accounted for in your contract: a hurricane might wipe out swaths of New York City, ISIS might attack Turkey, someone might discover the cure to AIDS, and so on. Crazy events happen and there will undoubtedly arise events that a codified contract was not intended to handle. This will lead to disputes about whether the contract is performing according to its original intent, and we quickly fall back into a world where everyone is calling their lawyer.

Contract stewards

With the above observations, one proposal I’d like to make is that we institutionalize the idea of a contract steward and make it recommended or even mandatory for all but the simplest smart contracts.

The steward’s responsibility is to intervene in the event of a bug being discovered or if an event arises that’s not covered by the original code of the smart contract. The actions that a steward can take may be restricted by the original smart contract (e.g. an expiration date after which the contract state is immutable even by the steward), but should be rather broad in order to be able to handle as large a range of contingencies as possible.

One key question is who should play the role of steward? This can and should be decided on a contract-by-contract basis. The creators of the contract can designate a steward that they all trust, whether it be a friend, a court, or a company set up for such purposes, similar to an escrow service.

We see that this is already happening in an ad hoc way in the DAO debacle: the Ethereum developers are proposing a fork precisely to prevent the ill-gotten ether from being spent, and are thus playing the role of steward in this crisis. While the Ethereum devs may be the natural party to appeal to in this case because of their prominence, it’s not really clear if they’re neutral (some are invested in the DAO) or suffer from other conflicts of interest.

If we could institutionalize a neutral 3rd party steward in contracts, we would have a systematic response to hacks and bugs and more importantly we may dissuade attackers from exploiting bugs because they know that their attack can be reversed.

Finally, this change is “easy to implement” in the sense that it does not require any technical changes to Ethereum itself. Rather, it requires only that new contracts be written to designate a steward and grant them the ability to intervene.

Some will cry that this is antithetical to the spirit of the Blockchain, and truly it is, if one insists that the Blockchain is about total and non-negotiable decentralization. But it seems like sacrificing this bit of ideological purity is worth it to escape the grip of immutable buggy contracts, which if allowed to persist will kill the appeal of smart contracts altogether.