To fork or not to fork? TheDAO's hack and Ethereum's governance

June 17th, 2016 was an important day for the Ethereum community, and for the blockchain community more generally. It was the day in which it became apparent (although not to everyone) that social organizations cannot be ruled only and exclusively by code.

But let’s start from the beginning. The story begins on April 30th, 2016 with the birth of TheDAO, a brand new organizational structure commonly referred to as a Decentralized Autonomous Organization

In a nutshell, TheDAO is nothing more than a piece of code running on the Ethereum blockchain, which can be regarded as a decentralized investment fund. It enables people to invest Ether (Ethereum’s native cryptocurrency) into the fund in order to vote on the proposals they want to fund.

On June 17th, just a few weeks after its launch, TheDAO has been hacked. The attacker exploited a bug in the code, draining it of 3.6 million Ether (worth over 50 million dollars worth of at the time of the attack).

Unlike the traditional financial system, where financial intermediaries have the power to unilaterally revert illegitimate transactions, on the blockchain, after a transaction has been made, it becomes an irrevocable part of history, and no single entity can revert it.

Given the extent of the attack, some influential members of the Ethereum community, including its inventor Vitalik Buterin, suggested two possible ways of resolving the issue:

• updating the Ethereum client so as to censor all transactions coming from TheDAO’s account to prevent the attacker from extracting more funds (a so-called soft-fork)[1]
• modifying the transaction history of the Etheurm blockchain, in order to restore the original balance of TheDAO (a so-called hard-fork).[2]

Both solutions require cooperation of the Ethereum community. Only if a majority of key entities agree to upgrade the Ethereum client in a coordinated manner is it possible to change the consensus state of the Ethereum blockchain.

What would appear to many as a simple decision (“Should we remediate a tort caused by a software bug?”) turned out to be quite a controversial issue. The situation led to an actual divide in the Ethereum community, between those eager to intervene in order to revert the illicit transaction, and those who absolutely want to abide by the wording of the code (in spite of its flaws), even if this goes counter to the original intention of the code. Indeed, some members of the latter group believe that the attacker has not done anything wrong other than ingeniously using the code to get additional funds, and restoring TheDAO balance would therefore amount to stealing from the attacker.

Ultimately, the divide can be reduced into a disagreement on whether the “intention of the code” should prevail over the “wording of the code”.
To better understand the arguments from both sides, it might be useful to distinguish between two different types of codes:

• Legal code, written in a language that is inherently flexible and ambiguous. This is the reason why the law must always be appreciated by a judge in order to determine, on a case-by-cases basis, whether (and how) it applies to the particular facts of a case. In some cases, the judge might decide to ignore the wording of the law, whenever it appears that, given the facts of the case, blindly applying the rules would actually violate the original intention of the legislator.

• Computer code, written in a strict and formalized language, which is only meant to apply to these cases that have been specifically accounted for. As opposed to the law, computer code lacks the necessary flexibility to cover unforeseen situations that might emerge in a complex society. Besides, the more formalized a rule is, the easier it is for an attacker to exploit it or to route around it.

If one had to choose between one of these two options, most people would probably go for the former. Yet, many people from the blockchain community tend to believe that people (and organizations) cannot be trusted and social interactions should consequently be mediated only and exclusively through computer code.

This is what motivated the development of Bitcoin and other blockchain-based applications. These so-called “trustless” technologies are designed to enable people to interact with one another on a peer-to-peer basis, even if they do not know and therefore do not trust each other. Provided that the underlying technology can be trusted, the blockchain makes it possible for people to coordinate themselves and to exchange value without the need for any trusted third party.

Of course, there is no such thing as a “trustless” system. While it is works well as a rhetorical tool, the ideal of a perfectly trustless technology is nothing more than an ideal. Every blockchain today relies on a number of agents that must be trusted to ensure the operations of the network —those include the developers of the software, the miners validating the transactions and, more generally, all the active participants in the network.

These trusted agents are often regarded as a threat by the blockchain community, in that they might possibly collude into centralized control points that would harm the trustless nature of the network.

But these agents also have an important role to play when trust in the technology breaks down because of unforeseen circumstances (i.e., due to a flaw in the blockchain’s code or design). If the technology can no longer be trusted, the whole system will break unless the technology can be fixed and upgraded. In the case of a blockchain, this means letting these agents intervene —through a soft or hard fork— in order to restore the original guarantees of the system, and ideally, restore trust in the technology.

This process is not uncommon; it has already been done multiple times, both with Bitcoin and Ethereum, to fix bugs or upgrade the protocol. However, it has —thus far— never been done to change the history of transactions. It is this very action that is currently being condemned by some members of the blockchain community, on the ground that it would violate the basic guarantees of immutability and irrevocability.

Independently of whether it makes sense to perform a soft or hard fork on the Ethereum network, the current debate has shed light on a much more fundamental problem.

We seem to have lost sight of the original motives that justified the development of these trustless systems —allowing people to collaborate and coordinate themselves on a peer-to-peer basis, without any central authority. That which was initially just a means to an end has now become an end in and of itself. Instead of being regarded as a tool to promote disintermediation and individual emancipation, immutability and irrevocability have turned into a dogma that must be preserved at all costs, regardless of the effects it has on the blockchain community, and on society at large.

We are now trying to preserve the (alleged) trustless character of the technology, even when faced with an apparent mistake or injustice. We are refusing to change the history of transactions, not because we believe one history is better than the other, but only because changing it would require some kind of human intervention.

But isn’t that exactly what distributed consensus is about? —allowing people to coordinate themselves, in a decentralized manner, on what they believe the state of the consensus should be? And if the Ethereum community agrees that a particular transaction is erroneous, doesn’t it have the right (or perhaps the duty) to intervene in order to fix the problem?

As I have already written before, centralized governance is no longer possible on a blockchain infrastructure, because centralized institutions —such as governments and corporations— have lost the ability to regulate the system. The power has shifted away from centralized authorities towards the individual members of the blockchain community, which now have the ability to dictate the rules of the game.

But with power also comes responsibilities. Members of the blockchain community have a lot of power, and are socially accountable for how they choose to exercise (or not exercise) this power. Even in a so-called “trustless” system, the community cannot delegate the responsibility of a tort to a simple piece of code, if the community is the one actually running that code. If there is no central authority capable of applying the law, the blockchain community is under a moral duty or responsibility to intervene in order to enforce the intention of the law (or of the code, for that matter) so as to preserve public order and morality. This is exactly what “distributed governance” is about.

The bottom line is that, if the objective is to promote individual emancipation, we must give people the ability —and the responsibility— to shape their own future. As long as there is consensus, people should be able to update their “social contract” —and that, even if it has been encoded into a “smart contract. Any refusal to do so would mean that people have ultimately lost agency to a trustless system that might eventually turn against them.

[1] A soft-fork does not violate the Ethereum protocol, it simply requires the consent of a majority of miners and validators, who must agree to censor certain transactions.
[2] A hard-fork actually violates the Ethereum protocol, and thus requires all active participants in the network to reach consensus for an invalid state transition to become valid.