BEP-341: Validators Can Produce Consecutive Blocks

[Nathan]

Summary

Each epoch in BSC consists of multiple slots, and a batch of validators take turns in a predefined order to obtain priority block-producing rights for each slot. This BEP proposes an adjustment to the allocation of priority block-producing rights: each validator receives priority block-producing rights for a predetermined number of consecutive slots per round.

Abstract

This BEP describes a new allocation method for priority block-producing rights, which is logically concise and significantly enhances the system’s transaction processing capacity, while remaining orthogonal to transaction processing optimization techniques within blocks.

Motivation

The BSC ecosystem is active and continuously evolving, requiring ongoing improvements to the system’s transaction processing capacity.

Specification

Scaling Principle

Currently, each validator obtains priority block-producing rights for a single slot and is then rotated, with a fixed block interval of t. The transaction processing limit is t/2 for validating transactions from the previous block and t/2 for processing transactions in the new block.

Assuming the number of transactions that can be processed is T, the average TPS is calculated as follows:

After implementing this BEP, each validator can obtain priority block-producing rights for a continuous sequence of n slots in one round. The first block they process still allocates t/2 for validating transactions from the previous block and t/2 for processing transactions in the new block. However, subsequent blocks can skip the transaction validation process and focus on processing transactions in the new block. It is recommended that the processing time for the last block in their current round be only half of the time required to process transactions in the new block. This helps avoid the situation where the first block processed by the next validator is close to being an empty block.

The TPS after continuous block production is as follows:

Therefore, the TPS improvement rate is:

The relationship between the number of continuous blocks produced and TPS improvement is

As shown in the graph, it is evident that continuous block production cannot double the TPS. There is no benefit when n<3, and increasing n beyond 5 does not proportionally increase the benefits. Therefore, a value within the range [3, 5] is suitable for n; when n=4, r=50%.

Implementation Specification

Priority Allocation

Each epoch predefines a set of validators, with a total of validatorN validators, and each validator within the set has a unique index ranging from [0, validatorN). If the current block height is blockN, then the validators with the following indices obtain priority block-producing rights.

Validator Set Switch

Each epoch will choose a new validator set, assuming an epoch contains epochSlots slots. The validator set switch occurs only when the block height reaches Bswitch to prevent epoch block forging. The calculation of Bswitch is as follows:

Block Avoidance

To prevent fewer than 1/2 of the nodes from controlling the entire network, block producers are required to produce fewer than n blocks within the previous ((validatorN/2+1)*n-1) historical blocks.

Governable Number of Consecutive Blocks

When n=1, it is equivalent to disabling the feature of consecutive block production, while significant optimization is observed when n belongs to the range [3,5]. Currently, the range for the value of n is set to [1,9] but except 2.

The initial value of n is 1, and changing its value requires the BSC governance process.

Combatting MEV

As the consecutive period in which a single validator gains priority in block production extends, it may facilitate MEV extraction, potentially leading validators to include more transactions in the later blocks they consecutively produce. To constrain validators to promptly package transactions, within a validator’s consecutive priority over n blocks, the transaction fees’ split to the SystemRewardContract will increase linearly with block number, capped at the value denoted as systemRewardAntiMEVRatio.
Respectively, the split ratio remains at systemRewardBaseRatio when continuous block production is disabled. Once continuous block production is enabled (i.e., when n > 1), the systemRewardRatio is calculated as:

as shown in the following picture:

The initial value of systemRewardAntiMEVRatio is 0, and changing its value also requires the BSC governance process.

Incentive Fairness Analysis

Within a single epoch, tail validators have fewer block-producing opportunities, but the allocation of priority rights is unbiased and cannot be manipulated. Therefore, from a statistical perspective, it is fair.

If a validator tries to extract more MEV by placing more transactions in later blocks they produce, it will also increase user transaction confirmation times. To curb this, the systemRewardAntiMEVRatio can be raised through the governance process, which will increase the proportion of transaction fees allocated to the SystemRewardContract. These bonuses will be distributed as Fast Finality voting rewards to validators, keeping their overall benefits unchanged. However, during high traffic and transaction backlog, high-performance validators usually handle more transactions. These changes will reduce the income advantage of having high performance.

Security Analysis

This BEP relies on BSC’s Fast Finality feature. If Fast Finality fails, it may result in the following issues:

• Nodes intentionally hide mined blocks, potentially leading to longer short-term reorganizations.
• The probability of finality for transactions increases, requiring waiting for 2/3*validatorN*n+ blocks.

Liveness Analysis

The liveness of the chain remains unchanged, meaning it is required to ensure that at least (validatorN/2+1) validators are active. The proof is as follows:

If (validatorN/2+1) validators are active and none are allowed to produce blocks at a certain moment, each validator must have produced at least n blocks in the past ((validatorN/2+1)*n-1) blocks. Thus, collectively, at least (validatorN/2+1)*n blocks must have been produced, which is impossible. Therefore, at any moment, at least one of the (validatorN/2+1) validators must be allowed to produce blocks.

License

The content is licensed under CC0.

[brilliant-lx]

It could benefit performance, but I have some concerns, need to be addressed
Q1: fork choice definition with&without FastFinality attestation, difficulty defination.
Q2: could be more large reorg, how to handle?
Q3: hidden block attack is also critical.
Q4: more pressure for other full node, if validator has better compute power

[Nathan]

for Q1, there is no change for fork choice logic
for Q4, any performance improvement will lead to the same thing, so it’s not an issue generated by this BEP.

for Q2 and Q3, the BEP has been updated, and they are replyed in the new content.

[Nathan]

FAQ

Q1: Could there be more large reorganizations (reorgs)? How to handle them?

• If Fast Finality functions correctly, there will be no additional reorgs.
• If Fast Finality fails but validators do not act maliciously, there will also be no additional reorgs.
• If Fast Finality fails and validators act maliciously, more reorgs may occur because a validator can produce multiple high-difficulty blocks in a row. The length of reorgs will increase proportionally to the number of consecutive blocks produced by a single validator.

Q2: Hidden block attacks are also critical. How to handle them?

To enhance stability, we should increase the incentives for Fast Finality. Fast Finality allows transactions and blocks to be finalized more quickly, which is a crucial feature and foundation of the BSC. Increasing its incentives appropriately is necessary. The current version already supports governance for these incentives.

Q3: How effective is the approach to combating MEV (Miner Extractable Value)?

Governance through the systemRewardAntiMEVRatio has some effectiveness in combating MEV, but it is limited. If the profits obtained through MEV far exceed transaction fees, this approach will be ineffective.

Q4: What’s the impact on validators?

• Under heavy network load, validators can process more transactions, increasing their income.
• Due to consecutive block production, validators can handle transactions continuously for a longer period, giving them more time to optimize MEV.

Q5: What’s the impact on users?

• For regular transactions initiated by users, the transaction packaging delay remains unchanged.
• For transactions targeted by MEV, validators tend to place them in the later blocks they produce consecutively, increasing the packaging delay.
• Users may experience more MEV extraction, but its impact is limited. For example, if a validator consecutively produces four blocks, the time they control transaction processing is 12 seconds, which is comparable to Ethereum.

Q6: What happens if a validator misses one or more of its in-turn blocks?

As before this BEP was enabled, a backup validator will produce low-difficulty blocks. The fork choice logic remains unchanged. This will result in the miner who is selected for the low-difficulty block to produce fewer in-turn blocks in succession.