Forks, or the threat of forks, seem to be a staple of the cryptocurrency landscape. But what are they? Why are they such a big deal? And what's the difference between a hard fork and a soft fork?
In programming language, a "fork" is an open-source code modification. Usually, the forked code is similar to the original, but with important changes, and the two "prongs" can comfortably coexist. Sometimes a fork is used to test a process, but in cryptocurrencies it is more commonly used to implement a fundamental change or to create a new asset with similar (but not the same) characteristics as the original.
Not all forks are intentional. In a widely used open source code base, a fork can be accidental if not all nodes replicate the same information. Usually, such accidental forks are detected and fixed. Most forks in cryptocurrencies occur due to disagreements over embedded features, as we will explore below.
One thing to note about forks is that they share a "common history." The record of transactions on each of the chains (old and new) is identical before the fork.
Hard Forks.
There are two main types of program forks:
- Hard fork.
- Soft fork.
A hard fork is a change to a blockchain protocol that invalidates older versions. If older versions continue, they will end up with a different protocol and data than the newer version. This can lead to significant confusion and possible errors.
In Bitcoin, a hard fork would be necessary to change defining parameters such as block size, mining difficulty algorithm, limits on additional information that can be added, etc. Changing any of these rules would cause blocks to be accepted by the new protocol but rejected by older versions, which could lead to serious problems - possibly even loss of funds.
For example, if the block size were increased from 1 MB to 4 MB, a 2 MB block would be accepted by nodes running the new version but rejected by nodes running the older version.
Suppose this 2 MB block is validated by an upgraded node and added to the blockchain. What happens when the next block is validated by a node running an older version of the protocol? It will try to add its block to the blockchain, but it will find that the last block is not valid. Therefore, it will ignore that block and append its new validation to the previous one.
Suddenly you have two blockchains, one with older and newer blocks and another with only older blocks. Which chain grows faster depends on which nodes have the next blocks validated, and there could be further splits. It is conceivable that the two (or more) chains could grow in parallel indefinitely.
This is a hard fork, and it is potentially messy. It is also risky, as it is possible that Bitcoins spent in a new block could be spent again in an old block (as merchants, wallets, and users using the previous code would not recognize the spending in the new code, considering it invalid).
The only solution is for one branch to be abandoned in favor of the other, at a loss to some miners (the transactions themselves would not be lost, they would just be reallocated). Or all nodes would have to upgrade to the newer version at the same time, which is difficult to achieve in a decentralized, widely distributed system.
Or Bitcoin splits, which has already happened (hello, Bitcoin Cash).
Soft Fork.
A soft fork is essentially the opposite of a hard fork, where newly introduced changes remain backward compatible with older versions.
For example, if a protocol is changed to tighten rules, make a cosmetic change, or add a feature that does not affect the structure of the blockchain in any way, then blocks from the new version will be accepted by nodes from the old version. The reverse is not true: the newer, "stricter" version would reject blocks from the old version.
In Bitcoin, the old version's prospectors would notice that their blocks were being rejected and would be forced to upgrade. As more prospectors upgrade to the latest version, the chain with the most new blocks becomes the longest, which in turn increases the number of orphaned blocks from the old version and causes more prospectors to upgrade. This process ensures that the system corrects itself. Since blocks of the new version are accepted by both old and upgraded nodes, the blocks of the new version eventually win.
Suppose the community decides to reduce the block size from the current theoretical limit of 4 MB (with SegWit blocks) to 0.5 MB. New nodes would reject blocks with the old limit and build on the previous block (if it was mined with an updated version of the code), resulting in a temporary fork.
This is a "soft fork," and it has happened several times before. Originally, Bitcoin did not have a block size limit. The introduction of the 1 MB limit was done through a soft fork because the new rule was "stricter" than the old one.
The pay-to-script hash function, which improves the code without changing the structure, was also successfully introduced through a soft fork. This type of change usually only requires the majority of miners to upgrade, making it more feasible and less disruptive.
Soft forks do not carry the risk of duplicate output that hard forks do, as traders and users running old nodes can read blocks from both the new and old versions.
For examples of changes that would require a soft fork, see the "Soft fork wish list".