Blockchain forks can be divided into two categories: soft forks and hard forks. Our primary focus here is “Hard Forks,” or upgrades to a network’s protocol that break compatibility with older versions of the protocol. A hard fork is a protocol change that invalidates the previous version of the blockchain. Blockchains are able to ensure data integrity across a distributed system by utilizing a consensus mechanism. In a typical setup, each node must execute the same algorithm according to the same set of rules. Proof of Work (PoW) is one such consensus mechanism, and it is used by cryptocurrencies like Bitcoin. Before “The Merge,” Ethereum used a Proof of Work (PoW) consensus algorithm. After “The Merge,” however, Ethereum adopted a PoS (Proof of Stake) consensus algorithm.
Several events can cause a blockchain to fork. As it happens, this is a common occurrence in blockchains.The majority of forks that occur are ‘soft’ forks where a previously valid block is rendered invalid. There may be competing blocks of the same height at times, but these blocks will eventually be abandoned, leaving only one block. Hard forks, on the other hand, are completely different. They are carefully planned and executed. Here, node clients deploy a version of the blockchain protocol that differs from the network’s original implementation. Since the original network is unable to verify or accept these new blocks, the forked chain is the only place they can be verified. For instance, the newly created EthereumPoW (ETHW) network cannot accept blocks from the forked ETH network because they operate using different consensus mechanisms.
Forking a blockchain is not as easy as it may seem; it involves more than just copying and making a few tweaks to the original code to assure its integrity. As a result, we have included a brief overview of various standard security concerns and countermeasures.
Network Layer
Since the forked chain is a separate blockchain from the original network, it must first be isolated at the network layer (P2P):
1. Seed Node
A seed node, also known as a bootnode, is the first node to which the network attempts connection to after the blockchain is launched. When the forked chain starts, it connects the nodes on the seed node list first. This enables it to locate its network peers and synchronize the blocks in order to arrive at a consensus. Therefore, it is necessary to change the seed node list so that new nodes cannot join the old network.
2. Alien Attack
Even if you modify the seed node list, you can still establish a connection to the original network. Because P2P protocols are generally used by both networks, it is possible for a node to become accidentally connected to a different network. In the end, the two nodes will synchronize, adding each other to their respective node address pools and thus polluting each other’s networks.To learn more about Eclipse attacks, check out our “Conflicting Public Chains! Eclipse Attack Vulnerabilities from P2P Protocols.”
To address the issue of mutual pollution of address pools, network identification on the communication protocol is necessary. Earlier versions of Ethereum did not support network separation. However, in subsequent versions of the protocol, NetworkID was included to serve as a means of distinguishing between networks. The NetworkID of each chain is also its ChainID. The NetworkID and ChainID of the Ethereum main network, for instance, are both 1, and the NetworkID was not forked in the first release of ETHW; however, this may leave the network susceptible to an eclipse attack.
Magic values are used to identify different networks on the Bitcoin network. These are typically specified in chainparams. The Bitcoin main network value, for example, is F9BEB4D9, and the test network value is FABFB5DA.
Consensus Layer
1. Transaction Isolation
We usually need to sign a transaction with our private key when interacting with blockchains. Miners or block producers then broadcast the transaction to the network and package it into blocks. If a blockchain forks, the transaction may be packaged into separate blocks by both networks. If this is a transfer transaction on the original chain, an identical transfer will occur on the forked chain, potentially resulting in double spend and asset loss.
At the same time, the transaction must be protected against replay. There was no such protective measure in earlier versions of Ethereum. Following EIP155, ChainID was added to the transaction structure to ensure that the user-signed transaction was only used on the current network. If Ethereum is forked, then the ChainID needs to be redefined. Because the forked chain must be compatible with the old blocks, we need to use the new ChainID after the fork height to ensure normal chain operation.
Since there is no ChainID in the Bitcoin transaction structure, how does it have replay protection? Bitcoin employs a model known as UTXO. To put it simply, it sends a transaction (UTXO) rather than an account. For the most part, no two transactions on a freshly launched network will be identical, so there will be no replay scenario.
However, there is still the issue of transaction replay in the case of a hard fork, such as the BCH fork in 2017 and the subsequent BSV fork. BCH achieved replay protection by appending SIGHASH FORKID(0x40) to the transaction data signature, rendering BCH and BTC transactions incompatible.
2. Adjustment of Computing Power
Before the fork, in accordance with the PoW consensus algorithm, the difficulty of the original blockchain was relatively high because it formerly possessed all of the network’s computing power. As computing resources were divided amongst the various blockchains in the wake of the fork, the forked chain was unable to amass sufficient resources to generate new blocks due to a lack of consensus, resulting in a reduction of the rate at which blocks were being added.
3. 51% Attacks
Concerns about security remain, such as protecting against 51% attacks, even after the network along with its transactions have been isolated, forked successfully, with new blocks produced and normal operation resumed.
The mining industry is profit-oriented. In the event of a fork in a cryptocurrency, miners will direct their processing power to a network that promises the greatest reward. Unfortunately, due to insufficient demand, the value of forked coins are typically quite low. If we look at the ETHW fork as an example, we can see from 2miners that the peak computing power of the original ETH network was over 900TH/s, while the peak computing power of ETHW is now only about 30TH/s as of this writing. Which leaves ETHW vulnerable to 51% attacks.
A 51% attack is nearly impossible to defend against, and the only way to mitigate the risk is to increase the amount of distributed computational resources.
Application Layer
Applications built on transactions, such as virtual machine-based smart contracts, are included in the application layer. When a blockchain is forked, the applications that run on it are significantly impacted.
1. Signature Replay
The signature replay is the same as the previously mentioned transaction replay. Some contracts, such as Gnosis Safe, validate the user’s signature in the contract. If the ChainID is not included in the signature, the signature will almost certainly be replayed on both chains, resulting in asset loss.
2. Oracle Failure
Most smart contracts in the post-fork blockchain, such as Token contracts and AMM contracts, can continue to function normally. These self-running systems can run without relying on off-chain data, but lending applications such as MakerDAO and other similar projects rely on Oracle price data. They are unable to function after losing support from the off-chain price feed.
3. Price Fluctuation
Which chain should a user use if a blockchain is forked and an application runs on both chains simultaneously? Which of these is the “correct chain”? This question brings us back to the point of consensus. When the new chain reaches consensus, the assets on it retain their original value, whereas the assets on the other blockchain lose their value instantly.
These drastic price changes will cause DeFi applications to completely collapse, and lending applications will never be able to close their positions. Some astute parties will seize these opportunities by exchanging “zeroed” assets via AMMs and other applications. We observed a large number of arbitrage behaviors on the forked chain in the ETHW fork event, with the main chain token retaining some value.
Summary
So far, we have investigated the security of blockchain forks at the network, consensus, and application layers. We can see the technical risks, and should remain cautious when it comes to newly forked blockchains. Furthermore, many forks are motivated not only by the need for technological change, but also by direct commercial interests. For example, the ability to generate a large number of tokens from a fork. It is critical that users fully understand this concept in order to avoid unnecessary losses.
Blockchains are a decentralized system, which means that their development is not reliant on a single person or group. As a result, blockchain forks are unavoidable. While it may cause some dissension in the community, it also encourages the system’s development in order to better serve its users.
