BEP(Idea): Validators Can Produce Consecutive Blocks

BEP
,
1

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

BEP-234 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.

image.png1322×380 21.1 KB
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. The last block processed in their current round only uses t/2 of time to process transactions in the new block, ensuring that the first block processed by the next validator is not close to being an empty block.
image.png1356×446 21.3 KB
The TPS after continuous block production is as follows:
image.png1963×153 12.1 KB
Therefore, the TPS improvement rate is:
image.png1544×153 9.5 KB
The relationship between the number of continuous blocks produced and TPS improvement is
image.png1032×616 8.74 KB
As shown in the graph, it is evident that it is impossible to double the TPS through continuous block production; it can only approach it. Choosing n=4 can achieve a 50% TPS improvement, and beyond that, increasing n does not proportionally increase the benefits.

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, validatorNum). If the current block height is blockN, then the validator with the following index obtains priority block-producing rights.

image.png1264×153 11 KB
#### Block Producer Rotation

Every epoch will select a new set of validators, assuming an epoch contains epochSlots slots. Block producer rotation will only occur when the block height reaches Bswitch to prevent epoch block forgery. The calculation for Bswitch is as follows:

image.png1597×153 13.3 KB
#### 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*n/2 historical blocks.

System Dependency

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

  • Hidden block attacks: Validators with multiple consecutive slot priority block-producing rights can hide their blocks and release them together to cause longer chain rollbacks.
  • Variable transaction finality probabilities: Previously, it required waiting for 2/3*validatorN+ blocks, but with the implementation of this BEP, it requires waiting for 2/3*validatorN*n+ blocks.

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.

License

The content is licensed under CC0.

2

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

1 Like