The DAO Exploit

Yesterday (2016 June 17) all hell broke loose in the Ethereum universe. A $150,000,000 deal was found to be defined by code with a bug. This has caused me to take more than a passing glance at Ethereum and DAO too.

Very briefly: Ethereum is a presumably secure platform within which smart contracts (.) can be defined by code. It involves digital currency that is, or at least was interconvertible with dollars. The DAO is such a contract. The code has a bug.

Some propose that the blockchain with the bad code be ‘forked’—i.e. that the current blockchain be abandoned. Some suggest this would be a terrible precedent, considering that this was not a flaw in Ethereum. I wish the first such bug had involved less money.

Language in which contracts are defined, .
The DAO White Paper
Analysis of the DAO exploit by Phil Daian
Expansive description of Ethereum.

Curiously this happened just as I was pondering whether similar bugs might be in Stiegler’s sealer proposal. In short: I don’t know. Both the DAO and my worries about Stiegler’s code involve putting the stack in an unanticipated state. There are contradictory opinions (my own) on my site. I am gradually beginning to believe that we need a more sound security theory—perhaps more formal; I don’t know.

Regarding the DAO bug, it seems clear that we need to better understand the meaning of code. In the case at hand we need to understand how that code operates in all situations contrived by a hostile agent. This is in the same category as computer security where you need assurance that some things stay fixed even as they interact with hostile signals. There is a growing consensus that this is impossible. I think that it is possible. There is the further concern distributed among stake holders that they understand some code. In the DAO case investors investing the $150,000,000 signed a document, in effect, saying that their money was to be used according to the logic of the code. Conceptually they should all have understood that code. Evidently they did not. An investment house can afford a code specialist; so can Warren Buffet. Some sort of trust network seems plausible; but it is not in place yet.

I have a poor opinion of the description of the language. It is typical of other languages descriptions today. It needs a much better description so that you can reason about what you are protected against. It has more to do with what cannot happen instead of what can. In the case at hand there is agreement in retrospect about what the code means and that meaning is bad. Perhaps the EVM is better described.
Perhaps this paragraph belongs better elsewhere on my website. The safety here is that the hostile behavior does not share a runtime with you. The value of a variable within a contract is entirely under control of the code of the contract, whereas in some situations the protection boundary is at a call interface.