Hard Fork vs Soft Fork




The fork, or its threat, seems to be an established feature of the cryptocurrency landscape. But what are they? Why are they so important? And what is the difference between a hard fork and a soft fork?

"Fork," in programming terms, is a modification of the open source code. Usually the branching code is similar to the original, but with important modifications, and two comfortable "forks" coexist. Sometimes forks are used to test a process, but with cryptocurrency, it is more often used to apply fundamental changes, or to create new assets with characteristics that are similar (but not the same) as the original.

Not all forks are intentional. With open source code widely distributed, forks can occur accidentally when not all nodes replicate the same information. However, these forks are usually identified and resolved, and the majority of fork cryptocurrency is caused by disagreement over the characteristics embedded.

One thing to keep in mind with a fork is that they have "shared history." The transaction records for each (old and new) chain are identical before the split.

Hard fork

There are two main types of programming forks: hard and soft.

A hard fork is a change to the protocol that makes the older version invalid. If the older version continues, they will end up with different protocols and with data that is different from the newer version. This can cause significant confusion and possible errors.

With bitcoin, a difficult fork will be needed to change the parameters that determine such as block size, difficulty of cryptographic puzzles that need to be solved, limits for additional information that can be added, etc. Changes to one of these rules will cause the block to be accepted by the new protocol but rejected by the older version and can cause serious problems - maybe even losing funds.

For example, if the block size limit is increased from 1MB to 4MB, a block of 2MB will be received by the node running the new version, but it is rejected by the node running the older version.

Say that this block of 2MB is validated by nodes that are updated and added to the blockchain. What if the next block is validated by a node that runs an older version of the protocol? It will try to add the block to the blockchain, but it will detect that the latest block is invalid. So, it will ignore the block and attach the new validation to the previous one. Suddenly you have two blocks, one with the older and newer version blocks, and the other with only the older version blocks. Which chain grows faster will depend on which node gets the next block validated, and finally there can be additional separation. It is feasible that two (or more) chains can grow in parallel without limits.

This is a difficult, potentially messy fork. This is also risky, because the possibility of bitcoins spent in new blocks can then be spent again on old blocks (because traders, wallets, and users who run the previous code will not detect spending on new codes, which they consider invalid).

The only solution is for one branch to be abandoned for another, which involves several losing miners (the transaction itself will not be lost, they will only be reallocated). Or, all nodes must switch to newer versions at the same time, which is difficult to achieve in a decentralized and widespread system.

Or, the separation of bitcoin, which has happened (hello, bitcoin money).

Soft fork

Soft forks can still work with older versions.

If, for example, the protocol is changed in a way that tightens the rules, which implements cosmetic changes or adds functions that do not affect the structure in any way, then the new version of the block will be accepted by the old version of the node. However, not the other way around: the newer version, "tighter" will reject the old version of the block.

In bitcoin, the old version of the miners would ideally realize that their block was rejected, and will be upgraded. As more and more miners upgrade, chains with mostly new blocks become the longest, which will make the old versions of the block orphaned, which will lead to more increases in miners, and a self-correcting system. Because the new version of the block was received by the old node and that was upgraded, the new version of the block finally won.

For example, the community decided to reduce the block size to 0.5MB from the current limit of 1MB. The new version node will reject block 1MB, and will build in the previous block (if mined with an updated version of the code), which will cause a temporary fork.

This is a soft fork, and has happened several times. Initially, Bitcoin has no block size limit. Introducing the 1MB limit is done through a soft fork, because the new rule is "tighter" than the old one. The pay-to-script-hash function, which increases the code without changing the structure, was also successfully added through a soft fork. This type of amendment generally only requires most miners to be upgraded, which makes it more feasible and not too disturbing.

Soft forks do not carry the risk of double spending hitting heavy forks, because traders and users running the old node will read the new and old version of the block.
Powered by Blogger