In our last issue, The Advantages and Disadvantages of the heaviest chain rule, we looked at the powerful potential of the heaviest chain rule to reduce validation times.

But we also mentioned that in the heaviest chain rule, one of the prerequisites for determining whether a block is identified is that the block is the “common ancestor” of all honest miners (note: if an honest miner identifies a block in his main chain, then we call it the “common ancestor” of all honest miners).

In the tree graph structure, we do not require the block to be identified to be a common ancestor, but require the main chain block in the epoch to be identified to be a common ancestor.

Ethereum uses a variant of the heaviest chain rule, and we’ll use Ethereum as an example of the heaviest chain rule in action.

In Ethereum, we can see that most blocks go into the main chain, and then just wait a few minutes or less for all the newly generated honest blocks to appear in the subtree of that block. In other words, this block becomes the common ancestor. Then all the new honest blocks work together to increase its subtree weight. An attacker with a small amount of computing power can no longer “foster” a sibling as a competitor.

Once the common ancestor block has accumulated enough advantages, the block is identified.

In Conflux’s experiment, each block could become a common ancestor or enter the epoch of the common ancestor in about ten seconds without attack. If the block speed is fast, it will be confirmed in a very short time.

All seems fine and dory, however, some attack strategies can prevent new blocks from becoming “common ancestors”. That is, an attacker has no ability to reverse an identified block that has become a common ancestor.

However, the attacker has the ability to keep honest nodes from agreeing on who the next common ancestor block will be, leading to a protracted “crown prince battle” between honest nodes. After that, any newly generated blocks cannot be verified by all honest nodes.

This kind of attack that does not aim at the double spending confirmed transaction to prevent the new transaction from being confirmed as the purpose, we call “survival attack”.

One of the most publicly discussed strategies so far is a live tool strategy we call “balancing attacks.”

The idea of a balanced attack is simple: the attacker “raises” two equally matched children below the last common ancestor block, trying to maintain two equally sized subtrees.

The attacker’s effect on the block network traffic contributes roughly half of the computing power to one tree and half to the other tree.

If the computation power of two trees is close but not exactly equal, the attacker can use his own computation power to balance the difference and eventually achieve the computation power of the two trees is equal.

Honest computing, which is divided into two parts, becomes two opposing camps.

Two subtrees of roughly the same size increase the subtree weight at the same average rate.

In under the influence of the attacker’s deliberate, each block after generated, in a very short period of time by his own camp node to see, but need a period of time can be nodes to see the other camp, each camp felt the subtrees weight slightly larger, then in his own camp trees continue to contribute to the clause.

This is a dilemma created by the attacker.

If the attacker only balances the power of the two subtrees and the network, and does not “hide the block” operation, the honest node is still able to break the trap.

Because there is always some randomness to the mining process, one camp will dig up more blocks over a period of time.

However, assuming that there are an average of n blocks in the network that are broadcasting but have not yet spread to all nodes, the time it takes for the honest nodes themselves to break this trap is N squared.

For a given network delay, n doubles for every doubling of the block generation speed, and the time for honest nodes to break their own traps increases by an order of magnitude squared.

If the attacker also hides some blocks on each branch, then every time the honest node is about to break the trap, the attacker can “intervene” and release some blocks on the weak branch to maintain the balance (like the spy in the Killing of three Kingdoms).

Through some analysis, it can be found that when the block speed is fast enough, even if the attacker with small computing power, there is a certain probability that the honest node will never be able to break the dilemma.

As the designer of consensus mechanism, how should this problem be solved?

It’s very simple, like bitcoin, to slow down the block speed, to decrease the value of n. If a block to the entire network need 10 seconds, a block of time is 10 minutes, the attackers to “hide” operation, a new block in the generated honestly, the probability of 59/60, there is no other blocks in the transmission network, all the honest node local tree graph structure is consistent, there is no honest nodes in the two camps.

Even if the attacker has stronger attack ability, he will find that in the case of slow block speed, the number of “intervention” is greatly increased, and his own computing power has become inadequate.

We constructed a theoretical model.

In this model, the computing power of the honest nodes is n blocks per second on average, and all the honest nodes are divided into two groups with equal computing power. There is no delay for block propagation within groups, and a delay of d seconds for block propagation between groups.

In this way, each group receives the same block, and the two groups do not see exactly the same block.

At the beginning, the two groups chose two different child blocks under the same parent block as the main chain block and contributed weights under them. The initial weights of the two child blocks were the same.

If at some point, one group of the selected child blocks within their own local view is not dominant, which is the group according to the rules of the largest chain “rebellion”, the attacker needs to release some blocks to avoid this matter, so as to maintain two groups cannot be who is under a “common ancestor” agreement. If the attacker cannot release the block, the attack fails.

If the attacker wants the probability of never failing to attack to be greater than zero, then the attacker needs to meet a minimum computation power requirement.

The figure below shows the minimum computational power requirements for different d*n cases.

As can be seen, when the value of DN is very small, the required nearest computation force is close to N blocks per second, which is the block generation rate of all good people. At this point, the requirement for a balanced attack is no less than that for a double-flower attack. When the value of DN is very large, the required computational force approaches 0.

If we slow the block speed down enough so that the dn value is less than 0.1, then it will be difficult for an attacker to launch such an attack with low computational power (Bitcoin is not the heaviest chain rule, but we can use bitcoin’s parameters as an example. In Bitcoin, dn is about 0.02.)

However, by slowing down the attack block, we defeat the purpose of creating a PoW public chain with a very short confirmation time. This presents a dilemma.

  1. Fast block production speed: the confirmed block has no security risk. Confirmation is very fast when no one is attacking, but never when someone is attacking.

  2. Slow block production speed: It can also ensure security and confirm transactions 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 (live attack when block speed is fast) almost completely overshadows the “jade” of the heaviest chain rule (confirm fast when block speed is fast).

So in this dilemma, is there a way to achieve both, both slow block safety and fast block efficiency?

We’ll find out in the next few episodes.