Hard Forks and Changing Consensus Rules
In this article, we learn about hard forks and the impacts of changing the consensus rules in blockchains.
Table of contents.
- Introduction.
- Hard Forks.
- Software, Network, Mining, and Chain Forks.
- Summary.
- References.
Introduction.
In blockchains, consensus rules are used for validating transactions and blocks. These rules when adopted by all full nodes for validating blocks usually result in similar outcomes, meaning that if a node mutates a transaction or block thereby breaking the consensus rules, the outcome will differ from other nodes making it invalid.
Consensus rules may vary in the short term but must always be consistent across all network nodes to produce similar outcomes in the long run.
Upgrading or changing consensus rules is very difficult compared to changing the code itself since it requires all participants to agree.
When new rules are implemented in the blockchain, there will be a period where some nodes adopt the new rules and others continue using the old rules. In such cases, there are two known ways in which consensus can break;
- First, blocks using the new rules are accepted by nodes using the same new rules and are rejected by nodes using the old rules.
- Secondly, blocks violating the new rules are rejected by upgraded nodes and accepted by non-upgraded nodes.
Hard Forks.
In the article on blockchain forks we learn that a fork is when the main chain splits into two or three(very unlikely) due to reasons such as network delays or two miners solving the cryptographic puzzle at the same time. We also learned how the network reconverges to form a single chain with the most cumulative proof of work.
Apart from splitting the network into two chains, hard forks can also cause a change in the consensus rules. Unlike soft forks which leave network nodes backward compatible, hard forks require all nodes of the network to upgrade otherwise they will be invalidated and no longer be able to participate in the blockchain.
Consider the following image demonstrating a blockchain with forks;
Above we have two forks, one is at block 4 and the other at block 6. In the former block height, we see a reconvergence brought about by block 5, now the fork is resolved. As the chain continues to grow, we have another fork at block height 6. Here we assume a new Bitcoin client is implemented. Now, all nodes need to upgrade their client software in order to participate. Miners who upgrade their software now mine transactions with this new consensus protocol that can with the client and we have resulting block 7b with such transactions.
Any miner that refused to upgrade their client won't be able to process such a transaction. In their perspective, the transaction or block is invalid because they use old consensus rules.
These miners continue to mine and produce block 7a, here all transactions will be valid since they are based upon old consensus rules used by the miners.
In this case, there are no reconvergences. Miners in chain b accept and mine blocks using new consensus rules while miners in chain a reject them and mine transactions to form chain a. Each set of miners sees the other blocks of their counterparts as orphan blocks.
Software, Network, Mining, and Chain Forks.
In software development terms, a fork(software fork) is an occurrence when a group of developers forges a very different path from the original software development roadmap of an open-source project. In blockchains, hard forks can come as a result of bugs found in the old consensus rules or the deliberate changing of the existing consensus rules.
For a hard fork that comes about as a result of deliberate changing of the rules, a new software implementation is required whereby agreeing miners must adapt and change their existing clients.
In Bitcoin, the software includes Bitcoin Classic and Bitcoin Unlimited among others. Note that these did not result in a hard fork. For hard forks to occur the new implementation must be adopted and new rules activated by miners, wallets, nodes, and all other existing infrastructure forming the blockchain. Nevertheless, we can have multiple implementations of Bitcoin Core or software forks that don't change the consensus rule and coexist without causing a hard fork.
Consensus rules can differ in many ways for example how they validate transactions or blocks, and how they are applied to bitcoin scripts and digital signatures among others.
A hard fork develops in four stages, these are a software fork, a network fork, a mining fork, and a chain fork. Hard forks start when there is an alternative implementation of the client that has different rules. When deployed, some miners, wallet users, and intermediate nodes might adopt and execute it. The resulting fork depends on whether the rules apply to transactions, blocks, and digital signatures among other network aspects.
For example, if the fork is applied to blocks, then the fork process starts when a new block is mined under the new rules. If the fork pertains to transactions on the network, then the wallet that created the transaction precipitates a network fork followed by a hard fork when a transaction is mined into a block.
In the beginning, the network will fork, then nodes that are based on the previous consensus rules reject any transactions created with the new rules. Also, the nodes that work under the old rules ban and invalidate the nodes implementing the new rules.
In this case, the network splits into two chains. Here the old nodes connect to old nodes using old rules and new nodes connect to new nodes using new rules.
When a miner using new rules mines a block, the mining power and chain also fork. The resulting partitioned network makes sure that miners operating on old rules don't receive blocks mined using the new rules and miners operating on new rules don't receive blocks from miners using old rules.
Summary.
Consensus rules are used for validating transactions and blocks. When used by every node in the chain, it is expected that all nodes come to the same conclusion. If a node doesn't come to the same conclusion, then it is rejected by other nodes.
Soft forks are backward compatible meaning old and new nodes can still participate and communicate with each other, hard forks require all nodes of the network to upgrade otherwise those that don't are invalidated and can no longer participate in the blockchain.
Hard forks that come as a result of deliberate changing of the rules require new software implementations whereby agreeing miners change their existing client software.