Editor's Note: This article comes fromEditor's Note: This article comes fromEthereum enthusiasts (ID: ethfans) vitalik, author Vitalik Buterin, reprinted with permission from Odaily.
secondary title
Hard Fork, Soft Fork, Default and Mandatory
The following figure can illustrate the fork type:
image description
The left side of the figure is a two-way hard fork, and the right side is from large to small: strict expansion hard fork, original agreement, soft fork
Here are some of the commonly cited advantages of soft forks and hard forks.
Hard forks give developers more flexibility when making protocol upgrades, since they don't have to be careful to ensure new rules.
Soft forks are more convenient for users because users don't need to upgrade to stay on the blockchain.
A soft fork is less likely to result in a blockchain split.
Soft forks only require the consent of miners/validators (even if users still use the old rules, but if nodes use the new rules, only things valid under the new rules will be entered into the chain); hard forks require users to choose to agree.
Beyond that, one of the main criticisms of hard forks is that hard forks are "forced." The coercion referred to here is not physical force, but coercion through network effects. That is, if the network changes the rules from A to B, even if you personally like A, if most other users like B and switch to B, then you must switch to B in order to enable the same network as everyone else, despite your Individuals disagree with the change.
1.
Proponents of hard forks are often derided as trying to achieve a "malicious buyout" of the network and "force" users to join them. In addition, the risk of blockchain splits makes the hard fork scheme labeled "unsafe".
My personal opinion is that these criticisms are misplaced and in many cases put the cart before the horse. This point is not specific to Ethereum, or Bitcoin, or any other blockchain; it stems from the pervasive nature of these systems and applies to any of them. Furthermore, the argument below applies only to controversial protocol changes, i.e. when a majority of members of at least one community component (miners/validators and users) disapprove of the change; if the protocol change is non-controversial, Then the change can usually be done safely, no matter which way the fork was implemented.
First, let's discuss the issue of coercion. Both hard forks and soft forks can change the protocol in ways that some users may not like; if the change is not 100% supported, then any protocol change faces the problem of being enforced. Furthermore, it is almost inevitable that in any case at least some opponents of protocol changes will abandon their preferred protocol rules because they want to align with the majority of members with a greater emphasis on network effects. Therefore, both types of forks are mandatory in the sense of network effects.
However, there is an essential difference between hard forks and soft forks: hard forks give users the opportunity to choose, while soft forks do not allow users to "choose". Users who want to join the hard fork chain have to install the software package that implements the fork rules themselves, and those user bases who disagree with the rule change more than they value network effects can theoretically simply stay on the old chain—in practice, this way events have occurred.
The above description applies equally to strictly extending hard forks and two-way hard forks. However, during a soft fork, once the fork is successfully forked, the blockchain before the fork no longer exists. Therefore, soft forks are clearly institutionally biased towards forced acceptance rather than disengagement, and hard forks are the opposite in this regard. My own moral views lead me to favor disengagement over coercion, although others may disagree (the most common argument is that network effects really matter and that the existence of "one coin" is crucial , although milder versions also exist).
Aside from the above discussion, if I had to guess why soft forks are often considered "less mandatory" than hard forks, I would say that it's because a hard fork feels like "forcing" users to install a software update , and soft fork users do not "necessarily" do anything. However, this intuition is misleading: what matters is not whether individual users have to perform the simple bureaucratic step of clicking a "download" button, but whether users need to be forced to accept protocol rule changes they are unwilling to accept. Measured by this standard, soft and hard forks are ultimately mandatory, while hard forks are slightly better at maintaining user freedom.
Now, let’s look at highly contentious forks, especially those where miner/validator preferences conflict with user preferences. There are three scenarios here: (i) a two-way hard fork, (ii) a strictly expanding hard fork, and (iii) a so-called "user-activated soft fork" (UASF). The fourth category is where miners activate soft forks without user consent; we will discuss that later.
First, a two-way hard fork. In the best of cases, the situation is simple. The two coins are traded in the market, and traders determine the relative value of the two. From the ETC/ETH case, we have ample evidence that miners are most likely to simply distribute their computing power according to the ratio of coin prices in order to maximize their profits, regardless of their ideology.
Even if the ideology of some miners leans toward one side or the other, there will most likely be enough other miners willing to arbitrage the mismatch between price and hashrate to bring the two into line. Assuming that some miners try to form a group not to mine on a certain chain, the arbitrage space will create an incentive for people not to do so.
There are two edge cases here. The first possibility is that the value of mining has decreased due to the decrease in price, but the difficulty has not decreased to a matching level due to the inefficient difficulty adjustment algorithm. At this time, mining becomes unprofitable, and no miner will be willing to lose money. Continue to push the entire chain forward until the difficulty returns to balance. This is not the case for Ethereum, but it may be the case for Bitcoin. Therefore, the minority chain will most likely never start. Note that whether this situation is good or bad depends on how you feel about coercion vs secession; you can infer from what I wrote above that I personally think this kind of difficulty adjustment algorithm that is hostile to minority chains is bad.
The second scenario is that the larger chain can 51% attack the smaller chain if the difference is very large. Even with a 10:1 ETH/ETC split, that didn't happen; so it certainly didn't have to happen. However, if the miners on the large chain prefer force over breakaway, and act with their preference, then a 51% attack scenario is always possible.Next, let's look at strictly extending hard forks. SEHF (short for Strictly Extended Hard Fork) has the property that the pre-fork chain is still valid under the rules after the fork, so if the fork chain is cheaper than the non-fork chain, it will have a lower price than the non-fork chain. The non-forked chain has lower computing power, so the non-forked chain will eventually be accepted as the longest chain by the client rules of the original chain and the forked client rules, while the forked chain "”。
will be obliterated
Such a fork has an inherent disadvantage, because the possibility of the forked chain being annihilated will be reflected in the price, driving the price down, making the chain more likely to be annihilated... This argument is very strong in my opinion, so any controversial The fork of should be a two-way hard fork, not a strict extension.Bitcoin Unlimited devs suggest adoption after forkTwo-way manual hard fork
to deal with this problem, but a better option is through built-in bidirectionality; for example, in Bitcoin's case, rules can be added to disallow some unused opcodes, and then the operation containing this opcode can be done on the non-forked chain transaction, so that under the fork rule, the non-forked chain will be considered invalid forever from then on. In the case of Ethereum, almost all hard forks are automatically bidirectional due to the various details of how state computation works. Other blockchains may have different properties due to structural differences.
The last type of fork mentioned above is a user-activated soft fork. In UASF (short for User Activated Soft Fork), users switch to the soft fork rules without miners' consensus; they expect miners to automatically agree to the rule change because of the economic benefits. If many users don't implement UASF, then the coin will split, which will result in the same situation as a strictly scaling hard fork, except - and this is the really clever and devious part of the concept - is strongly detrimental in a strictly scaling hard fork The "annihilation risk" of forked chains is here strongly biased towards forked chains in UASF. Even if the UASF offers options, it exploits economic asymmetry to make forks more likely to succeed (although this propensity is not absolute; if the UASF decides to be unpopular, it will not succeed and will result in a blockchain split).
However, UASFs are a danger. For example, suppose the project's developers want to create a UASF patch that converts a previously unused opcode that accepts all transactions to an opcode that only accepts transactions that conform to some new rules, even if politically or technically controversial or Miners don't like it. Miners have a clever and cunning way to fight back: they can unilaterally implement a miner-activated soft fork, making all transactions that use the functionality created by the soft fork fail.
Suppose we have three rule sets:
The original rule, where opcode X is always valid.
A rule where opcode X is only valid if the rest of the transaction complies with the new rules
Opcode X is always invalid rule.
Note that (2) is about the soft fork of (1), and (3) is about the soft fork of (2). Hypothetically, there is strong economic pressure in favor of (3), and the soft fork cannot achieve its goal.
