BEP(Idea): Validator Slash Mechanism 2.0

BEP
1

1. Summary

This BEP introduces a validator slash mechanism 2.0 on the BNB Smart Chain.

2. Abstract

This BEP describes a new slash mechanism to slash malicious validator in more scenarios, if some validator missing proposal, it could slash directly. Otherwise, validators could propose a slash to the malicious validator, and when the majority of validators agree on it, the slash will affect too.

There are slash scenarios:

  1. The validator misses the INITURN block;
  2. The validator delay broadcast INTURN block too long;
  3. The validator proposes a duplicated block in the same block height with a different block hash;

The new slash rules refer to the previous ones. There is a certain tolerance threshold, and the punishment will be executed if the threshold is exceeded. This BEP can also be used in other scenarios where validators are punished for malicious behavior.

The new slash mechanism enriches the scenarios for monitoring validators, can promote good competition among validators, and protect the security and smooth operation of the network.

3. Status

draft

4. Motivation

The current BSC network will impose slash penalties on validators who skip block generation, but this is not enough. After observing that the current validator will delay the broadcast behavior:

  1. Poorly operated validator clients may use poor machines or network providers;
  2. Maliciously delay broadcasting blocks, in order to collect more transaction fees as rewards;

These behaviors have seriously affected the stability of the network, but they will not be punished, because the validator’s INTURN block in BSC’s PoSA algorithm has a higher difficulty. In some scenarios, the slashing penalty can be reorg, which will damage the entire network. Not in line with the interests of the current BSC’s long-term operations:

  1. Frequent network reorgs cannot guarantee a stable TPS;
  2. Collect more transactions during the delayed broadcast period to obtain higher returns, resulting in uneven returns and harming the rights and interests of other validators;

In order to guarantee the rights and interests of the nodes and maintain the reliable and safe operation of the network, it is necessary to propose a solution, through an effective mechanism to limit the validator to package transactions for a longer period of time, or to use a poor network and machine to run the validator node.

5. Specification

The PoSA consensus algorithm is used in BSC, and the set of selected validators generates blocks in sequence according to the established order and broadcasts them to the network.

The blocks released in the order of block generation are called INTURN blocks, and the block difficulty is 2. In order to ensure liveness, if there is a block node failure, severe network delay, or a malicious block, other validators will re-generate a liveness block. This block is called NOTURN Block, block difficulty is 1, and at this time the validator of the supposed block will mark a slash.

However, since the INTURN block is more difficult than the NOTURN block, the current chain will be reorg in some scenarios. First of all, you need to consider the reorg scenarios in the current BSC.

1966Ă—1336 125 KB

As shown in the figure above, Scenario 1 and Scenario 2 will reorg the current chain after the supposed validator delays releasing blocks.

However, when the current chain continues to generate blocks and accumulate higher difficulty, the delayed release of the INTURN block cannot reorg the current chain.

Of course, some collusion situations or corner cases will trigger reorg too, but the new scheme will record delayed or repeated block generation. The new slash mechanism will ensure the good operation of the network.

5.1 Block Difficulty

In BSC, INTURN blocks have a higher priority, and one INTURN block can reorg two NOTURN blocks, because under the same difficulty, the height of INTURN blocks is smaller.

The current difficulty of INTURN and NOTURN:

INTURN = 2, NOTURN = 1

When the weight of NOTURN could be slightly increased, this scenario could be improved. The new difficulty options are as follows:

INTURN = 3, NOTURN = 2

The impact of diff changes on reorg can be simulated through the library diff-simulation, and it can be observed that the new difficulty value has fewer reorg times.

5.2 Missing Block

The current slash mechanism mainly punishes the behavior of not producing blocks. This upgrade will still punish the behavior of not producing blocks. When it is found that the supposed validator has not produced a block, other validators will propose NOTURN blocks and slash the supposed validator.

Consistent with the current Slash penalty method, if the current block is a NOTURN block, a Slash is marked for the supposed validator.

5.3 Delay Broadcast

Delayed broadcasting is the malicious behavior that this BEP focuses on solving. Consider using the next validator proposing, all validator set voting mechanism to determine whether to slash the validator.

Delay Broadcast is for the INTURN block, and the supposed validator will be directly punished for the NOTURN block.

Specifically, the validator can judge that the current supposed validator has a delayed broadcast based on the block timestamp of the received INTURN block and the block arrival timestamp. Assuming that most of them are honest nodes.

  1. Each validator needs to cache the block generation status of nearly 21 block heights, and the historical blocks with a height of more than 21 blocks will be eliminated;
  2. When receiving an INTURN block with a height H, first verify whether the block timestamp meets expectations, and then calculate the delay weight:
DelayTime = receiveTime - parentBlockTime - blockPeriod; 
if DelayTime < initialBackOffTime: 
    DelayWeight = 0 
else 
    DelayWeight = (DelayTime - initialBackOffTime) / wiggleTime + 20

notice: The first INTURN block of height H is expected to be broadcast to the network at parentBlockTime+blockPeriod+initialBackOffTime time.

The current blockPeriod is 3s, initialBackOffTime is 1s, and wiggleTime is 1s.

  1. If the weight DelayWeight greater than 0, record that the current supposed validator needs to be punished at height H, and submit delayWeight;
  2. When it is the validator’s turn to produce a block, collect all the current records that need to be punished and submit them to the SlashIndicator contract in batches:
    • Determine whether to submit slash repeatedly;
    • If the validator has already taken effect at the height of delay broadcast slash or missing block slash, skip it;
    • If the slash is correct and the cumulative delayWeight is greater than the threshold for majority found delays, greater than (N/3*2)*20, record a slash for the validator;

5.4 Duplicated Block

It is unacceptable for the same validator to continuously produce two blocks with the same height and different hashes. Off-chain statistics and on-chain voting are required, assuming that most of them are honest nodes.

  1. Each validator needs to cache the block generation status of nearly 21 block heights, and the historical blocks with a height of more than 21 blocks will be eliminated;
  2. When receiving a block with a height H, query the historical blocks of the validator with the same height to determine whether the block hash is consistent:
if newBlockHash == prevBlockHash: 
    DupWeight = 0 
else 
    DupWeight = 1
  1. If the weight DupWeight is greater than 0, record that the current supposed validator needs to be punished at height H, and submit DupWeight;
  2. When it is the validator’s turn to produce a block, collect all the current records that need to be punished and submit them to the SlashIndicator contract in batches:
    • Determine whether to submit slash repeatedly;
    • If the validator has already taken effect at the height dup slash, skip it;
    • If the slash is correct and the cumulative DupWeight is greater than the threshold for majority, that is, N/3*2, record a slash for the validator;

5.5 Punishment

For the specific punishment, it tends to be the same as the previous Slash rules. There is a certain tolerance number every day. If the tolerance number is exceeded, the real penalty will be confiscated:

  1. When the number of Slash marks is greater than or equal to 50 times, misdemeanor penalties will be executed, and all current income will be confiscated. If the canEnterMaintenance condition is met, it will immediately enter the Maintenance state;
  2. When the number of Slash marks is greater than or equal to 150 times, a felony penalty will be executed, all current income will be confiscated, the validator will be eliminated, and a cross-chain penalty message will be sent;
  3. If the current validator has only one node, only the current income will be confiscated when the felony penalty is executed, and a cross-chain penalty message will be sent;

The current Slash mechanism has more punishment scenarios than before. The same validator can use the Maintenance method in BEP-127, Enter the maintenance state, and wait for the node to recover before rejoining the network to generate blocks to avoid real punishment.

6. Rational

There are some other important things to consider:

  1. Does the penalty record need to be persisted? At present, it is not necessary, and it is not a big problem to omit some evidence submission due to node maintenance or failure;
  2. If there is a node rotation in epoch, the voting in progress may be invalidated. It is recommended that the number of nodes replaced each time should not exceed N/3;
  3. Whether malicious voters need to provide proof, assuming that most of them are honest nodes, this is not necessary;
  4. Missing block punishment and Delay Broadcast generally do not exist at the same time. Duplicated Block may exist at the same time as Missing block or Delay Broadcast, recording multiple punishments of a certain validator at a height;

7. Backward Compatibility

This BEP needs a new hard fork, it needs to upgrade SlashIndicator system contract, and add trace validator malicious behaviors.

8. License

The content is licensed under CC0.

1 Like
2

Hi, I have post a BEP draft PR, welcome to review it, [WIP]BEP-191: Validator Slash Mechanism 2.0; by GalaIO · Pull Request #191 · bnb-chain/BEPs · GitHub.

1 Like
3