You Always Remember Your First Fork
• 15 min
• 15 min
We’re hoping you’ve recovered from the last few economics adventures, and glad to see you’re back for more! We’ll try to keep this WBS on the less technical side, though this topic is deceptively simple. So sit back, relax, and enjoy some hard and soft forking (childish, we know).
The term “fork” originates from traditional software development; it’s when a subset of a team of developers working on an open-source project decides to change/update/add code that was not agreed to by everyone. The result may not be what’s best for the overall project: two versions of the source code that different sets of people are working on - hence the fork.
Go a little deeper here: Why Do Open Source Projects Fork? Or put on your scuba gear for this paper: A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes
Forking works similarly on a blockchain network, except that nodes and/or token holders (depending on voting rights), are the team and the changes are made to either the protocol or to the actual ledger (chain). On a fully decentralized network, any governance model can allow forks, and potentially have a negative impact on the original network - we’ll explain why that matters (to you) after the lesson in forking (ok, we’ll stop).
Just like with any regular software (like a phone app), blockchain network related updates are necessary from time to time - that’s a type of fork. Blockchain forks can be caused by three things: an accident involving blocks being processed at nearly the same time, an intentional divergence based on an agreed upon change to the protocol, or a disagreement among nodes related to which chain or protocol rules are the correct ones.
Quick definition: Block height is a number found within every block, signifying how many blocks came before it (the age, in blocks, of the chain). Additionally, once verified, it can be used by nodes to confirm whether or not a new block received from another node is really a new block (chronologically) or potentially part of a divergent chain (a fork).
In the case of an accidental fork, two different blocks with equal block height are processed and validated at almost the same time. One group of nodes adds one block to its chain, and another adds the other block. That results in the existence of two different chains, almost identical except the last block(s), and nodes basically choosing which one to acknowledge and continue adding blocks to. Most of the time, the correct chain is identified fairly quickly because it’s the one that the majority of nodes support. The fork is resolved when the less popular chain becomes stagnant due to decreasing node participation, and blocks added to that chain after the fork are “orphaned” and no longer valid.
Most forks are people driven processes; they are not automated functions. Non-accidental (intentional) forks can lead to separate chains and split networks (eventually distinct) when there is a divergence of opinion in regards to a protocol rule or general inability to reach consensus. For example, one subgroup of a network’s participants (nodes) may update their protocol and branch off by continuing the chain with blocks based on the updated protocol, and another group may stay on the old protocol and keep adding non-updated blocks like nothing happened. Keep in mind that in terms of the ledger, both resulting networks have identical versions of the chain up to the last block before the forking event - so the chain of token ownership and transactions is intact all the way back to the genesis block, it just splits after the fork. From the perspective of a node after a fork, their chain is the one correct chain (they don’t see or interact with two chains simultaneously).
As we wrote earlier, a fork can also be an intentional, agreed upon update to the network protocol - without resulting in two chains. In that case, there is still only one chain post forking, but the blocks may be different after the fork, so visually more like a single bent chopstick (good luck coming up with a better food analogy). The blocks may be different because a network protocol change may be related to block structure requirements, like block size, and the point where the chain starts to look different because the block structure has changed, is the fork. This part is very important! ANYONE can propose and put into effect a new or updated network protocol with the backing of the necessary number of miners or validators (nodes). Even if the update isn’t supported by the network founders, it’s still an “agreed upon” intentional fork if the majority supports it.
There are two types of intentional forks: hard forks and soft forks (for real).
Hard forks are usually the result of consensus/mining and block structure related changes. Because these changes are so fundamental, every single miner/validator (in some networks every “full node”) needs to run updated software to do anything block related. If a node doesn’t update, they will no longer be able to participate in mining, validation or adding blocks (since their blocks will be rejected by the updated nodes). In addition, their chain will no longer be correct, and new proposed blocks will appear invalid to them. However, if there are a bunch of people who decide they don’t want to update their node operating code, they can join together, stay on the old code and continue the old chain - essentially becoming their own network. That’s called a contentious hard fork. And in so doing, their transactions (and any token attached to them) will no longer be accepted on the updated network, resulting in two distinct tokens.
Soft forks are a lot less dramatic from a blockchain perspective, but they are tricky to understand at first, so don’t skim this section. Soft forks are caused by changes that don’t require everyone to upgrade to continue the “correct” chain post-fork, but a majority of nodes would need to be running updated software to validate and add blocks that complied with the update. Nodes who did not update would still see the correct chain, they could even propose blocks (which would get rejected), and theoretically, they can keep running the node, but economic incentives would probably push them to update. An example of a soft fork update may be something like an additional description field in the transaction message code - old nodes would see post-fork blocks, though likely without the additional piece of information. But, if they tried to propose a block without the additional field, it would be rejected.
Now some recommended reading, it’s tough not to include this post from Vitalik Buterin.
Check out Bitcoins wiki for a concise definition of hard and soft forks within their network.
One of the better diagrams about accidental forks - pay particular attention to the top left text
And then there’s this great hand-drawn visualization of what happens when blocks are mined at almost the same time.
Bitcoin and Ethereum (and many others) have had numerous hard and soft forks. Here are a great infographic and explanation.
There is a massive amount of info on this topic if you’re interested, just Google it! Forking is one of those things that takes research and time to get comfortable with, and it really helps to see some examples of forking (miner* pun intended).
*extra points for using the word miner
Ok, let’s circle back and understand why this is an important consideration for blockchain securities investment. Forks (contentious hard ones) have the potential to create a completely new token or network currency, based on a new network protocol. These types of forks can be considered negative from the perspective of network stability, token economy, and long term network growth - for the original network, of course. But, blockchain technology is meant to be (brutally) efficient, so either the network keeps evolving or it perishes. This type of thinking is at the root of blockchain network rules (and people), so there is a perspective from which all types of forks are considered natural and must occur to keep a network competitive. As a token holder, an investor may find the value of a token decrease if, for example, the network or chain with the “new” token becomes more popular among validating or full nodes (note: there are also “read-only” nodes). Therefore, looking at the governance model of a prospective blockchain company’s network is very important when doing your due diligence. Consider whether their protocol allows any node to initiate forks, how voting occurs, their consensus mechanisms, and whether their blockchain is truly decentralized and/or permissionless. A public decentralized chain has a higher probability of forking.
Thathathathathat’s all folks! Our apologies to the readers who would have preferred more humor related to soft/hard forks and forking - maybe if there’s enough of you, we can contentiously hard fork the WBS into WBSoriginal and WBSfunny...just kidding. See you next week!