Blockchain Software Upgrades And Forks

In the early morning of November 16, 2018, Beijing time, Bitcoin Cash (BCH) implemented a software upgrade. Unlike previous software upgrades, this upgrade was accompanied by many controversies and fierce confrontations. The opposition even intervened in the process with a "war" attitude. There are many articles on the Internet introducing this, including live broadcast of the event process [1] and in-depth analysis and interpretation of the background of the event [2].

This article attempts to analyze from a technical perspective what happens during the blockchain node software upgrade process, why forks occur, and the direction of the blockchain after the forks.

Why the split?

The node software hosts the consensus algorithm. When the software of some nodes is upgraded to a new version, because the consensus algorithms among them are not completely consistent, when faced with newly mined blocks, they will choose according to the requirements of their respective consensus algorithms. Incorporate the blocks you think are legitimate into the main chain. Therefore, different main chains will appear in the blockchain network, each main chain is supported by some miner nodes and new blocks are mined on it. This is a fork.

This article only discusses forks caused by differences in consensus algorithms. Forks caused by differences in network propagation speeds and other reasons are beyond the scope of the discussion.

There may be some degree of compatibility between inconsistent consensus algorithms, with different combinations determining the final destination of the fork.

Various situations of compatibility between old and new versions of software

What follows may be a little difficult to pronounce. For convenience of expression, we first define two abbreviations——

Old blocks: new blocks mined by old software

New block: new block mined by new version of software

YA: Any version will recognize the history before version upgrade

YB: Any version will recognize new blocks it mines

YC: Legacy software accepts new parts (with forward compatibility)

ND: Old software does not accept new parts (no forward compatibility)

YE: The new version of the software accepts the old part

NF: The new version of the software does not accept the old version

Note: Forward compatibility ( ) means that after a new version of the software is released, the old version of the software can still accept and process the data output by the new version of the software. For example, a file saved in Word 2013 can be opened and edited in Word 2011.

Why is it sometimes compatible and sometimes not?

The compatibility (YC/ND) between old version software and new version is often determined by the content of the version upgrade itself, such as capacity expansion (block size adjusted from 8M to 32M). At this point, the new part is illegal in the eyes of the old version of the software (ND); just like disabling an opcode after an upgrade, the new part is legal in the eyes of the old version of the software (YC).

The compatibility (YE/NF) of the new version of the software with the old version may be determined by the content of the version upgrade itself, such as capacity expansion, etc. At this time, the old version of the software is legal in the eyes of the new version of the software (YE); and if a certain part is disabled after upgrading the opcode, the old block is illegal in the new version of the software (NF). But NF may also be just an upgrade strategy choice, such as hoping to force an upgrade, which will be discussed later.

Situations faced by different software versions in 4 upgrade scenarios

Comparing these four scenarios, they are symmetrical:

S1 and S4 are completely opposite scenes. S1 means that the two versions accept each other and play happily together; S4 means that the two versions do not accept each other and go their own ways.

For the pair S2 and S3, if we put aside the inheritance relationship between the new version and the old version, treat them as two independent versions A and B. In fact, they are the same situation, one version accepting the other one-way.

Suppose A accepts B, but B does not accept A, then:

Both forks are legal to him, and he will accept the longest chain as the new starting point for his work.

New blocks mined can only be accepted by miner nodes of the same type (also using version A). If the number of similar nodes in the network (not computing power!) is not dominant, then the new blocks mined cannot be effectively propagated and will be ineffective.

Only one of the two forks can be accepted as a starting point for your work. All similar miner nodes can only stubbornly stick to this fork.

If the computing power of similar miner nodes dominates the network, it will eventually replace another fork.

As long as you don't give up, your cross will never disappear and the efforts you put in will still be valid.

The difference between hard fork and soft fork

S2 and S3 also have forks. Why is one soft and the other hard? It is understandable that it is precisely because of the "new/old" comparison that this difference is caused. Forward compatibility of older versions of software is a watershed between the two [3]. A fork occurs when some nodes are upgraded to a new version. The hardness of the fork is based on the angle of the old version of the node.

In the S2 scenario, old version nodes will consider both forks to be legal. According to the previous logic, both forks will be treated equally, and the longer one will be accepted, so this fork is "soft".

In the S3 scenario, a fork is illegal and the old version nodes will definitely not accept it, so this fork is "hard".

When a miner node using an older version of the software faces a hard fork, it must make a difficult decision: stick with its version or update to the new version. For example, when BCH and BTC parted ways, some miners chose to stick to the original chain and continue to run BTC; while other miners chose to update to the new version and switch to another chain, which means entering a new chain. The world of forked coins.

Of course, after the hard fork, which chain can continue to enjoy the original name is not a technical issue, but is determined by the recognition of the community (the recognition of the exchange). For example, when BCH forks from BTC, the original chain continues to enjoy the name BTC, and the forked chain is BCH; and for several important hard forks in the history of BCH, the forked chains continue to use BCH. This name, the original chain has been abandoned; BCH has just completed a hard fork. The current basic conclusion is that the new chain generated by the ABC version of the Wu Jihan camp can continue to enjoy the name of BCH, while the BSV version of the CSW camp will Stick to the original name chain and become a forked currency. It remains to be seen how the forked currency will develop, but there is a high probability that it will not have the name BCH.

The difference between two hard forks

In both scenarios, S3 and S4, neither of them accept new blocks from the perspective of the old nodes, so they are both hard forks. But for the new version of the node, whether it can accept the old version, the results are different.

As the leader of the hard fork, his purpose is to promote the new version of the software, hoping to end the transition period as soon as possible. Based on this appeal, ND+NF (new version software does not accept old versions) will have more advantages than ND+YE (new version software accepts old versions).

NF or YE (will new versions of the software accept the old parts)? As mentioned earlier, this matter may depend on the content involved in the software upgrade itself, but sometimes the changes in the upgrade do not exclude the old version (such as capacity expansion), so whether to accept the old version can be a strategic choice. The leader of an upgrade (hard fork) often integrates with the provider of the new version of the software, and they can make favorable arrangements for themselves in the new version of the software.

Imagine an extreme situation. Suppose Wu Jihan wants to support the ABC team to complete the hard fork upgrade. The mining pool controlled by Wu mobilized 50% of the computing power of the entire BCH network to activate the new version of the software, while all other miner nodes temporarily stayed on the old version. On the software.

If the new version of the software chooses the YE method, although Wu Mining Pool has a 50% probability of being the first to dig out a new block, no one will spread it for him. He is the only one working on this fork, while other nodes are mining another fork. Once which fork length dominates, Wu Kuangchi will accept that fork and continue working, effectively scrapping his previous work.

In order to ensure there is no waste, you must ensure that your unique fork always has an advantage in length (maintaining more than 50% of the total network computing power) and wait for the situation to change (more miner nodes have been upgraded to the new version).

If the new version of the software chooses the NF method, it will be much simpler. Wu Mining Pool will not accept other forks and will focus on mining its own forks. If its computing power accounts for a low proportion of the entire network's computing power, it will not cause your fork to be eaten, and you can wait for changes to come more calmly.

Therefore, from the perspective of leaders, especially those who invest in computing power support, choosing NF will make the upgrade process simpler and more direct, reduce variables, and avoid economic losses. Of course, this is also a point of no return. Although the amount of work you put into this fork will always remain valid, if the fork is eventually abandoned by the market, all your investment will be reduced to zero.

The upgrade implemented by BCH on November 16, 2018 included two updates:

1) Add standardized transaction ordering (CTOR) to transactions within the block;

2) Add two opcodes (and Y).

Through simple analysis, it is not difficult to judge. The first one is YC+NF, the second one is ND+YE, and together they are ND+NF, so this is a hard fork belonging to the S4 scenario.

In this case, after the fork, the two chains will go their own ways, and neither will "eat" the other. Why spend a lot of money and mobilize a lot of computing power to conduct this kind of aerial battle? I think there may be two reasons for this:

The first is to compete for the naming rights of BCH. After the fork, which chain is the authentic BCH and which chain is the forked currency? The general convention is that "longest chain" wins. At present, it seems that the Wu camp has achieved its expected goals. (Note: The longest chain here refers to the maximum cumulative difficulty, not simply the height of the blockchain)

The other is "Dharma Protector". The opponent of this hard fork, CSW, is aggressive and promises to attack the new chain. When a new chain is born, its status in the world is unstable, so computing power needs to be mobilized for protection. However, so far, no obvious signs of attacks have been reported on the new chain. As the new BCH status stabilizes and is widely accepted by the community, CSW will have to withstand greater social pressure if it wants to launch attacks under its real name.

refer to

[1] Bitcoin Cash completes hard fork! ——Wu Jihan vs. Satoshi Omoto——Process Record

[2] Liu Changyong: The war and evolution of BCH

[3] Slit

@/上--和-fork-

标签： #Fork #New version #Section #Node #Block