10 min. read • Published 2020-08-20
A hard fork is a change to a protocol that renders older versions invalid. In case the older versions continue to run, they will end up with a different protocol and with different data than the newer version.
With bitcoin, a hard fork would be necessary to change defining parameters such as the block size, the difficulty of the cryptographic puzzle that needs to be solved, limits to additional information that can be added, etc. Changing these rules causes blocks to be rejected by older versions and accepted by the new protocol. This can have serious consequences!
For example, if the block size limit were to be increased from 1MB to 4MB, a 2MB block would be accepted by nodes running the new version, but rejected by nodes running the older version.
Assuming that the 2MB block is validated by an updated node and added on to the blockchain. What if the next block is validated by a node running an older version of the protocol? By trying to add its block to the blockchain, it will detect that the latest block is invalid. Therefore, it will ignore this block and attach its new validation to the previous one. Now there are two blockchains, one with both older and newer version blocks, and another with only older version blocks. Which chain grows faster will depend on which nodes get the next blocks validated, and there could end up being additional splits. It is possible that two or more chains could grow in parallel indefinitely.
Bitcoins spent in a new block could then be spent again on an old block (since merchants, wallets and users running the previous code would not detect the spending on the new code, which they deem invalid).
The only solution is for one branch to be abandoned in favor of the other, which involves some miners losing out (the transactions themselves would not be lost, they’d just be re-allocated). Or, all nodes would need to switch to the newer version at the same time, which is difficult to achieve in a decentralized, widely spread system.
A soft fork works with older versions and is changed in a way that tightens the rules, that implements a cosmetic change or that adds a function that does not affect the structure in any way, then new version blocks will be accepted by old version nodes.
In bitcoin, ideally, old-version miners would realize that their blocks are rejected, and would upgrade. The more miners upgrade, the longer the chain with predominantly new blocks becomes, which orphans old version blocks, which leads to more miners upgrading. Since new version blocks are accepted by both old and upgraded nodes, the new version blocks win.
For example, say the community decided to reduce the block size to 0.5MB from the current limit of 1MB. New version nodes would reject 1MB blocks and would build on the previous block, which causes a temporary fork.
This is a soft fork, and it has already happened several times. Initially, Bitcoin didn’t have a block size limit. Introducing the limit of 1MB was done through a soft fork, since the new rule was “stricter” than the older one. The pay-to-script-hash function, which enhances the code without changing the structure, was also successfully added through a soft fork. This type of amendment generally requires only the majority of miners to upgrade, making it more feasible and less disruptive.
Soft forks do not carry the double-spend risk that plagues hard forks, since merchants and users running old nodes will read both new and old version blocks.