Forks, and why we use them
The word “fork”, used as a noun, has always been used to describe an object/instrument that has two or more prongs protruding from the end, used for holding or lifting. The origination of the word (Middle Eastern “forke”, Old English “forca”, and Latin “furca”) seems to be slightly muddled, but the meaning is clear on all accounts. As a verb the word pulls from its physical presentation to simply describe similar abstract situations: to divide into branches, to go separate ways, to be inconsistent, and to have a disagreement among witnesses.
When expressing the word in reference to software code, all of these definitions are relevant.
For the remainder of this post, the word “fork” is going to be used to describe what a software fork is, why someone would fork software, what a blockchain fork is, and differentiate the different types of forks used to fork blockchain protocols.
What is a fork?
A software fork is a distinct and separate piece of software created by taking the existing source code of a software package and making a copy for independent development. This most often occurs with open-source software due to developers fear of violating copyright law and accessibility of the source code, but licensed forks of proprietary software also occur. Why does this happen?
There are many reasons why a developer or group of developers would decide to fork a piece of software:
- Work on bug fixes of the current version to push out on the next update
- Original developer halting development
- Original developers ceasing support for a particular function
- To test a piece of peripheral software being developed for compatibility before going live
- Ideological divide between developers
- Upgrade software with functionality not offered by original developers
- Repurpose the software for a different use case or audience
- etc…
This is all relevant because blockchain protocol forks occur when there is a change to the software client the miners and/or node operators are running. Since most of the blockchain development has been focused around open-source development, we see forks occur frequently and for many of the reasons previously stated adding the ability to roll back a hack or catastrophic bug to an earlier time and restore with preventative measures in place. In reference to the blockchain, there are two classifications of forks.
Accidental vs Intentional
The two classifications of forks are accidental and intentional forks. Accidental forks occur when multiple miners find a block at nearly the same time. This causes a slight divergence for miners, having multiple blocks with the same block height, forcing them to choose which blockchain to continue to mine. As one blockchain grows longer than the other(s) It again becomes the default chain and the other blocks that don’t exist within that chain are orphaned due to hash rate fleeing their host chains for the default chain supported by the core software client.
Intentional forks, on the other hand, occur due to similar reasons as the software forks discussed above.
There two different types of intentional forks: hard forks and soft forks
Hard Fork
Hard forks occur when a core software update is not recognized by all of the nodes validating transactions within the blocks. Blocks produced based on the updated rules will be viewed as invalid by the nodes running older software. When this occurs two separate chains emerge, creating two separate assets underlying the chains as we saw with Etherum and Ethereum Classic, and then with Bitcoin and Bitcoin Cash. When this occurs both chains have a similar history, but they can not be re-merged. Although, nothing stops all of the nodes supporting the newer software from returning to the old software or visa-versa effectively killing the fork.
Soft Fork
Unlike hard forks, soft forks are backward-compatible causing the blockchain to stay consistent for most participants even if they do not update their software. Old software is typically abandoned over time and no new asset is created. Eventually, a node running much older software may not recognize the most recent blocks causing the chain to split, but all blocks produced by those chains will be viewed as invalid. There are two different ways recognized to enforce a soft fork:
- User-Activated Soft Fork (UASF) occurs when a soft fork is activated on a specified date, enforced by full node operators forming an economic majority, and doesn’t require majority miner support. The miner still produces valid blocks within the chain and are rewarded the base asset, but the full node operators may only validate transactions that adhere to the newer software.
- Miner Activated Soft Fork (MASF) occurs when a soft fork is activated by a miner majority. This allows for a faster activation time for the soft fork and does not require full nodes to upgrade immediately.
Starting a New Coin
Most blockchain projects with new coins are the result of forking an existing blockchain’s codebase that was deployed pre-Genesis block. The codebase is modified to fit the needs of the new developers, generally creating a new asset to reward miners: deployed in the “coinbase”. The coinbase, a term to describe the original transaction of the Genesis block, contains the mining input data for generating new blocks. This new coin and protocol are not compatible with the infrastructure supported by the nodes of the forked chain and share none of that chains transaction history.
Everest
The Everest project — with two new tokens (ID & CRDT), our own blockchains, our specific governance, and our own goals — is the result of forking the “codebase” or code repository, and modifying it to be compatible with the goals of our project. We started with two private instances of the Ethereum blockchain and will continue to make modifications to optimize performance, security, and meet the needs of our unique network architecture.
Learn more at https://everest.org
