Draft: BEP-188: Early Broadcast block for an in-turn validator.
1. Summary
This BEP introduces a new block broadcast strategy to improve the network capacity and stability. In-turn validators can broadcast its block earlier when it is ready, so that other nodes could import the block earlier and have more time to mine or import the next block.
2. Abstract
Currently, a mined block will not be broadcasted until the timestamp of header.Time is reached. This proposal tries to allow an in-turn validator to broadcast earlier when the block is ready. But if all the validators broadcast blocks earlier without any restrictions, the blockchain will grow too fast. To solve this problem, we also limit broadcast time to be after the parent block’s header.Time.
3. Status
Draft
4. Motivation
Currently, a mined block will not be broadcasted until the timestamp header.Time is reached, even though the mining process is finished. If an in-turn validator spends too much time in the importing phase, it may not have enough time to mine its own block. In extreme cases, it could generate an empty block or even miss its block. This could be a challenge to the stability of the blockchain.
With this BEP, validators could begin to import a block earlier and have more time to mine a new block.
5. Specification
5.1 Broadcast strategy
The current block production process is roughly shown in the figure below:
As we can see, even though a block was mined before header.Time, it will delay to be broadcasted after header.Time. Then the next in-turn validator starts importing and mining after it receives the block. Actually, a block mined by the in-turn validator can be broadcast as soon as the mining process is finished to let other validators start importing in advance.
But if we early broadcast without limit, the block production process may be like the figure below in case each validator finished mining very quickly because they ran out of gas.
In this case, more than one block was mined in one block production cycle, which will break the current rule.Let’s see how it works if we limit the block broadcast time to after its parent’s header.Time under the same condition.
Block N finished mining in advance because it ran out of gas and then broadcast without delay.
Block N+1 also finished in advance and before blockN.header.Time, but it must delay broadcast to be after blockN.header.Time. In this way, the block production speed won’t be too quick to break the rule.
In summary, when a block mined by an in-turn validator, if
- time is after its parent block’s header.Time, broadcast it without delay.
- time is before its parent block’s header, broadcast it when the parent block’s head.Time is reached.
5.2 consensus engine adaption
The current consensus engine of the BNB chain does not accept future blocks, which means BSC nodes will reject the block if it is received earlier than its timestamp defined in header.Time. So we need to change the header’s verification logic in the consensus engine as well.
As the broadcast strategy changes, the logic of verifyHeader must be changed accordingly.The new logic should be like this shown in the figure below.
5.3 Compatibility
In order to ensure the compatibility of the network, we should upgrade the changes with the strategy as follows:
- Upgrading consensus changes with a hard fork first.
- Then upgrading the broadcast strategy after the hard fork.