Original Author: Johan

Blockchain forks are divided into soft forks and hard forks.This article focuses on hard forks, a method of software upgrades that do not support backward compatibility.Hard fork is the split or change of consensus. Consensus is the algorithm for each node in the blockchain system to achieve data consistency. Under normal circumstances, each node needs to run the algorithm with the same rules. For example, Bitcoin runs based on PoW (workload Proof) consensus, Ethereum used to be a PoW consensus, and recently switched to the PoS consensus algorithm through "The Merge".

There are many reasons for bifurcation, which is a very common phenomenon in the blockchain, usually a short-distance bifurcation, which is related to the consensus algorithm. Sometimes competing blocks appear at the same height, but in the end there are blocks will be discarded and only one block will be kept. But the hard fork is different. This kind of fork is planned and purposeful. Some node clients have deployed different program versions from the original network. The blocks produced can only be verified on the forked chain and cannot be verified by the original network. The network accepts and does not accept blocks from the original network. For example, the recent popular EthereumPoW (ETHW) fork.

first level title

Network layer

Since the forked chain is a blockchain independent of the original network, it first needs to be isolated at the network layer (P2P):

1. Seed node

The seed node, also called bootnode or seednode, is the node that the network will first try to connect to when the blockchain starts. When the forked chain is started, it first connects to the nodes in the seed node list, so as to further discover other peer nodes in the network, and then it can further synchronize the blocks and reach a consensus. Therefore, the list of seed nodes must be modified to prevent nodes from connecting to the original network.

2. Alien attack

Even if the list of seed nodes changes, it does not mean that the forked network will not be connected to the original network, because the P2P protocol of both parties is the same, if a node accidentally adds a node connection of another network, then the two nodes will The handshake is successful, and the other party is added to the node address pool. Not only that, the nodes of both parties will also share the addresses in their own nodes with each other, which will cause mutual pollution of the node pools of the bilateral networks. Regarding this issue, SlowMist has previously disclosed separately"Conflicting Public Chains! Alien Attack Vulnerability from P2P Protocol"。

In order to solve the problem of mutual pollution of address pools, it is necessary to perform network identification on the communication protocol. Early Ethereum did not support network separation, but in subsequent versions, NetworkID was added to the protocol as a sign of network distinction. NetworkID is usually the ChainID of each chain. For example, the NetworkID and ChainID of the Ethereum mainnet are both 1, while In the initial version of ETHW, NetworkID was not forked, and there may be an alien attack vulnerability.

first level title

consensus layer

1. Transaction isolation

Usually when interacting with the blockchain, we need to sign a transaction with our own private key, and then the transaction is broadcast to the network and packaged into a block by miners or block producers. But if there is a fork in the blockchain, the transaction may be packaged into different blocks by the two networks. Assuming this is a transfer on the original chain, then there will be the same transaction on the forked chain. Transfer, obviously this is an unexpected behavior, will cause asset loss.

At this time, it is necessary to protect the replay of the transaction. In the early version of Ethereum, there was no such protection. Later, after EIP155, ChainID was added to the transaction structure to ensure that the transaction signed by the user is only used in the current network. If Ethereum is forked, the ChainID also needs to be redefined. Of course, this is not as simple as just modifying the ChainID in the configuration, because the forked chain needs to be compatible with the old blocks, so it needs to be after the fork height Only by using the new ChainID can the normal operation of the forked chain be guaranteed.

ChainID does not exist in Bitcoin's transaction structure, so how does it do replay protection? Bitcoin uses a model called UTXO. Simply put, it spends a transaction (UTXO) instead of an account. Usually, there will not be two identical transactions in a newly launched network, and there will be no replayed scene.

However, in the case of hard forks, there will still be transaction replay problems, such as the BCH fork in 2017 and the later BSV fork. By adding SIGHASH_FORKID (0x40) to the transaction data signature of BCH, the transactions on BCH and BTC are no longer compatible with each other, so as to achieve the purpose of replay protection.

2. Computing power adjustment

Before the fork, the original chain occupies all the computing power of the entire network, so according to the PoW consensus algorithm, the calculation difficulty of its block generation is relatively high. After the fork, the computing power is distributed to different blockchains, and the forked chain usually cannot obtain enough computing power to produce new blocks due to insufficient consensus, and the growth of blocks will stagnate. At this time, it is necessary to reduce the initial calculation difficulty after the fork, and win a time window for the fork chain to quickly adjust the computing power.

3. Prevent 51% attacks

The network and transactions are isolated, the blockchain is forked, new blocks are produced smoothly, and everything seems to be normal. However, the security problem is still outstanding, and there is still a more common and more difficult to defend attack: 51% attack.

Mining is profit-seeking. When there is a fork coin, the miners on the side with the highest mining income will switch their computing power to that network. However, the reality is that the fork coin often has a low currency price, resulting in a very low overall computing power. . Taking the ETHW fork as an example, we can see from 2miners that the peak computing power of the original ETH network exceeds 900TH/s, while the computing power of ETHW is only about 30TH/s at the time of writing. The disappearance of a large amount of computing power is not a good thing. A 51% attack on ETHW can be launched at any time.

application layer

application layer

We classify applications based on transactions, such as smart contracts based on virtual machines, into the application layer. When the blockchain is forked, it will also have a huge impact on the applications running on the blockchain.

1. Signature replay

Signature replay is the same as the transaction replay mentioned above. Some contracts, such as Gnosis Safe, will verify the user's signature in the contract. replay on each chain, resulting in asset loss.

2. The oracle fails

Most of the smart contracts in the blockchain after the fork can still run normally, such as Token contracts and AMM contracts. These self-running systems can run stably without relying on off-chain data, but lending systems like MakerDAO are highly dependent on the price of the oracle Data, after losing the price feed support off the chain, it will not be able to continue to operate.

3. Dramatic price changes

The blockchain is forked, and an application runs on two chains at the same time. Which chain should the user use? Which one is "orthodox"? This question comes back to the consensus. Usually which blockchain has an orthodox consensus, then the assets on it will retain the original value consensus, while the assets on the other blockchain will lose their value in an instant.

Summarize

Summarize

So far, we have analyzed the security of blockchain forks from the network layer, consensus layer, and application layer, and we can see the technical risks that exist. We need to be very cautious about forks. Moreover, behind many forks is not only the need for technological change, but some may have direct commercial interests. For example, the initiator directly obtains a large number of forked coins in the fork. These require users to accurately understand and avoid unreasonable necessary loss.

The blockchain is a decentralized system, and its upgrade does not depend on a single individual or organization, so forks are unavoidable in the blockchain. Although it brings confusion to community users, it also promotes the development of the system to better serve the society.