In programming terminology, a “fork” is a change to an open-source code. The forked code is usually similar to the first but with significant changes, and the two “prongs” coexist peacefully. A fork may be used to test a procedure, but in the case of cryptocurrencies, it’s more likely to be used to make a fundamental modification or to produce a new commodity with similar (but not identical) qualities to the original.
Not all forks are made on purpose. A fork may occur unintentionally in a broadly distributed open-source codebase when not all nodes are duplicating the same information. The majority of bitcoin splits are caused by disputes about embedded features, and these forks are usually discovered and resolved.
One thing to remember about forks is that they have a “common history.” Prior to the separation, the transaction records on both chains (existing and new) were identical.
Hard and soft programming forks are the two primary kinds of programming forks.
A hard fork is a modification to a protocol that invalidates previous versions. If older versions are allowed to run, they will wind up with an alternative protocol and data than the current ones. This may cause a lot of confusion and even errors.
A hard fork would be required in the case of bitcoin to alter defining factors such as block size, the complexity of the cryptographic puzzle that must be solved, the amount of extra information that may be added, and so on. A modification to any of these criteria would cause blocks to be acknowledged by the new protocol but refused by earlier ones, potentially resulting in severe issues and even a loss of money.
For example, if the block size limit was raised from 1MB to 4MB, nodes running the new version would accept a 2MB block, but nodes running the previous version would refuse it.
Let’s pretend that this 2MB block is verified and uploaded to the blockchain by an upgraded node. What if a node running an earlier version of the protocol validates the following block? It will attempt to add its transactions to the chain, but will discover that the most recent block is invalid. Consequently, it will ignore that block and instead apply its new evaluation to the current one in the process. You now have two blockchains, one having blocks both from older and newer editions, the other with blocks just from earlier versions. Which chain grows quicker will be decided by which nodes verify the next blocks, and further splitting may occur. The two (or more) chains may potentially develop forever in tandem.
This is a fork in the road that may become nasty. It’s also dangerous, since bitcoins spent on a fresh block may wind up being spent on an old block (since wallets, merchants and users running the previous code would not detect the spending on the new code, which they deem invalid).
The only option is to forsake one branch in favor of the other, which will result in some miners losing money (transactions will not be destroyed; they will just be re-allocated). Alternatively, all nodes would have to upgrade at the same time, which is impossible in a decentralized, globally distributed system.
Or, as is currently the case, bitcoin divisions.
With earlier versions, a soft fork may still be used.
New version blocks will be allowed by old version nodes if, for example, a protocol is modified in a manner that tightens the rules, makes a cosmetic modification, or adds a function that has no effect on the structure. The newer, “tighter” version, on the other hand, would reject older versions of the blocks.
In the case of bitcoin, old-version miners should notice that their blocks are being refused and updated. As more miners upgrade, the chain with the majority of new blocks becomes the longest, orphaning older versions of blocks further, causing more miners to upgrade, and the system self-corrects. Because both old and updated nodes accept new version blocks, the new version blocks ultimately win.
For example, suppose the community voted to decrease the block size limit from 1MB to 0.5MB. New version nodes would reject 1MB blocks and build on the preceding block (if mined with a newer version of the code), resulting in a temporary fork.
This is a soft fork that has previously occurred on many occasions. When bitcoin was originally created, it did not have a block size limit. A soft fork was used to implement the 1MB restriction. A soft fork was also used to introduce the pay-to-script-hash function, which improves the code without altering the structure. This kind of modification usually only requires the upgrading of the majority of miners, making it more practical and less disruptive.
Because merchants and users running old nodes will read both new and old version blocks, soft forks avoid the double-spend danger that affects hard forks.