Ethereum Classic Divided Over the Proposed Hardfork

Ethereum is to hardfork within 85 hours with little if any apparent controversy as the community moves quickly to address dos vulnerabilities. Ethereum Classic however seems divided regarding a proposed hardfork to solve an underlying fault that has lead to numerous dos attacks.

The argument concerns null accounts that contain no balances or code and are fully empty. Ethereum developers have proposed the removal of this “state-bloat” as apparently the attacker could create as many null accounts as he wishes at effectively no cost to himself, but at a cost to the network in storage and perhaps memory usage.

Technically, this is a “violation of immutability”, says one active member of ETC’s community opening a debate that has apparently led to the formation of a small community arguing that the hardfork would breach ETC’s main reason for existing, immutability. Therefore, they are to continue ETC’s current chain as ETC Uncensored, splitting ETC’s currency and tiny community.

In comparable arguments made during the DAO debate, practicality and functionality is raised on one hand, with one commenter suggesting that immutability is “worthless in a dead chain” and idealistic principles on the other with some arguing that the attacker exploited the rules of the code, same as with the DAO, therefore over imposing new rules is a slippery slope.

The question regarding these empty accounts, for ETC’s community, is not without merit. From a practical point of view, we clearly want to remove the bloat, but from a hard ideological, perhaps even fundamentalist, immutability or bust view, which is the whole point of ETC, it is not very clear why these accounts should be removed since that would technically violate immutability which brings up an interesting philosophical question.

What is Immutability?

According to Wikipedia’s definition: “an immutable object is an object whose state cannot be modified after it is created.” We know this does not apply to blockchains, whether Ethereum or Bitcoin. They both can be modified from a technical perspective. Therefore, we need to add to the definition “cannot or should not.”

Should is a subjective term and a matter of opinion, concerning more philosophical or political questions than code, but it assists to establish three different categories for network upgrades as far as immutability is concerned.

There are purely technical upgrades, such as the current proposed fork, with decisions mainly based on technical aspects. These are not at all controversial, with little if any real arguments against it.

There are defensive upgrades where the decision is fairly obvious and beneficial to almost everyone – such as the slock.it dao upgrade where a theft was prevented with the agreement of an overwhelming majority, but a small minority disagrees for a variety of reasons from purely selfish (such as say thief sockpuppets) to more thoughtful considerations of how such upgrades could be abused.

Generally, upgrading the network in these cases has overwhelming and obvious benefits. Equally, failure to do so has tremendous costs for network participants and potentially the network itself on a social and reputational level. The network incentives, therefore, would probably demand an upgrade in most cases with the upgraded chain having far more value than the immutable at a cost of tens of millions chain as we have seen with the dao fork.

Then there are offensive, as in pro-active, rather than defensive, hardforks which almost everyone takes issue with and where the principle of immutability truly, and perhaps solely, applies. An example would be seizing satoshi’s bitcoins – a clear abuse of power, but, considering that bitcoin mining is so centralized and may well be a cartel, it might be tempting for miners to covertly seize such coins.

Here, immutability is necessary, but the question of should is irrelevant, giving prominence to the question of can which depends on the level of decentralization of not just mining, but developers, clients, and all other aspects. The dogmatic application or misapplication of this principle can therefore be dangerous if applied where it is of little benefit yet high cost to the network and its participants as, in increasing centralization, it places the network at risk of mutability where it actually matters.

What we may now see with ETC is the absurdity of the dogmatic application of this principle by a very small number of individuals even where the principle is of no benefit and in fact likely to be quite harmful.

From a dogmatic point of view, ETC should not fork, because the attacker simply knows the code better than any ETC dev and has not violated any rule of the protocol. Instead, the attacker is using the rules far more proficiently than any ETC developer. Therefore, ETC’s community has no right to impose its will upon the attacker by changing the rules afterwards as this leads to a slippery slope where the one or two ETC devs make all sort of decisions and might all the sudden censor ordinary transactions and demand that everyone provides ID to use the network (or they suddenly randomly start seizing assets).

Nonsense arguments, of course, but, since the whole point of ETC’s existence is a dogmatic application of immutability, by their own arguments, they should not fork. Practically, however, they have no choice, thus invalidating the dogmatic application of the immutability principle even where it is of high cost while providing as good as no benefit.