Security challenges brought by blockchain branching

Blockchain forks are divided into soft forks and hard forks. This paper mainly discusses hard fork, a software upgrade mode that does not support backward compatibility.Hard bifurcation is the split or change of consensus. Consensus is the algorithm for all nodes in the blockchain system to reach data consistency. Normally, each node needs to run the algorithm with the same rules. For example, Bitcoin runs the consensus based on PoW (Proof of Workload). Ethereum was also a PoW consensus, and recently switched to the PoS consensus algorithm through "The Merge".

There are many reasons for bifurcation. It is a very common phenomenon in blockchain, usually a short distance bifurcation, which is related to consensus algorithm. Sometimes there are competing blocks at the same height, but the final block will be abandoned and only one block will be retained. However, the hard fork is different. This is a planned and purposeful fork. Some node clients have deployed different program versions from the original network. The blocks produced can only be verified on the fork chain and cannot be accepted by the original network, nor can they accept the blocks of the original network. For example, Ethereum PoW (ETHW), which is popular recently, is bifurcated.

If it is not easy to successfully split a blockchain, it is not enough to directly copy the code of the original network. Basic modifications are required to ensure its safe operation. To this end, we summarized several common security problems and protection methods.

network layer

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

1. Seed node

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

2. Alien attack

Even if the seed node list changes, it does not mean that the forked network will not connect to the original network, because the P2P protocols of both sides are the same. If one node inadvertently adds a node connection of another network, the two nodes will successfully shake hands and add the other to the node address pool. In addition, both nodes will share the addresses in their own nodes with each other, thus causing mutual pollution in the bilateral network node pool. On this issue, Slow Fog has previously separately disclosed Conflicting Public Chains! Heteromorphic Attack Vulnerabilities from P2P Protocols.

In order to solve the problem of mutual pollution of address pools, it is necessary to do network identification on communication protocols. Early Ethereum did not support network separation, but subsequent versions added NetworkID as a symbol of network differentiation in the protocol. The NetworkID is usually the ChainID of each chain. For example, the NetworkID and ChainID of the Ethereum primary network are both 1. However, the initial version of ETHW did not bifurcate the NetworkID, which may have a profiled attack vulnerability.

In Bitcoin networks, Magic values are used to identify different networks, which are usually defined in chainparams. For example, the Bitcoin primary network value is F9BEB4D9, and the test network value is FABFB5DA.

Consensus layer

1. Transaction isolation

Usually, when interacting with the blockchain, we need to sign a transaction with our private key, and then the transaction is broadcast to the network and packaged into the block by the miner or the outgoing node. However, if the blockchain bifurcates, the transaction may be packaged into different blocks by two networks. Assuming that this is a transfer on the original chain, the same transfer will occur on the forked chain. Obviously, this is an unexpected behavior, which will cause asset loss.

At this time, the transaction needs replay protection. In the early version of Ethereum, this protection was not done. Later, after EIP155, ChainID was added to the transaction structure to ensure that the transaction signed by the user is only used for the current network. If Ethereum is forked, the ChainID also needs to be redefined. Of course, it is not just simple to modify the ChainID in the configuration. Because the forked chain needs to be compatible with the old blocks, it needs to use the new ChainID after the fork height to ensure the normal operation of the forked chain.

The ChainID does not exist in the transaction structure of Bitcoin, so how does it perform replay protection? Bitcoin uses a model called UTXO. In short, it costs a transaction (UTXO), not an account. Generally, there will be no two identical transactions in a newly launched network, so there will be no replay scenario.

However, in the case of hard branching, there will still be the problem of transaction replay, such as BCH branching in 2017 and BSV branching later. BCH adds SIGHASH to the transaction data signature_ FORKID (0x40) makes the transactions on BCH and BTC no longer compatible with each other, so as to achieve the purpose of replay protection.

2. Calculation force adjustment

Before the bifurcation, the original chain has all the computing power of the whole network. According to the PoW consensus algorithm, it is also difficult to calculate the outgoing blocks. After the branching, the computing power is distributed to different blockchains. The branching chain usually cannot obtain enough computing power to produce new blocks due to lack of consensus, and the growth of blocks will stagnate. At this time, it is necessary to reduce the difficulty of initial calculation after bifurcation and win a time window for quick adjustment of calculation force for the bifurcation chain.

3. Prevent 51% attacks

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

Mining is profit oriented. When a forked coin appears, miners with high mining income will switch their computing power to that network. But the reality is that the forked coin is often cheap, resulting in very low overall computing power. Taking ETHW bifurcations as an example, we can see from 2miners that the peak computing power of the original ETH network exceeded 900TH/s, while at the time of writing, ETHW's computing power was only about 30TH/s. It is not a good thing that a large number of computing power disappeared. It can launch 51% attacks against ETHW at any time.

There is almost no good way to prevent this 51% attack. You can only prevent it by increasing the number of confirmations.

application layer

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

1. Signature replay

Signature replay is the same as the transaction replay mentioned above. There are some contracts, such as Gnosis Safe, which will verify the user's signature in the contract. If the signature does not contain the ChainID, then the signature can most likely be replayed on both chains, causing asset loss.

2. Oracle failure

Most of the smart contracts of the forked blockchain can still operate normally, such as Token contracts and AMM contracts. These self running systems can operate stably without relying on off chain data. However, lending systems such as MakerDAO are highly dependent on the price data of the oracle. After losing off chain price support, they cannot continue to operate.

3. Price upheaval

The blockchain is bifurcated. One application runs on two chains at the same time. Which one should users use? Which is "orthodox"? This problem returns to the consensus. Usually, which blockchain has the orthodox consensus, then the assets on it will retain the original value consensus, while the assets on the other blockchain will lose value in an instant.

This drastic change in price will lead to the complete collapse of DeFi application, and the loan application will never be able to close the position. Some people of insight will seize the time window of the bifurcation and exchange the "zeroed" assets into the main chain token through AMM and other applications, thus retaining some value. In the ETHW bifurcation event, we observed a large number of arbitrage behaviors on the bifurcation chain.


So far, we have analyzed the security of blockchain forks from the network layer, consensus layer and application layer, and we can see that there are technical risks. We need to be very careful about the forks. In addition, behind many forks is not only the need for technological change, but also the possibility of direct commercial interests. For example, the initiator directly obtains a large number of forked coins in the forks, which requires users to accurately understand and avoid unnecessary losses.

Blockchain is a decentralized system. Its upgrading does not depend on a single person or organization, so it is difficult to avoid bifurcation in the blockchain. Although it brings confusion to community users, it also promotes the system to develop forward to better serve the society.