Forks, or their threat, appear to be an established characteristic of the cryptocurrency landscape. What are they, though? Why are they a large deal? And what’s the distinction between a hard fork and a soft fork?
A “fork” is an open-source code modification in programming terms. Usually, the forked code is similar to the original, but with significant modifications, and the two “prongs” coexist comfortably. Sometimes a fork is used to test a method, but with cryptocurrencies, it is more often used to introduce a basic shift, or to generate a fresh asset with comparable (but not equal) features to the original.
Not all forks are deliberate. With a commonly distributed open-source codebase, a fork can occur inadvertently when not all nodes replicate the same data. Usually, however, these forks are recognized and resolved, and the majority of cryptocurrency forks are due to disagreements over integrated features.
One thing to keep in mind with forks is that they have a “shared history.” Before splitting, the record of transactions on each of the chains (old and new) is identical.
Hard forks
There are two primary kinds of fork programming: hard and soft.
A hard fork is a shift to a protocol that makes older variants invalid. If older variants continue to run, they will end up with a distinct protocol and distinct information than the newer version. This can lead to substantial confusion and possible mistake.
With Bitcoin, it would be essential to modify a hard fork to define parameters such as block size, the complexity of the cryptographic puzzle that needs to be solved, restrictions on extra data that can be added, etc. Changing any of these regulations would cause blocks to be adopted by the new protocol but denied by older variants and could lead to severe issues–potentially even a loss of resources.
For example, if the block size limit were to be increased from 1 MB to 4 MB, nodes operating the new version would accept a 2 MB block but would be dismissed by nodes running the older version.
Let’s say this 2 MB block is validated by an updated node and added to the blockchain. What if a node operating an older version of the protocol validates the next block? It will attempt to add its block to the blockchain, but it will detect that the recent block is not valid. It will overlook that block and add its fresh validation to the past one. Suddenly you have two blockchains, one with both older and newer version blocks, and the other with only older version blocks. Which chain grows quicker depends on which nodes are validated for the next blocks and may result in extra divisions. It is possible that the two (or more) chains could develop forever in parallel.
It’s a hard fork, and it’s possibly chaotic. It is also dangerous, as it is feasible that bitcoins spent in a fresh block could then be spent again on an ancient block (since merchants, wallets, and customers operating the earlier code would not detect the expenditure on the fresh code, which they deem invalid).
The only alternative is to abandon one branch in favor of the other, which includes some miners losing out (the transactions themselves would not be lost, they would just be re-allocated). Or, at the same moment, all nodes would need to move to the newer version, which is hard to accomplish in a decentralized, widespread scheme.
Or, bitcoin divides, which has occurred (hello, cash for bitcoin).
Soft fork
A soft fork may still operate with older versions.
For example, if a protocol is changed in a way that tightens the rules, implements a cosmetic change, or adds a function that does not affect the structure in any way, then old version nodes will accept new version blocks. However, not the other way around: the newer, “tighter” version would dismiss old version blocks.
Ideally, in Bitcoin, old-version miners would understand that their blocks were dismissed and would upgrade. As more miners upgrade, the chain with predominantly fresh blocks becomes the longest, which would further orphan old version blocks, leading to more miners upgrading, and self-correcting the system. Since both old and upgraded nodes accept the new version blocks, the new version blocks eventually win.
For example, say the community has decided to reduce the block size from the current 1 MB limit to 0.5 MB. New version nodes would reject a 1 MB block and construct on the prior block (if mined with an updated version of the software), which would trigger a temporary fork.
This is a soft fork, and it has already occurred several times. Initially, Bitcoin did not have a block size restriction. The introduction of the 1 MB limit was performed through a soft fork, as the fresh rule was “stricter” than the old one. Also effectively introduced through a soft fork was the pay-to-script-hash feature, which enhances the code without altering the framework. This sort of amendment usually needs only the majority of miners to upgrade, making it more viable and less disruptive.
Soft forks do not carry the double-spending danger that plagues hard forks, as merchants and customers operating ancient nodes will read fresh and old version blocks.
