BEP-418: Increase Initial BackOffTime From 1 To 2 Second

BEP
1 
  BEP: 418
  Title: Increase Initial BackOffTime From 1 To 2 Second
  Status: Idea
  Type: Standards
  Created: 2024-08-05

BEP-418: Increase Initial BackOffTime From 1 To 2 Second

1. Summary

This BEP attempts to enhance the network stability by delay the first off-turn block generation, so the in-turn block could have more time to be propagated.

2. Motivation

The current Parlia consensus mechanism involves a primary in-turn validator responsible for producing each block, with several off-turn validators on standby to take over in the event of a failure by the in-turn validator. These off-turn validators adhere to a strict backoff timing protocol for block production. The current initial backup time is set at 1 second, which imposes a stringent demand on network latency. If a block is not delivered within this timeframe, the first off-turn validator is triggered to produce and broadcast an alternative block. Given the often unpredictable nature of network conditions, it’s not unusual for off-turn blocks to be generated due to network fluctuations. These unexpected off-turn blocks can disrupt the network and negatively affect the performance of the blockchain.

By extending the initial backoff time to 2 seconds, such instabilities can be significantly reduced. Doubling the network latency window from 1 to 2 seconds provides a buffer that can help mitigate the impact of network jitter, thereby enhancing the overall stability and performance of the blockchain.

3. Specification

Under this proposed BEP, the first off-turn validator will have the capacity to produce a block at a time calculated as ParentTimestamp + 3 + 2. Subsequent off-turn validators will follow with a one-second interval between their block production times.

To illustrate this with an example, consider a scenario where there are 21 validators in the network. If the timestamp of the previous block is 1000, the in-turn validator will be permitted to broadcast a new block starting from 1003. In the event that the in-turn validator does not produce a block within their designated time, there are 10 off-turn validators ready to step in as backups. These off-turn validators have staggered backup times, increasing sequentially: 1005, 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1013, 1014. This arrangement ensures a smooth transition and continuity in block production, reducing the likelihood of network disruption due to untimely block deliveries.

4.Backward Compatibility

This BEP only changes the backoff time of the off-turn blocks, there is no known compatibility changes to the users yet.

5. Reference Implementations

See consensus/parlia: increase initial backOffTime from 1 to 2 second by buddh0 · Pull Request #2627 · bnb-chain/bsc · GitHub

6. License

The content is licensed under CC0.

1 Like
2

Potential Risks:

Q1: Validator may exploit this BEP to delay broadcast to include more transactions.

It is a known issue, try to illustrate it:
Case 1: without FF, the behaviors when validator broadcast it in-turn block:

//== before this BEP
  3s: accepted, good
  4s: accepted, reorg 1 off-turn block, next in-turn has 2s left to import/mine 
  5s: accepted, reorg 1 off-turn block, next in-turn has 1s left to import/mine
  6s: accepted, reorg 1 off-turn block, next in-turn has 0s left to import/mine (empty block)
  7s: rejected
//== after this BEP
  3s: accepted, good
  4s: accepted, no reorg, but not good, next in-turn has 2s left to import/mine
  5s: accepted, reorg 1 off-turn block, next in-turn has 1s left to import/mine
  6s: accepted, reorg 1 off-turn block, next in-turn has 0s left to import/mine (empty block)
  7s: accepted, reorg 1 off-turn block, next in-turn has -1s left to import/mine (empty block)
  8s: rejected

Case 2: with FF, it is same as without FF.

Q2: any impact to validator’s revenue?

If validator’s network is not stable enough, i.e. it failed to receive the in-turn block and failed to cast vote, it will not able to get the vote reward. But this BEP does not help on it, validator has to improve their node’s network condition.

3

Because of the side effect of delay broadcast, as mentioned in Q1, I think risks outweigh the benefits, so likely I will withdraw this proposal.