In software development, a fork is the creation of a project in a different direction from the main or official project from the existing source code. This practice is in common use in open source projects or free software. In blockchain networks, forks are used both to create new projects from a previous one, and to update a project in question.
Blockchain networks are governed by rules encoded in the protocol that allow nodes to validate transaction blocks in the same way and remain in consensus. These rules verify that the structure of the block and the transactions included in it, such as the size of the block (amount of available space) are correct.
Sometimes consensus rules can be modified to add updates or protect the network from attacks, or changed for specific purposes, such as giving birth to a new cryptocurrency. Regardless of the reason for the modification, there are two ways to change the rules: using a soft fork or hard fork.
Soft forks change the protocol so that updated nodes reject previously valid transactions, but nodes with old software validate both old and new format transactions, making it easier for updated nodes to create the longest blockchain. These types of forks are more difficult to implement in code than the hard forks since compatibility with past versions of the software must be taken care of, which adds limitations when programming.
Hard forks modify the protocol so that updated nodes accept transactions with the new format, but outdated nodes reject them. In these cases, the new transaction structure can include previously invalid formats (for example, the old rules allow blocks of 1MB and the new ones from 1 to 2 MB) or change the format so that they are incompatible (for example, the structure of the addresses was ‘ABC’ and now it can only be ‘XYZ’).
Similarities and differences between a soft fork and a hard fork
In both soft forks and hard forks, users must participate in updating the network, either by downloading the new software and starting up updated nodes, or by refraining from doing so, if they choose so. However, soft forks do not exclude participants who do not update, while hard forks do. Regardless of the way in which the change is carried out, it is necessary to develop applications that take advantage of the update made. Key example of this is Segregated Witness or Segwit), an update that was implemented through a soft fork in the Bitcoin network, but which has taken a long time to be implemented by the various portfolios and services, causing that its improvements have not yet can be used by all users.
When forks are used to update the network in question, it is necessary to reach the threshold of adoption by the network nodes, previously agreed and implemented in code by the protocol developers. If, on the contrary, you want to create a new cryptocurrency, consensus is not a problem. The developers of the new blockchain specify the new parameters and a starting point regarding the forked chain, be it zero (like Litecoin) or a specific block height (like Bitcoin Cash).
In the case of hard forks, once activated, a kind of market game can start that can end in one of the following scenarios:
- The old or new chain is abandoned and the rest is active, with nodes and miners that have migrated mostly to this chain. In this scenario, miners who stay in the minority chain or take time to move to the longer chain may lose money. It is a common scenario before a scheduled update.
- Both chains survive and the processing power and value of each crypto asset is divided as determined by the market. This scenario is likely in cases of contentious or controversial hard forks. An example of this is the fork of Ethereum and Ethereum Classic.
- The chain that initiates the fork is totally foreign to the main chain, giving life to an altcoin whose birth does not necessarily affect the processing power or market value of the original chain. An example of this is the Bcash (Bitcoin Cash) fork from the Bitcoin blockchain.
In summary, soft forks are difficult to program, they reduce consensus rules and their implementation does not imply updating by all nodes in the network, although it is the most desirable scenario. In contrast, hard forks are easier to code develop, add or change current consensus rules, and their implementation involves a mandatory update of nodes or the exclusion of the network from not doing so; can derive in two independent chains.