A Decentralized Escape Hatch for DAOs

Naive Hatches

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.

A Better Hatch

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:

• A buffer: All money flows out of the main contract go through the DEH contract. The DEH buffers these money flows for a pre-determined and parameterized amount of time, say, 24 hours, before actually executing the send() call that transfers them to their ultimate destination. This delay provides an opportunity to review the operation of the main contract for errors.
• A trigger: A DEH implements a mechanism by which the money flows in its buffer can be reverted under precisely-specified conditions.
• An undo log: An associated, application-specific undo log optionally provides a mechanism by which the DEH can specify how to revert certain actions. The undo log can ensure, for instance, that if a transaction in the buffer is reversed, that the funds are sent back to the clients who initiated them, making them whole, instead of unilaterally usurped.

The implementation of the trigger, then, is the sticky point. There are two, mutually complementary, options:

1. Programmatic invariants can serve as automatic triggers where possible. For instance, an invariant that the number of tokens that have been cashed in equal the amount of ether paid out, properly implemented, would have stopped The DAO attack in its tracks. The weaknesses of invariants, though, are that they are hard to specify, subject to blindspots because they are typically specified by the same people who wrote the smart contract, and, finally, they consume gas (though this is too small a price to pay for stopping a $53M heist).
2. Crowd-sourced triggers can bring in human supervision and catch issues that are difficult or impossible to specify as an invariant. In a crowd-sourced trigger, a pre-determined quorum can stop the payments in the buffer, keeping control at the hands of the participants, and allowing them to audit their script at runtime for unanticipated misbehaviors.

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.

Summary

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.