In the standard software industry parlance, a software fork is just a copy of an existing project. Considering the current pre-eminence of open-source software development, a software fork can very often be carried out without explicit permission from the developer of the original project. In case of the blockchain, it is different. A blockchain fork is when a blockchain splits into two separate chains.
First, let’s revisit blockchain in an elementary manner. In this technology, a network of computers, commonly called “nodes” maintain a shared, verifiable, and immutable record of data. Two or more block records, commonly called “blocks”, are linked together while adhering to a predetermined protocol, in this distributed database. Each node has the complete information of the blockchain, and hence each node can be considered as a ledger. This is why blockchain is also often referred to as “Distributed Ledger Technology” (DLT). Unlike one central server, or any other method of ensuring every update goes through one central point of authority, every node in a blockchain has the same authority. Every node can add a new block if consensus on the validity of the transaction can be achieved. To achieve this consensus, a node has to carry out significant number-crunching operation at high speed to solve a cryptographic puzzle and provide evidence of that. This evidence is called “proof of work” (POW). In summary, to add a new block, a node has to achieve consensus, and it is here that the concept of fork enters our discussion.
Take for example a blockchain where the existing protocol mandates blocks of 1 megabyte (MB) size. “Miners”, i.e. a combination of user, software, and specialized hardware, in this blockchain will continue to follow this 1 MB mandate, so that they can get rewarded for their mining. What happens when a miner decides to create a 2 MB block instead? Initially the other miners will ignore this block since it does not conform to the rules. Remember that the other miners are looking for rewards, for which they will need to adhere to the rules. Let’s assume that our adventurous miner continues to create 2 MB blocks on top of the earlier 2 MB blocks he/she had created. If the other miners continue to ignore these blocks, then eventually the chain of the 2 MB blocks will be the shortest chain and will be orphaned by the network. If this is just one miner trying to break the rules, then the transgression will have a negligible economic impact in terms of whatever that blockchain is dealing with, for e.g. Bitcoin, Ethereum etc. Note that at this point there is already a split in the network, i.e. there are now multiple chains, one with 1 MB blocks and another shorter chain of 2 MB blocks. A fork has occurred!
What if 25% of the miners in the network feel that 2 MB blocks should be created instead of 1 MB ones, and start adding blocks on top of the 2 MB chain of blocks? Now we have a fork of a real economic significance!
Now, to actually change the rules in this blockchain and allow 2 MB blocks instead of 1 MB, we will need a “hard fork”. A hard fork is when the software is upgraded to introduce a new rule, and as a result, the network will no longer be compatible with the older software. If a miner continues to run the old software, then he/she will see the new transactions as invalid. In order to mine valid blocks in the new chain, an upgradation is must for that node. When Ethereum community was split over their decentralized autonomous organization (DAO) and became two entities, Ethereum and Ethereum Classic, it was a split over rules, and it was a hard fork.
On the contrary, let’s consider that some miners wanted to create 500 kilobytes (KB) blocks instead of the 1 MB ones in our blockchain. If this change is done, the nodes that did not upgrade will continue to see the 500 k blocks as valid, since 500 k is less than 1 MB, however, if these non-upgraded nodes continue to mine blocks, their new blocks will be rejected by the upgraded nodes. This is “soft fork”, and to implement this majority of hash power, i.e. majority of the computing power in the network, needs to support the change.
There can also be unplanned forks, which are usually results of not understanding the software complexity, or changes made without sufficient planning, review, and testing. These can cause serious security risks in the network.
To sum it up then, there can be different types of forks in a blockchain network:
- Soft forks – these invalidate previously valid blocks, and can cause security risks for non-upgrading nodes;
- Hard forks – make previously invalid blocks valid, and the non-upgrading nodes become incompatible;
- Unplanned forks – results of inadequately understood software complexity or rushed changes, and can cause serious vulnerability in the network.
Liked what you read? Checkout Byte Academy's Software Development and Intro to Python courses.
