Please read the disclaimer before proceeding. Thank You.
A naturally occurring fork is a divergence in a blockchain that occurs when a part of the network has a different perspective on the history of transactions than another part of the network. Imagine driving down a road in your car and all of the sudden, the road splits off into 2 separate paths. Imagine the road as the blockchain, your car as a part of the network (made up of users, miners, developers, etc.), and the 2 diverging roads as the forked parts of the newly forming blockchain.
This naturally occurring fork happens on a very regular basis and occurs when two or more blocks have the same block height. This typically happens when two or more miners find blocks at roughly the same time.
This type of fork fixes itself when one of the forked blockchains becomes longer than the other. The network validates the longest chain and the other block gets “orphaned” (abandoned) by the network.
Another type of fork is one that is purposefully introduced and is the more commonly discussed version – this is a divergence in a blockchain whereby a part of the network has a different perspective about the rules or protocols of the blockchain than another part of the network.
There are 2 ways that rules can change in a distributed blockchain network:
(1) A hard fork loosens or eradicates existing rules. Blocks which were previously invalid and unacceptable by nodes following the old rules are now considered valid and acceptable by nodes following the new rules.
Nodes that do not upgrade to the new rules will continue to reject these blocks, while nodes who upgrade will accept these blocks. This causes different nodes to see and record on different ledgers, thus diverging the blockchain into 2 separate blockchains in what is referred to as a chain split. To avoid a chain split, all nodes must upgrade to the new rules.
Examples of rules that might loosen in a hard fork: increasing the block reward, increasing maximum base block size, changing the proof of work function, etc.
(2) A tightening of the rules is considered a soft fork. Rules get tighter in the sense that blocks which were previously valid under the old rules are now considered invalid under the new rules. When the rules get tighter, old nodes will still be able to accept new blocks because they do not break any of the old rules, the new blocks simply follow a “stricter” rule set than before – this is known as backward-compatibility (old software is still compatible under new rules).
When it comes to soft forks, it is likely that there will be a convergence into 1 blockchain rather than a divergence into 2 separate blockchains, provided the majority of hash power enforces the new rules. Examples of what rules might tighten in a soft fork: reducing rewards, reducing maximum base block size, etc.
Consider the decentralized restaurant analogy:
The restaurant, in its current capacity, is operating as a vegetarian restaurant. In the kitchen, the restaurant has many chefs. Each chef pays for their own equipment as well as the electricity costs associated with running their equipment. In front of the kitchen are the cashiers, they are the ones who are taking orders. The customers are the ones ordering food and eating at the restaurant.
(1) Hard Fork: The chefs decide to add meat to the menu and change the fact that the restaurant is vegetarian – this is a hard fork. The rules are now looser and if customers want to continue eating at the same restaurant, they are forced to “upgrade” their diets and consume meat or else find a new restaurant to go to.
Translate this to blockchain terms: The miners have decided to loosen the rules by making valid what was previously invalid (making meat under the previous rules was invalid. The new rules dictate that making meat is now valid). Everyone must upgrade their systems in order to use the same blockchain. Blocks from non-upgraded systems and blocks from upgraded systems will be diverged into 2 separate blockchains.
(2) Soft Fork: The chefs decide to change from being vegetarian to having only vegan food on the menu – this is a soft fork. The rules are now tighter; however, meat-eaters and vegetarians can continue eating at the restaurant if they want to, but they will have to eat vegan food.
Translate this to blockchain terms: The miners have tightened the rules by making invalid what was previously valid (under the previous rules of vegetarianism, cooking with butter was valid, but under the new vegan rules, cooking with butter is now invalid). If the upgraded nodes have a majority of the network, non-upgraded nodes don’t have to upgrade to the new rules.
This is possible because the upgraded nodes will create a stronger chain than the non-upgraded nodes; however, the blocks in this stronger chain will not violate the old rules which are still used by the non-upgraded nodes, resulting in the non-upgraded nodes accepting blocks from upgraded nodes (you can feed vegan food to a vegetarian or meat-eater without breaking the rules of their diets).
Previously introduced were the concepts of hard fork and soft fork. Now combine these with miner activated and user activated to get the 4 ways a fork can be activated:
(1) Miner activated hard forks (MAHF):
A MAHF is a hard fork activated by the mining majority.
(2) Miner activated soft forks (MASF):
A MASF is a soft fork activated by the mining majority. A block signaling threshold must be passed in order for all the nodes to begin enforcing the new rules. This threshold is set so that new blocks must enforce the new rules once 75% of blocks within a 1000 block interval have the new version. Following this threshold is at 95% of blocks within a 1000 block interval. When the 95% threshold is reached, blocks with the old version will be rejected.
The idea is that miners should enforce the new rules to avoid mining blocks that could potentially be rejected by nodes who follow the new rules. Because of differing interests, it has become clear that miner activated soft forks are probably not the best way to enforce new rules. If miners want 1 thing and users want another, there is likely to be a chain split.
Using the restaurant analogy: A proposal is made to soft fork the restaurant from vegetarian to vegan. New food (blocks) must be vegan once 75% of food within a 1000 food (meal) interval have been cooked as vegan. Following this threshold is at 95% of vegan food within a 1000 food (meal) interval. When the 95% threshold is reached, food that isn’t vegan will be rejected.
(3) User activated hard forks (UAHF):
A hard fork activated when developers add a mandatory rule that changes the node software and does not require the majority of hash power. This makes certain invalid blocks valid following the flag day.
Using the restaurant analogy: The recipe writers (developers) decide to add a meat dish to the menu. This makes invalid recipes (ones containing meat) now valid following the flag day.
(4) User activated soft forks (UASF):
A soft fork that is activated when nodes (computers connecting to the Bitcoin network – users, exchanges, etc.) implement a new rule after a specified flag day. This type of fork requires overwhelming support, referred to as the economic majority.
Using the restaurant analogy: Customers (users) say that they are going to start ordering only vegan off the menu. “You don’t have to cook vegan, but we refuse to order anything you make that isn’t vegan.”
How to keep forks from being disruptive?
You need to have overwhelming consensus in order to keep forks from being disruptive. Consider the Bitcoin Gold (BTG) fork as an example. This highly controversial and unorganized fork had overwhelmingly divided consensus and thus resulted in battles within the community. At the time of this writing, BTG is still only traded in the futures market, and the price has already dropped over $400. The failure of BTG is only a hindrance to the Bitcoin brand and has not proven to be of any value to the long-term future for Bitcoin.
Blockchain expert Andreas Antonopoulos explains:
Users: If you hold bitcoin and there is a HF, you will now own bitcoin on both forks. You don’t need to do anything.
— Andreas (@aantonop) March 13, 2017
There’s just a few more things that users should know when it comes to forks and the actions they need to take.
First of all, it’s important to know how the storage of your cryptocurrency affects your holdings on both forks. If you own your private keys and store your coins on a hard wallet or some form of cold storage, you will have the same amount of holdings on both forked blockchains under the same private key.
If however, you do not own your private keys and hold your coins on an exchange (Coinbase, Bittrex, Binance, etc.) it is possible that they may not support the fork and this could cause a variety of issues.
The only real way to combat all of these issues is to do your research. Most exchanges will release information prior to a fork about how they plan on dealing with the fork. If you do not like their plans, it is your responsibility to move your coins to another exchange or into some other method of holding.
Secondly, users should research the proposals of a given fork and understand the issues and solutions being discussed. This is an optional step and shouldn’t have much of an effect on how an average user behaves, but the knowledge can’t hurt.
Finally, a user who is acting more like an “investor” should especially research the fork and investigate what implications it may have on the future of their “investment.” A fork is happening for a reason and that reason could be a long-term threat or it could be a long-term benefit to the underlying coin.
Bitcoin.org Developer Guide – An amazing resource for technical information about Bitcoin and blockchain technology in general.
Andreas Antonopoulos Explaining “Forkology” – This video is a great beginners guide to “forkology” – the study of forks. It’s very interesting and Andreas also introduces the restaurant anology used above.
Forks, Signaling, and Activation – a technical article about forks and how they work. This is a great read for those looking to dive deeper into how forks work, especially from a developer perspective.