Skip to content

Commit

Permalink
BEP-341: Validators can produce consecutive blocks
Browse files Browse the repository at this point in the history
  • Loading branch information
NathanBSC committed Jan 12, 2024
1 parent 2415066 commit 1b36e3f
Show file tree
Hide file tree
Showing 12 changed files with 98 additions and 0 deletions.
97 changes: 97 additions & 0 deletions BEPs/BEP-341.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
<pre>
BEP: 341
Title: Validators can produce consecutive blocks
Status: Draft
Type: Standards
Created: 2023-09-27
Discussions(optional): https://forum.bnbchain.org/t/bep-idea-validators-can-produce-consecutive-blocks/2052
</pre>

# BEP-341: Validators can produce consecutive blocks

<!-- @import "[TOC]" {cmd="toc" depthFrom=1 depthTo=6 orderedList=false} -->

<!-- code_chunk_output -->

- [BEP-341: Validators can produce consecutive blocks](#bep-341-validators-can-produce-consecutive-blocks)
- [1. Summary](#1-summary)
- [2. Abstract](#2-abstract)
- [3. Motivation](#3-motivation)
- [4. Specification](#4-specification)
- [4.1 Scaling Principle](#41-scaling-principle)
- [4.2 Implementation Specification](#42-implementation-specification)
- [4.2.1 Priority Allocation](#421-priority-allocation)
- [4.2.2 Validator Set Switch](#422-validator-set-switch)
- [4.2.3 Block Avoidance](#423-block-avoidance)
- [4.2.4 Governable Number of Consecutive Blocks](#424-governable-number-of-consecutive-blocks)
- [5. Incentive Fairness Analysis](#5-incentive-fairness-analysis)
- [6. Security Analysis](#6-security-analysis)
- [7. License](#7-license)

<!-- /code_chunk_output -->

## 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.
## 2. Abstract
BEP-341 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.
## 3. Motivation
The BSC ecosystem is active and continuously evolving, requiring ongoing improvements to the system's transaction processing capacity.
## 4. Specification
### 4.1 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.
<div align="center">
<img src=./assets/bep-341/4.1-1.png width=60% />
</div>
Assuming the number of transactions that can be processed is T, the average TPS is calculated as follows:
<div align="center">
<img src=./assets/bep-341/4.1-2.png width=18% />
</div>
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.
<div align="center">
<img src=./assets/bep-341/4.1-3.png width=60% />
</div>
The TPS after continuous block production is as follows:
<div align="center">
<img src=./assets/bep-341/4.1-4.png width=50% />
</div>
Therefore, the TPS improvement rate is:
<div align="center">
<img src=./assets/bep-341/4.1-5.png width=40% />
</div>
The relationship between the number of continuous blocks produced and TPS improvement is
<div align="center">
<img src=./assets/bep-341/4.1-6.png width=60% />
</div>
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%.

### 4.2 Implementation Specification
#### 4.2.1 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 validators with the following indices obtain priority block-producing rights.
<div align="center">
<img src=./assets/bep-341/4.2.1.png width=36% />
</div>

#### 4.2.2 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:
<div align="center">
<img src=./assets/bep-341/4.2.2.png width=48% />
</div>
In addition, the rewards for FastFinality are also distributed when there is a transition in the validator set.

#### 4.2.3 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.

#### 4.2.4 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.

## 5. 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.
## 6. Security Analysis
This BEP relies on BSC's Fast Finality feature. If Fast Finality fails, it may result in the following issues:
1. Nodes intentionally hide mined blocks, potentially leading to longer short-term reorganizations.
2. The probability of finality for transactions increases, requiring waiting for 2/3 validatorN * n + blocks.

In addition, as the consecutive time during which a single validator gains priority in block production increases, it may make MEV extraction easier.

## 7. License
The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Binary file added BEPs/assets/bep-341/4.1-1.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.1-2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.1-3.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.1-4.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.1-5.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.1-6.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.2.1.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.2.2-2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.2.2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added BEPs/assets/bep-341/4.2.3.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,7 @@ Here is the list of subjects of BEPs:
| [BEP-311](./BEPs/BEP-311.md) | Implement EIP-3651 Warm COINBASE | Standards | Candidate |
| [BEP-312](./BEPs/BEP-312.md) | Announce EIP-6049 Deprecate SELFDESTRUCT | Standards | Review |
| [BEP-319](./BEPs/BEP-319.md) | Optimize the incentive mechanism of the Fast Finality feature | Standards | Candidate |
| [BEP-341](./BEPs/BEP-341.md) | Validators can produce consecutive blocks | Standards | Candidate |

# BNB Chain Upgrades
[BNB Chain Upgrades(Mainnet): History & Forecast](https://forum.bnbchain.org/t/bnb-chain-upgrades-mainnet/936)
Expand Down

0 comments on commit 1b36e3f

Please sign in to comment.