Editors Note: This article comes fromEditors Note: This article comes fromlast term
last termAdvantages and hidden dangers of the heaviest chain ruleAdvantages and hidden dangers of the heaviest chain rule
, we introduced the strong potential of the heaviest chain rule in shortening the confirmation time.
But we also mentioned that when judging whether a block is confirmed by the heaviest chain rule, one of the prerequisites is that the block is a common ancestor (Note: If honest miners agree that a block is in their main chain , then we call this the common ancestor of all honest miners).
In the tree graph structure, we do not require the block to be confirmed to be the common ancestor, but the main chain block in the epoch where the block to be confirmed is located is the common ancestor.
Ethereum adopts a variant of the heaviest chain rule, and we take Ethereum as an example of the actual deployment of the heaviest chain rule.
In Ethereum, we can see that most blocks have entered the main chain, and then only need to wait for a few minutes or even less time, all newly generated honest blocks will appear in the subtree of this block. That is, this block becomes the public ancestor. All new honest blocks then make a concerted effort to increase its subtree weight. This makes it impossible for an attacker with a small amount of computing power to foster a brother as a competitor.
After the public ancestor block has accumulated enough advantages, the block is confirmed.
In Confluxs experiments, without attack, each block can become the common ancestor within about ten seconds, or enter the epoch of the common ancestor. If the block is produced quickly, it will be confirmed in a short time.
All is well and good, however, some attack strategies can prevent new blocks from becoming common ancestors. That is to say, the attacker has no ability to reverse the block that has become the public ancestor and has been confirmed.
However, the attacker has the ability to make the honest nodes disagree on who the next public ancestor block is, thus causing the honest nodes to fall into a protracted crown prince dispute. After that, any newly generated block cannot be confirmed by all honest nodes.
This kind of attack that does not aim at double-spending confirmed transactions to prevent new transactions from being confirmed is called survival attack.
So far, there is a survivability tool strategy that has been discussed more publicly, which we call balanced attack.
The idea of the balance attack is very simple, that is, the attacker fosters two evenly matched children under the last common ancestor block, that is, tries to maintain two subtrees of the same size.
Through the influence of the block network transmission, the attacker makes almost half of the computing power contribute to one of the subtrees, and the other half of the computing power contributes to the other subtree.
If the computing power on the two subtrees is close but not exactly equal, the attacker can use his own computing power to balance the gap, and finally achieve equal computing power on the two subtrees.
The honest computing power divided into two parts has become two opposing camps.
Two subtrees of similar size grow subtree weights at the same average rate.
Under the deliberate influence of the attacker, after each block is generated, it will be seen by the nodes of its own camp within a short period of time, but it will take a while before it can be seen by the nodes of the other camp. The weight of ones own subtree is slightly larger, and then continue to contribute computing power on the subtree of ones own camp.
This is a dilemma created by the attacker.
If the attacker only balances the computing power and the network of the two subtrees, and does not perform the operation of hiding blocks, the honest nodes still have the ability to break this dilemma.
Because the mining process always has some randomness, one of the camps will dig out more blocks in a period of time.
However, assuming that there are on average n blocks in the network that are being broadcast but have not yet spread to all nodes, the time needed for honest nodes to break this dilemma is n squared.
Under a given network delay, every time the speed of block generation is doubled, n will also double accordingly, and the time for honest nodes to break the deadlock by themselves will increase quadratically.
And if the attacker still digs some blocks on each branch to hide, then every time the honest node is about to break the trap, the attacker can actively intervene and release some blocks hidden on the weak branch to continue Maintain balance (just like the traitor in Three Kingdoms).
Through some analysis, it can be concluded that when the block generation speed is fast enough, even an attacker with a small computing power has a certain probability that honest nodes will never be able to break through this dilemma.
As the designer of the consensus mechanism, how should this problem be solved?
Its very simple, like Bitcoin, slow down the block production speed and reduce the value of n. If it takes 10 seconds to spread a block across the entire network, and the block generation time is 10 minutes, when the attacker does not perform the hide block operation, there is a 59/60 probability that a new honest block is generated, and the network There are no other blocks being transmitted, the local tree graph structure of all honest nodes is consistent, and there is no situation where honest nodes are in two camps.
Even if the attacker has a stronger attack capability, he will find that in the case of slow block generation, the number of times he needs to intervene is greatly increased, and his own computing power is no longer sufficient.
We constructed a theoretical model.
In this model, the computing power of honest nodes is an average of n blocks per second, and all honest nodes are divided into two groups, and the computing power of both groups is equal. There is no delay for block propagation within the group, and there is a delay of d seconds for block propagation between groups.
In this way, the blocks received in each group are the same, and the blocks seen by the two groups are not exactly the same.
At the beginning, the two groups selected two different child blocks under the same parent block as the main chain blocks, and contributed weights under them, and the initial weights of the two child blocks were the same.
If at a certain moment, the child block selected by one of the groups is not dominant in its own local view, that is, when the group wants to turn over according to the heaviest chain rule, the attacker needs to release some blocks to avoid This matter, thereby maintaining that the two groups cannot agree on who is the next common ancestor. If the attacker cannot release the block, then the attack fails.
If the attacker wants the probability that the attack will never fail to be greater than 0, then the attacker needs to meet a minimum computing power requirement.
The figure below shows the minimum computing power requirements in the case of different d*n.
It can be seen that when the value of d*n is very small, the required latest computing power is close to n blocks per second, which is the block generation rate of all good people. At this time, the requirements for balanced attacks are no lower than those for double-spending attacks. When the value of d*n is very large, the required computing power approaches 0.
If we reduce the block generation speed low enough to make the value of d*n lower than 0.1, then it will be difficult for the attacker to launch this attack with a lower computing power (Bitcoin is not the heaviest chain rule, but we can Take the parameters of Bitcoin as an example. In Bitcoin, d*n is about 0.02.)
However, slowing down the speed of attacking blocks has violated our original intention - to create a PoW public chain with a very short confirmation time. This presents a dilemma.
Fast block generation: There is no security risk for confirmed blocks. The confirmation speed is very fast when no one is attacking, and it will never be confirmed when someone is attacking.
Slow block generation: It can also guarantee security, and can also ensure that transactions can be confirmed after a period of time when someone attacks, but even if no one attacks, the confirmation time will be very slow.
So far, the flaw of the heaviest chain rule (survival attack when the block is produced quickly) has almost completely covered up the jade of the heaviest chain rule (fast confirmation when the block is produced quickly).
So in this dilemma, is there a way for us to achieve both, the safety of slow block generation and the efficiency of fast block generation?
