Code is law, except when it isn’t

Code is law, except when it isn’t

Taken literally, “code is law” is caveat emptor taken to its logical extreme. That said, what many people (including many of The DAO’s unfortunate investors) evidently don’t realize is that this notion of “code is law” is deeply at odds to the common law idea that the intent/spirit of a contract supersedes its letter.

In the case of The DAO hack (and all the shenanigans that followed), there are actually two instances where the letter of the law (the code) is at odds with its intent:

  1. The DAO hack itself. Investors and the DAO’s authors intended for the DAO to be a sort of decentralized venture fund. They did not intend for its “splitDAO” function to have a recursive call vulnerability that would allow hackers to drain Ether from the contract.
  2. The blockchain’s state evolves over time as miners incorporate new blocks of transactions into the blockchain. If there are multiple competing blockchains, then miners vote on which blockchain is “correct”. The intention of the code underlying the mining process is that the miners are supposed to algorithmically determine which blockchain is longest, and use that one. They were not intended to vote “out-of-band” on things like whether to blacklist a smart contract because it is buggy / was hacked.

But miners certainly can do this, and that’s my point — the argument that in the first case “code is law” (so we must suck it up and deal with the hack), but that in the second case miners ought to respect the intent of the code’s authors, is logically inconsistent. In other words, it’s a bad argument, regardless of the “merits of the case” (i.e., whether or not forking Ethereum is good or bad in some larger sense).

This isn’t to say I support a hard fork — it’s solely meant as a riposte to the simple mechanistic argument that “code is law, deal with it, your tears are delicious”. There are good arguments for not restoring the funds taken by the hacker, but the arguments are rooted in the harmful precedent it would set to the Ethereum system as a whole to intentionally break the ledger’s immutability due to a third-party programming error — or anything other than a core protocol failure. For many users, including myself, Ethereum’s main draw is its extensibility (its flexible contract programming tools) combined with a blockchain’s ironclad guarantees of immutability. So, many of us genuinely recoil at the idea of a hard fork.

To be fair, there’s an obvious counter-point: at the end of the day, someone stole on the order of $80 million dollars from a huge number of (relatively small) investors. Justice as it is normally understood would require this money to be restored.

All that said, in principle, I’m ambivalent about a hard fork — there are good arguments both for and against. However, there are only two weeks remaining until the hacker can move funds from the “Dark DAO” where they’re currently frozen, and, in my opinion, for this reason alone, forking would be a mistake. Rushed code is bad code. The DAO was rushed. The DOS-vulnerable soft fork was rushed. If you ask me, rushing a hard fork would be a huge mistake.

Comments are closed.