Soft fork, hard fork, default and mandatory

Author: Vitalik Buterin

Original Title: 《Hard Forks, Soft Forks, Defaults and Coercion》

Published on: March 14, 2017

In discussions related to blockchain topics, a very important discussion revolves around whether soft forks or hard forks are preferable in the protocol upgrade mechanism. A fundamental difference between soft forks and hard forks is that soft forks change the protocol rules by strictly reducing the number of valid transactions, allowing nodes that follow the old protocol rules to remain on the new chain (assuming a majority of miners/validators implement the fork), while hard forks allow previously invalid transactions and blocks to become valid, requiring users to upgrade their clients to stay on the new chain after the hard fork. In hard forks, there are two subtypes: 1. Strictly expanding hard forks, which completely expand the set of valid transactions, thus allowing the old rules to be effectively compatible with the new rules, and 2. Bilateral hard forks, where both sets of rules are incompatible.

Here is a Venn diagram illustrating the types of forks:

The two commonly cited advantages are as follows:

1. Hard forks provide developers with more flexibility during protocol upgrades, as they do not need to consider whether the new rules are compatible with the old rules.
2. Soft forks are more convenient for users, as they do not need to perform additional upgrades to continue on the new chain.
3. Soft forks are less likely to lead to chain splits.
4. Soft forks only require the consent of miners/validators (even if users are using the old rules, if nodes make the chain use the new rules, then only transactions valid under the new rules can enter the chain, and this is the case in any situation). Hard forks, on the other hand, require user consent.

Additionally, the main criticism of hard forks is that they are "coercive." The coercion referred to here is not physical force; rather, it is a form of coercion through network effects. In other words, if the network changes the rules from A to B, then even if you personally prefer A, if the majority of users favor B and switch to B, you must also switch to B to stay in sync with others on the same network, regardless of your personal feelings about B.

Supporters of hard forks are often mocked for attempting to exert "malicious takeover" influence over the network and "forcing" users to go along with them. Furthermore, the risk of chain splits is often cited as a reason why hard forks are unsafe.

In my personal view, these criticisms are misguided. In many contexts, these situations are often the opposite. This perspective is not specific to Ethereum, Bitcoin, or any other blockchain; it stems from the general characteristics of these systems and applies to any of them. Moreover, the arguments below only apply to controversial changes where at least one constituency (miners/validators and users) has a majority opposed; if the change is not particularly controversial, it can be carried out very safely, regardless of the form of the fork.

First, let’s discuss the issue of coercion. Whether it is a soft fork or a hard fork, both change the protocol in ways that some users may dislike. Especially when the protocol does not receive 100% support, changing the protocol will make some users unhappy. Furthermore, it is almost inevitable that, in any case, dissenters place greater importance on maintaining synchronization with the majority's network effects than on their own preferences regarding the protocol. Therefore, in the sense of network effects, both types of forks are coercive.

However, there is an essential difference between soft forks and hard forks: hard forks are opt-in, while soft forks leave users with no choice. For a user to join a hard fork chain, they must personally install the software package to implement the fork rules, and the reactions of the group of users who disagree with the rule changes are often stronger than their concern for network effects; theoretically, they can remain on the old chain—and in fact, this has happened.

This applies to both strictly expanding hard forks and bilateral hard forks. However, in the case of soft forks, if the fork is successful, then the non-forked chain ceases to exist. Thus, soft forks are clearly more institutionally coercive rather than separative, while hard forks have the opposite tendency. My personal moral views lead me to favor separation over coercion, although others may not agree (the most common argument is that network effects are indeed very, very important for "one coin, one rule," which is essential, although a more moderate version also exists).

If I had to speculate on the reason, despite what I just stated, soft forks are still considered "less coercive" compared to hard forks, I would think it is because hard forks give users the impression that hard forks "force" users to install software updates, while in the case of soft forks, users can do nothing at all. However, I must say that this intuition is incorrect. What matters is not whether individual users must perform simple bureaucratic steps to click the "download" button, but whether users are coerced into accepting a change in the protocol, even if they do not want to accept it at all. And by this metric, as shown above, both types of forks are ultimately coercive, and hard forks are slightly better than soft forks in providing users with freedom.

Now, let’s look at highly controversial forks, particularly those where the preferences of miners/validators conflict with those of users. There are three scenarios: (i) bilateral hard forks, (ii) strictly expanding hard forks, and (iii) the so-called "user-activated soft fork" (UASF), with a fourth category being miners activating a soft fork without user consent. We will mention it later.

First, let me talk about bilateral hard forks. In the most ideal scenario, this situation is very straightforward. Two coins are traded in the market, and traders determine the relative value of the two coins. In the case of ETH/ETC, we have overwhelming evidence that the vast majority of miners prefer to allocate their hash power to the coin based on the price ratio to maximize their profits and returns, without considering their historical ideological views to determine their hash power allocation.

Even if some miners have ideological preferences leaning towards one side or the other, it is highly likely that enough miners will be willing to arbitrage the mismatch between price ratios and hash power, aligning the price ratio with hash power. If a group of miners wants to unite to stop mining on this chain, then this incentive will face the problem of excessive deficiency.

There are two edge cases. The first possibility is that due to an inefficient difficulty adjustment algorithm, the value of mining decreases because the value of the coin decreases, but the difficulty of mining does not decrease. This would make mining very unprofitable and unattractive. No miner would continue to push the chain forward in a loss-making situation until its difficulty restores balance. This is not the case for Ethereum, but it could very well be the case for Bitcoin. Therefore, a minority hash power chain is unlikely to ever take off, and thus it will die. Note that this is not necessarily a good thing; the answer depends on your views on coercion and separation. From my personal perspective above, I believe that such a minority hash power chain with hostile difficulty adjustment algorithms is not a good thing.

The second edge case is that if the disparity is very large, a high hash power chain can launch a 51% attack on a low hash power chain. But even with an ETH/ETC split ratio of 10:1, such an attack has not occurred. So this is certainly not a definitive answer. However, if miners on the dominant chain prefer coercion and allow deviations to split, then these miners will always find a way to achieve that.

Next, let’s look at strictly expanding hard forks (SEHF). In SEHF, there are valid attributes of non-forked chains under the fork rules, so if the forked chain has a lower price than the non-forked chain, then the hash power of the forked chain will be lower than that of the non-forked chain. Consequently, the non-forked chain will eventually be accepted by both the original client and the forked client as the longest chain. Gradually, the forked chain will be "overwhelmed."

One argument is that such forks succeed due to strong inherent biases, as the forked chain is overwhelmed and left behind in price, making the price of the coin lower, which increases the likelihood of the forked chain being overwhelmed. This argument makes a lot of sense to me, so it is a good reason to pursue bilateral hard forks rather than merely expanding.

Many Bitcoin developers suggest manually conducting bilateral hard forks after a hard fork to address this issue. However, a better option is to use built-in bilateral hard forks. For example, in the case of Bitcoin, you can add some rules to prohibit certain unused opcodes, and then include transactions with these opcodes on the non-forked chain, so under the fork rules, the non-forked chain will become permanently invalid at that time. In the case of Ethereum, regarding various details of how computational state works, almost all bilateral hard forks are automatic. Other chains will have different attributes based on their underlying infrastructure.

The last type of fork mentioned above is the user-activated soft fork. In UASF, users can directly activate soft fork rules without considering whether they have the consensus of miners; miners may be excluded from economic benefits. If a significant number of users do not follow this UASF, then the coin will be split, leading to a situation similar to that of a strictly expanding hard fork. Even if UASF is optional, it uses economic asymmetry to make itself more likely to succeed (although this bias is not absolute; if this UASF is deemed unpopular, it will not succeed, and doing so will only lead to blockchain splits).

However, user-activated soft forks are a dangerous game. For example, let’s assume that a project's developers want to create a UASF patch that converts previously accepted unused opcodes to only accept transaction opcodes that comply with some new rules, which would be controversial both politically and technically, and miners are unlikely to favor this feature. Miners have a clever and cunning way to counter this situation: they can unilaterally implement a miner-activated soft fork that ensures that features created using the soft fork will always fail.

Now, we have three rules:

1. The original rule where opcode X is always valid.
2. Opcode X is only valid if other transactions comply with the new rules.
3. The rule where opcode X is always invalid.

Note that point 2 is a soft fork of point 1, and point 3 is a soft fork of point 2. Now, there is strong economic pressure on point 3, so the soft fork cannot achieve its goal.

Therefore, my conclusion is this: soft forks are a dangerous game, especially when they are controversial, as miners begin to retaliate, making the game increasingly perilous. Strictly expanding hard forks are also a dangerous game. Miner-activated soft forks are coercive, while user-activated soft forks are less so, but due to the formation of economic pressure, users' choice to activate soft forks still carries some coercive element, which also poses certain dangers. If you really want to make a controversial change and insist that the social cost of doing so is worth it, then go ahead and make a clean, pure bilateral hard fork, take some time to add replay attack protection, and let the market's invisible hand help you sort it out.