A lot of ink was spilled discussing the bugs and vulnerabilities of The DAO -- an autonomous Ethereum script that came to control about $150m and lost it all to hackers, once black-, and once white-hatted. One of the key lessons to emerge from The DAO's breach was a call for an escape hatch. An escape hatch is simply a mechanism to stop the operation of a smart contract, perhaps revert it to a lower-level safety mode, when something nefarious seems to be taking place.
The problem with an escape hatch, though, is that it may seem to be at odds with the "autonomous" nature of smart contracts. Smart contracts are appealing for various reasons, not the least of which involve their deteministic predictability and certainty. A naively implemented escape hatch, then, seems at odds with these highly desirable properties. This post outlines a simple but effective escape hatch that is completely decentralized, and therefore, in line with the trust assumptions that power DAOs.
Technically, the simplest escape hatch could be implemented by having a cryptographic public key embedded in the contract, allowing only a person holding an appropriate secret key to activate the hatch and push the contract into "maintenance mode," from which it could be debugged and restarted, using the same key.
One step up from this kind of a single-person escape hatch would be a smart contract that implements a multisig or a shared secret key. These would allow k-out-of-n parties to override the operation of the main contract.
Both of these approaches are undesirable in a DAO, however, because the parties holding the keys present a point of weakness. They can intervene in the operation of the main DAO for their own gain; they may be coerced; and they might have their credentials stolen and abused. Further, as we found out in The DAO's aftermath, it is difficult to find people who might step up to hold such keys, as it might open them to legal liability for not stopping the operation of the main contract, should that contract violate some law in some jurisdiction.
Consequently, these kinds of hatches are unlikely to be a good fit for a DAO.
Yet a simple decentralized escape hatch (DEH) mechanism exists by which attacks of the kind that plagued The DAO could be stopped and reversed in a decentralized fashion.
A DEH comprises three components:
The implementation of the trigger, then, is the sticky point. There are two, mutually complementary, options:
Note that a DEH does not impact immutability or fungibility in any shape or form. The payments, once passed through the DEH, are final and immutable. The DEH simply adds a delay period during which the contract can stop an operation from taking place.
When does a transaction take place, then? A script with such a Decentralized Escape Hatch always waits for the predefined time before actually sending out money. Payments are tantamount to "side-effects" in traditional distributed systems -- they are buffered and staged for execution, but not made available to clients until they clear the DEH. Anyone who interacts with the script only considers its operations as done after the buffering period of 24 hours.
Can any participant stop the script? No. A crowd-sourced trigger will require a certain quorum to activate the escape hatch, for example 53% of its participants for The DAO, or perhaps a traditional supermajority like 2/3rds, a simple majority at 1/2, or any other fraction deemed suitable for the application at hand.
As the Dapp ecosystem expands, and perhaps through costly trial-and-error, we will undoubtedly discover many useful building blocks for smart contracts. One such general, and exceedingly useful, construct is a Decentralized Escape Hatch (DEH). DEHs are a generalization of the elegant Vault solution (also, here) we have previously built to deter private key thefts in Bitcoin. We hope that they will be used where appropriate in smart contracts.