Smart-Contract Escape Hatches: The Dao of The DAO

Preventing Another The DAO Requires Not Just Prevention, But Also a Way Out

Even if these precautions are taken, though, oversights tantamount to those in The DAO will inevitably occur in smart contracts. It’s nearly impossible to avoid errors or unforeseen exploits in an environment as intricate and dynamic a smart contract system like Ethereum. The technical solutions above would not have thwarted, for example, the game-theoretic and application-design problems in the DAO moratorium proposal of Gun, Vlad Zamfir, and Dino Mark, including the stalking attack that the heist perpetrator performed. Modeling errors, complex contract interdependencies, and many other issues could similarly result in contracts failing to reflect the intentions of their creators.

So the best response to The DAO is, well, somewhat Daoist: chaos will always exist. Rather than deny it, let’s embrace it with smart contract design approaches that accept this inevitability.

A key way to do so is to include “escape hatches” —i.e., clean paths for modifying and undoing contracts in light of unforeseen eventualities (something the DAO lacked entirely). It’s something I’ve been pushing for as far back as October at DEVCON1 (when Slock.it was still known mostly for producing a door lock), reiterated during a talk at the IC3 retreat in May, and also advocate in a paper, co-written with Ari Juels, that I will present July 9 at RuleML 2016.

Escape Hatches Can and Should Draw from Contract Law

The good news is that, in creating escape hatches for smart contracts, we needn’t start from scratch. In the real world, contracts already include escape hatches of a kind, embodied in a rich existing body of contract law. Over the years, the legal community has defined and refined a spectrum of remedies for errors and unforeseen eventualities in conventional contracts (e.g., modification, reformation, termination, and rescission). We can translate these into similar tools for smart contracts.

In the wake of The DAO exploit, the most immediate lesson contract law offers about escape hatches is simply that they should exist. Right now, in the smart contract world, they generally don’t. In contract law, though, they have as far back as the Roman Republic, when actio redhibitoria (rescission and restitution) —i.e., undoing a contract and restoring each party to their pre-contract standing— was one of the chief remedies available if someone sold you bad fruit at the market.

Of course, contracts at law have the advantage of post-agreement malleability. Smart contracts don’t. This means that implementing smart-contract escape hatches requires greater prescience from contract creators, library, platform, and language designers, and/or Ethereum developers.

How Escape Clauses Might Have Saved Some Folks $53M

The problem function in DAO.sol was splitDAO, which is vulnerable to a recursive send pattern. As Phil Daian explained, though, the send pattern requires multiple calls of splitDAO by the attacker. Had there been an escape hatch in-place that disabled splitDAO or swapped it out for a better implementation, the draining of The DAO could have been stopped soon after it was noticed.

Disabling splitDAO is the worse option here because it means permanently crippling The DAO’s functionality. That said, a disablement mechanism would have been easy to build (though it would have to have been built long ago). Simply conditioning splitDAO’s innards on a boolean that could be toggled by, for example, community quorum, The DAO’s Curators, or Ethereum’s overseers would do the job. It’s not very nuanced. But these sort of escape hatches might be an appropriate fix for other noxious contracts that simply need to be stopped and not delicately unwound like The DAO. Thus, they should be a more widespread fixture in contracts.

Swapping out splitDAO for a version of itself without the flaw is better than wholly disabling it, since The DAO could continue. And there are ways this could have been enabled. For example, the splitDAO function —or for that matter, any of DAO.sol’s functions— could have been put into separate satellite contracts. DAO.sol would then get pointer functions that call these satellite contracts’ functions externally using addresses and ABIs that are captured in easily-swappable string variables. If a satellite function has a problem, simply create a new one and swap the pointer in the main contract. Easy. (Naturally don’t want everyone having the power to change the pointers, so you’ll have to limit access to the functions that do the variable swapping.)

This last approach is, I believe, actually the contract modification route hinted at by Vitalik in the White Paper. If we build contracts that are modifiable in this way, we move towards a world where smart contracts can nimbly respond to bugs and other unforeseen circumstances. Further, if protections are built into the functions that initiate the swap (e.g., having all parties approve and maybe only if certain conditions are satisfied), this flexibility can be circumscribed such that it doesn’t realistically threaten the immutability of smart contracts (which, of course, forms their core appeal).

How Escape Hatches Can Reverse —and Not Just Curb— Damage

The above are just a few examples of the most naive escape hatches currently available to all. In reality, contract law escape hatches are quite nuanced and many of their gossamer details would serve us well now, too. Contract law rescission, for example, calls not just for a contract to be undone, but for the parties to be made whole, with any partial performance being unwound. Some have hoped for the same with The DAO and, in an ideal world, smart contract escape hatches will handle this task, too —maybe even automatically (keeping with the promise to reduce intervention by courts or their look-alikes).

Imagine, for example, that The DAO payouts had spent some quarantine time in temporary escrows that, upon a cancellation of The DAO, were automatically harvested and used to repay all investors in a proportional way. If a nuanced mechanism like this had been in place, we might now be debating the option of cancelling The DAO, instantly refunding its investors, and starting from scratch with a new, error-free clone contract tomorrow.

Who would control such a cancellation? Contract law is very strict —but also very transparent— about who has the right to alter and undo contracts (basically, just the parties and courts). And we could be, too, crafting a protocol that only lets parties, unanimously, or a “trusted authority” like the Ethereum founders pull the cancellation trigger. Some may argue that the latter path undermines the distributed nature of blockchain. But, in that case, so did the Curator-driven structure of The Dao. And so does asking the founders to make a centralized decision to fork Ethereum in response to its exploit. The fact is, custodial models —and, even better, mixed models that fuse custodial control with consensus—are already out there. With blockchain architecture already providing additional accountability of custodians, we shouldn’t feel shy about exploring these models for escape hatches.

Final Thoughts

To conclude, we need more research on how to create nuanced and robust escape hatches. And we need more engineers in the field creating and testing them.

Ethereum’s stewards may also spend some time thinking about global escape hatches —like a global selfdestruct for removing toxic contracts from the blockchain (regardless of whether the code includes the function) or like forcing boilerplate escape hatch code, that lets a contract be cancelled with the consent of all contracting parties, on all contracts. I’ve seen some ideas proposed this week that are not too far afield (like this contract “failsafe” mode proposal by Dr. Christian Reitwiessner).

On the micro level, there is value to standardizing escape hatch code and open sourcing it for use in all contracts. This will not only make escape hatches reusable but will let us subject them to even greater scrutiny than we ought to subject our contracts (which are often one-offs) to going forward. Naturally, in designing them, we need to employ the same good engineering practices I shouted-out at the start of this column: formal verification, careful modelling, good minimizing size of the code base in order to concentrate scrutiny, and offering bug bounties (if anything, The DAO, if we simply see it as an enormous bug bounty, seems to have proven their worth).

If these sorts of practices and more brainpower had been dedicated to escape hatches months ago, we could be patting ourselves on the back right now for how quickly we swapped out splitDAO or how quickly we terminated The DAO and returned its investors’ ether, rather than contemplating IRL litigation to sort out the mess. (Unfortunately, the idea that smart contracts will totally erase the need for court intervention has also been exposed as farcical the last few days...with even the alleged hacker of The DAO threatening lawsuits.)

Basically, it’s too late to do much about escape hatches in The DAO. But it’s not too late to build them for the future and ward off —or, adopting the Daoist mindset, reduce the damage of— The DAO part Deux.

Bill Marino is a lawyer and computer scientist, researcher for IC3, and CEO of computer vision startup Uru.

• The soon-to-be published RuleML 2016 paper mentioned above is here.
• Thanks to Andrew Miller and Peter Vessenes for double checking some aspects of this post.