NewsFlash Articles Data Fundraising BlockBeats Pro

Brief analysis of security challenges and protection methods brought by blockchain fork

Read this article in 13 Minutes

Slow fog summarized several common safety problems caused by bifurcation and protection methods.

原文标题：《慢雾解读 | 区块链分叉带来的安全挑战》

原文作者：Johan，慢雾安全团队

Blockchain forks are divided into soft forks and hard forks. This article focuses on hard forks, a software upgrade method that does 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, normally each node needs to run the same rules of the algorithm, for example, bitcoin runs on the PoW (proof of work) consensus, Ethereum was also PoW consensus, Recently switched to The PoS consensus algorithm with "The Merge".

There are many reasons for forking, which is a very common phenomenon in blockchain, usually short-distance forking, which is related to consensus algorithm. Sometimes there will be competing blocks on the same height, but eventually some blocks will be abandoned and only one block will be kept. However, the hard fork is different. This kind of fork is planned and purposeful. Some node clients deploy different program versions from the original network, and the blocks produced can only pass verification on the fork chain, and cannot be accepted by the original network, nor can they accept the blocks of the original network. Take the recent hot EthereumPoW (ETHW) fork.

It is not easy to successfully fork a blockchain. It is not necessary to directly copy the code of the original network, and basic modifications are needed to ensure its safe operation. To this end, we summarize several common security problems and protection methods.

The 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 seednode, also known as a bootnode or seednode, is the first node the network tries to connect to when the blockchain is launched. The fork chain starts by connecting nodes in the seed node list to further discover peers in the network before further synchronizing blocks to reach a consensus. Therefore, the seed node list must be modified to prevent connections to nodes of the original network.

2. Alien attack

Even if the seed node list changes, it does not mean that the bifurcated network will not connect to the original network, because the P2P protocol of both sides is the same. If one node inadvertently adds the node connection of another network, then the two nodes will successfully shake hands and add each other to the node address pool. In addition, the nodes of both sides will share the addresses of their nodes to each other, thus causing mutual contamination of the node pools of the bilateral networks. As for this issue, Slow Fog has previously separately disclosed "Conflicting Public chains! Alien Attack Vulnerability from P2P Protocol".

In order to solve the problem of mutual contamination of address pools, network identification is required on the communication protocol. Early Ethereum did not support network separation, but later versions added NetworkID to the protocol as a symbol of network separation. NetworkID is usually the ChainID of each chain. For example, the NetworkID and ChainID of the Ethereum main network are both 1. However, NetworkID is not forked in the initial version of ETHW, which may have alien attack vulnerabilities.

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

Consensus layer

1. Transaction isolation

Typically, when interacting with a blockchain, we sign a transaction with our private key, which is then broadcast to the network and packaged into a block by miners or blockers. However, if there is a fork in the blockchain, the transaction may be packaged into different blocks by the two networks. Assuming that this is a transfer on the original chain, there will be the same transfer on the forked chain. Obviously, this is an unexpected behavior, which will cause asset loss.

This requires replay protection for transactions, which was not provided in earlier versions of Ethereum, but ChainID was added to the transaction structure after EIP155 to ensure that transactions signed by users are only used on the current network. If you fork Ethereum, you also need to redefine ChainID. Of course, this is not as simple as modifying the ChainID in the configuration, because the fork chain needs to be compatible with the old block, so you need to use the new ChainID after the fork height, in order to ensure the normal operation of the fork chain.

ChainID is not part of Bitcoin's transaction structure, so how does it do replay protection? Bitcoin uses a model called a UTXO, which simply means that a transaction (UTXO) is charged instead of an account. Usually, the same two transactions will not exist on a newly launched network, so there will be no replay scenario.

However, in the case of hard forks, there is still the issue of trade replay, such as the BCH fork in 2017 and the BSV fork later. BCH can achieve replay protection by adding SIGHASH_FORKID(0x40) to the transaction signature, which makes transactions on BCH and BTC incompatible.

2, calculation force adjustment

Before bifurcation, the original chain occupies all the computational power of the whole network, so according to the PoW consensus algorithm, its block calculation difficulty is also relatively high. After a fork, the computational power is spread across different blockchains, and the forked chain usually cannot acquire enough computational power to produce new blocks due to a lack of consensus, and the block's growth is stalled. In this case, it is necessary to reduce the difficulty of initial calculation after bifurcation, so as to gain a time window for fast adjustment of calculation force.

3. Defend against 51% attacks

The network and the transaction are separated, the blockchain forks, the new block comes out smoothly, and everything seems normal. However, security is still a problem, and there is still a more common and difficult attack to defend against: the 51% attack.

Mining is profit-driven. When there is a fork coin, miners with high mining income on the side will switch their computing power to that network. But the reality is that the fork coin is often low in price, resulting in a very low overall computing power. Using ETHW fork as an example, we can see from 2miners that the peak value of the original ETH network exceeds 900TH/s, while the calculation power of ETHW is only around 30TH/s when writing, it is not a good thing that a large amount of calculation power disappears, as it can launch 51% attacks on ETHW at any time.

There are few good ways to defend against this 51% attack, except by increasing the number of confirmations.

The application layer

We refer to applications built on transactions, such as VM-based smart contracts, as the application layer. When a blockchain forks, it can also have a huge impact on the applications that run on it.

1. Replay the signature

Gnosis Safe, for example, verifies a user's signature in a contract. If the signature does not contain a ChainID, it is likely to be replayed on both chains, resulting in a loss of assets.

2, the prediction machine failure

Most smart contracts of blockchain after fork can still run normally, such as Token contract and AMM contract. These self-running systems can run stably without relying on off-chain data. However, credit systems like MakerDAO, which are highly dependent on the price data of the prophecy machine, will not be able to continue to operate after losing the off-chain price support.

3. Price upheaval

Blockchain forks, an application runs on both chains, which chain should the user use the application? Which is the "proper" one? The problem comes 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.

This drastic change in price will lead to the complete collapse of DeFi applications and the loan applications will never be able to liquidate their positions. Some people with insight will seize the time window of fork and convert the "zeroed" assets into main-chain tokens through AMM and other applications, thus retaining some value. In the event of ETHW fork, We see a lot of arbitrage in the bifurcated chain.

conclusion

So far, we have analyzed the security of blockchain fork from the network layer, consensus layer and application layer. We can see that there are technical risks, and we need to be very careful about fork. In addition, behind many forks is not only the need for technological change, some may have direct commercial interests, such as the initiator in the fork directly obtain a large number of fork coins, these need to be accurately understood by users to avoid unnecessary losses.

Blockchain is a decentralized system, and its upgrade does not depend on a single person or organization. Therefore, forks are inevitable in blockchain, which brings chaos to community users, but also promotes the system to move forward to better serve society.