It has been several days since Tjaden Hess, River Keefer and I wrote about how Ethereum's planned DAO Wars soft fork is a potential vector for denial-of-service (DoS) attacks. That blog post prompted a community-wide re-thinking of fork dynamics. In this post, we want to delve into the ramifications of that post.
First of all, the DoS attack vector we discussed is fundamental. It is not specific to that specific soft fork and has nothing to do with The DAO. It applies to any and all attempts where a majority of miners collude to exclude transactions based on their execution behavior from the Ethereum blockchain. And it says that miners who engage in such censorship can be punished.
The main, underappreciated consequence of this is that Ethereum inherently resists censorship, even by a majority of its miners. This is quite a surprising, and fantastic, outcome. Ethereum miners necessarily need to act in unison. A majority of colluding miners cannot conspire to exclude targeted transactions out of the Ethereum blockchain based on their execution, without being subject to debilitating attacks. True, miners can still exclude transactions based on features that are easy to statically analyze: e.g. format, syntactic features, source addresses, etc. But many static analyses are costly, and these costs all inherently pose a DoS vector to fight against censorship. So an Ethereum miner cannot say, for instance, "I will refuse to mine transactions that interact with contract X or send coins to address Y." Even a 51% or greater colluding cartel of miners cannot impose such a rule on the rest of the network.
We don't believe anyone was quite cognizant of this feature until our post. It's a fascinating property, that a system is able to keep even those who maintain the records in check, even when a majority of them are corrupt.
For context, Bitcoin does not have this feature: a majority of miners can censor Bitcoin transactions. We are lucky that Bitcoin miners have, to date, played very nicely by the rules and maintained fungibility.
Despite the connotations of the English words used, there is nothing remotely "soft" about a soft fork. Soft forks are violent affairs where a majority of miners attempt to impose their will on a minority, who have no means of voting against the new changes. In some sense, because nodes once voted to support a wide range of behaviors, it is assumed that, in a soft fork, they would support all subsets of that behavior.
But it is not a sound assumption that everyone who is OK with a behavior is OK with all subsets of that behavior.
For instance, my Bitcoin nodes exist to support money transfers between parties. A hypothetical soft-fork where money transfers can only take place between entities who have identified themselves with government ID represents a violation of what my nodes stand for.
Sadly, Bitcoin relay nodes have no facility by which they can reject such soft forks. In fact, even the Bitcoin miners are powerless against such a soft fork in the presence of a soft-fork supporting majority. In contrast, in Ethereum, the DoS vector we identified allows anyone in the community to punish miners who engage in censorship via a soft fork, even when the censoring miners constitute a majority.
At a higher level, participants in a system engage with that system based on a service agreement, whether explicit or implicit. This agreement should ideally be inviolable in toto. Soft forks represent a reneging on that agreement by a colluding group of miners. True, the colluding cartel cannot add new terms, but soft forks are an attempt to modify the contract by crossing out certain expectations. As such, they can violate the spirit of the contract, and can be violent affairs when used for evil ends such as censorship. It's fantastic to know that Ethereum provides its users with a way to resist them.
The Ethereum community's response to our post was fantastic. Within hours, we had a confirmation of the severity of the problem, and a corresponding shift among miners to not activate the soft fork. The miners reversed their voting patterns, and the dangerous soft fork did not get activated. The developers nuked the flawed geth release to completely undo the soft fork.
We received many notes of support from the community. A very human, but completely flawed, response would have been to deny the problem, to minimize its potential severity, and to attack the researchers. In contrast, the Ethereum community has been amazingly science-driven, open and forthright. The civilness of their response should be a shining example to other communities.
Following our announcement, the Ethereum price took a 10% dip, losing approximately $100M from the system's total valuation.
On the one hand, this was disconcerting: finding and fixing a flaw before it goes into production should be a cause for celebration, an indication of a healthy, functioning process, and not a sell signal. Of course, it is difficult, at best, to direct the skittish masses towards rationality.
On the other hand, various people have remarked that, had the DoS vulnerability not been discovered, and Ethereum had been attacked, it likely would have created a severe setback for the system, possibly killing it entirely. So, we've been told by a few people that the right way to view the blog post is that it saved $900M in value. :-)
A few people, some with close personal ties to people involved in Slock.It, criticized our disclosure for having been made in the public arena. We want to briefly outline why our disclosure was a textbook example of responsible engagement.
There is no ethical dilemma whatsoever about disclosing an unexploitable bug. The bug could only be activated in the future, and it was entirely preventable. We warned of an impending disaster that would have happened if, and only if, the community voted to adopt a change in the protocol. We did this prior to the adoption of the change. At no point in time were any funds at risk. In fact, the only way anything could have been at risk (and, in our opinion, the entire Ethereum ecosystem would have been at risk) is if we did not inform the voting miners and the community about the impending potential problem.
There are many other secondary considerations, e.g. the vector had been mentioned by others publicly on social media, we informed the Ethereum leads about the flaw ahead of time, and we did not provide executable code, out of an abundance of caution. But these pale in comparison to the main point.
We are greatly encouraged by the Ethereum community, happy to have helped avert a potential disaster, and even happier to have stumbled onto an accidental but turns-out-to-be fundamental property of Ethereum, namely, that it is resilient to censorship, even by a majority of its miners.