Security challenges brought about by blockchain forks

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. A hard fork is a split or change of consensus. Consensus is an algorithm for each node in the blockchain system to achieve data consistency. Normally, each node needs to run an algorithm with the same rules. For example, Bitcoin runs a PoW (workload) based algorithm. Proof) consensus, Ethereum used to be PoW consensus, and recently switched to PoS consensus algorithm through “The Merge”.

There are many reasons for bifurcation, which is a very common phenomenon in blockchain, usually short-distance bifurcation, which is related to the consensus algorithm. Sometimes there are competing blocks at the same height, but eventually there are The blocks will be abandoned and only one block will remain. But the hard fork is different. This is a planned and purposeful fork. Some node clients deploy a different program version 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.

Security challenges brought about by blockchain forks

It is not easy to successfully fork a blockchain. It is not necessary to directly copy the code of the original network. Basic modifications are required to ensure its safe operation. For this reason, we have summarized several common security problems and protection methods.

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

A seed node, also known as a bootnode or seednode, is the first node the network tries to connect to when the blockchain starts. When the fork chain is started, 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 and reach a consensus. Therefore, it is necessary to modify the seed node list to prevent 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 be connected to the original network, because the P2P protocol of both parties is the same, if a node inadvertently 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, thereby causing mutual pollution of the node pools of the bilateral network. Regarding this issue, SlowMist has previously disclosed “Conflicting Public Chains! Alien Attack Vulnerabilities from P2P Protocols”.

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

In the Bitcoin network, Magic values ​​are used to identify different networks, which are usually defined in chainparams. For example, the Bitcoin main 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, which is then broadcast to the network and packaged into blocks by miners or block producers. However, if the blockchain is forked, the transaction may be packaged into different blocks by the two networks. Assuming this is a transfer on the original chain, the forked chain will also have the same transaction. Transfer, obviously this is an unexpected behavior and will cause asset loss.

At this time, it is necessary to perform replay protection on 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, then the ChainID 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. Use the new ChainID to ensure the normal operation of the forked chain.

There is no ChainID in the transaction structure of Bitcoin, so how does it do replay protection? Bitcoin uses a model called UTXO. Simply put, it spends a transaction (UTXO), not an account. Usually, a newly launched network will not have the same two transactions, so there is no such thing as a transaction. replayed scene.

But in the case of a hard fork, there will still be transaction replay issues, such as the BCH fork in 2017 and the subsequent BSV fork. By adding SIGHASH_FORKID (0x40) to the transaction data signature, BCH makes the transactions on BCH and BTC no longer compatible with each other, thus achieving the purpose of replay protection.

2. Adjustment of computing power

Before the fork, the original chain has all the computing power of the entire network, so according to the PoW consensus algorithm, its block generation calculation difficulty 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, so as to 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. Yet security concerns remain prominent, and it remains a more common and harder-to-defend attack: the 51% attack.

Mining is profit-seeking. When there is a forked coin, the miners will switch their computing power to that network with the highest mining revenue. But the reality is that the forked coin often has a low 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 at the time of writing is only about 30TH/s. It is not a good thing to lose a lot of computing power. A 51% attack on ETHW can be launched at any time.

There is almost no good way to prevent this kind of 51% attack, and it can only be prevented by increasing the number of confirmations.

application layer

We classify applications built on transactions, such as virtual machine-based smart contracts, as 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

The 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 ChainID is not included in the signature, then the signature is very likely to be valid between two replay on the chain, resulting in loss of assets.

2. The oracle machine fails

Most smart contracts in the forked blockchain 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 machine. Data, it will not be able to continue to run after losing the support of the off-chain price feed.

3. Price drastic changes

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

Such drastic changes in price will lead to the complete collapse of DeFi applications, and lending applications will never be able to close their positions. Some people of insight will seize the time window of the fork and exchange “zeroed” assets through AMM and other applications. The main chain token, thus retaining some value, in the ETHW fork event, we observed a large number of arbitrage behaviors on the forked chain.


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

The blockchain is a decentralized system, and its upgrade does not depend on a single individual or organization. Therefore, 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.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-09-20 10:33
Next 2022-09-20 10:35

Related articles