A $50M Hack Tests the Values of Communities Run by Code [Motherboard]

A $50M Hack Tests the Values of Communities Run by Code

Written by
PRIMAVERA DE FILIPPI
11 July 2016 // 03:53 PM CET

June 17, 2016 was an important day for the small but dedicated community that has formed around the nascent decentralized technology known as Ethereum, 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.

The story begins on April 30, 2016 with the launch of TheDAO. TheDAO, which stands for Decentralized Autonomous Organization, is a leaderless collective of investors who vote on what to fund.

TheDAO runs on the Ethereum blockchain, a distributed ledger inspired by the Bitcoin blockchain. Ethereum has its own digital currency, known as Ether. It also features an internal Turing-complete scripting language, enabling people to deploy decentralized applications—also called smart contracts—on top of its blockchain.

In other words, TheDAO is a piece of code, or smart contract, running on the Ethereum blockchain. Anyone who invested Ether into the fund received a particular number of DAO tokens, which enable them to vote on the projects that TheDAO will fund. By the end of May, TheDAO had raised more than $150 million worth of Ether from investors.

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

The ideal of a perfectly trustless technology is nothing more than an ideal
In the traditional financial system, financial intermediaries have the power to unilaterally revert illegitimate transactions. On a blockchain network, however, after a transaction has been made, it can (theoretically) not be reversed—unless all active nodes of the network agree otherwise.

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, which both require the cooperation of the Ethereum community:

updating the Ethereum client so as to freeze any further movement of funds stemming from the attacker’s account, by censoring all the transactions that invoke that account (a so-called soft-fork). The advantage of this solution is that it can be put into practice without reaching consensus from the whole Ethereum community.
modifying the state of the Ethereum blockchain, in order to restore the original balance of TheDAO as it was previously to the theft (a so-called hard-fork). The problem with this solution is that it requires the whole Ethereum community to agree to that fork, at risk of otherwise splitting the network into two.
What would appear to many as a simple decision (“Should we remediate the damages caused by a software bug?”) turned out to be quite a controversial issue.

The situation led to a 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—they merely devised a clever way to use 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 (English) 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 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 who 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, such as 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.

If there is no central authority capable of applying the law, the blockchain community has a duty to intervene—that's what “distributed governance” is about.
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 motive 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? 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 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, who 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. They cannot delegate responsibilities to a simple piece of code, if they are the one 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.