User-Activated Soft And Hard Forks
Basically, a soft fork is new rules implementation. An old style software protocol with old set of rules will definitely accept innovation. This is caused by additional restrictions making verified set of blocks narrower. A hard fork, on the contrary, expands the number of allowed blocks. This means that blocks considered invalid before will become correct. Naturally, classic style nodes tend to reject them without upgrade. Hard forking is more dangerous since it may partially prohibit classic nodes to participate in the network.
User-activated soft fork (UASF)
UASF is a mechanism intended to activate a soft fork. The time of activation is specified in advance, and each participant can get prepared to consequences and upgrade software. Nevertheless, UASF has to be supported by majority of users and organizations. This concept was applied to initiate a BIP 148 proposal activation to implement SegWit.
User-activated hard fork (UAHF)
UAHF is a mechanism that requires developers to create and integrate new rules to make changes to software. Afterward, some invalid blocks get valid. The majority of hash power is irrelevant here, since the software development does not depend on it.
There are several reasons that stand behind the UASF vs. UAHF decision. Bitcoin is known to have some weak points. In order to solve these problems, developers proposed a solution, SegWit BIP148. However, some network participants and organizations like Bitmain or Bitcoin Unlimited refused to apply the changes. If the new system is implemented, the whole BTC environment will get split. That is why different options are examined now to prevent the unwanted consequences.
Of course, there were many precedents of forking before. Namely, all orphaned blocks are parts of different forks. As a transaction added to blockchain during the hash calculation, different miners use different sets to calculate hash. Before finalizing the block, it is possible to get two correct blocks at the same time.
There are several good examples of UASF and UAHF in the Ethereum blockchain.
In April-May 2016, The DAO, an Ethereum-based project, was launched. Some time later, a hacker managed to find a weakness in the code and stole $55 million from the foundation account. There were several options:
- To leave it the way that was.
- To execute a soft fork and remove the stolen money from the hacker’s crypto wallet.
- To execute a hard fork and roll the whole network back to the time before the hack.
The last option was considered as acceptable by the majority of Ethereum members. However, some participants refused to take part in this event, assuming that the main idea of blockchain, which is “Code is law”, must not be abused. As a result, two separated blockchains appeared. Those who did not accept changes got stuck with the Ethereum Classic network, while the others became members of Ethereum.
The UASF or UAHF implementation can be real for the Bitcoin network as well. This will definitely lead to great changes. There are several possible scenarios:
- Mining nodes and regular participants accept the changes, hence a fork is not executed.
- The network users vote for the changes, while miners do not. If the number of regular participants exceeds 51%, only one chain appears. If their number is less than 51%, the network will be split into two chains.
- No agreement between regular users and miners. The larger community might attack the smaller one, and all transactions processed by the second group will get unreliable.
Different scenarios bring different results. Small groups might try to change their protocols and software on their own. In this case, consequences can hardly be forecast.