BEP: 524 Title: Short Block Interval Phase Two: 0.75 seconds Status: Draft Type: Standards Created: 2025-02-18 Description: To shorten the block interval from 1.5 seconds to 0.75 seconds.
- BEP-524: Short Block Interval Phase Two: 0.75 seconds
Shorten the block interval from 1.5 seconds to 0.75 seconds to enable faster transaction confirmation and improve user experience.
BEP-520 is the phase one to reduce the block interval from 3 seconds to 1.5 seconds. And this BEP is the phase two, which would reduce it further to 0.75 seconds.
Faster transaction confirmation is a critical and long term goal, with 0.75 seconds block interval, it could meet the requirement of some time sensitive applications.
The overall design specification is similar to BEP-520, so only the parameter changes will be covered in this section.
As mentioned above, phase one and phase two are highly relevant, their parameter changes will be put in one table for easy comparison.
A multitude of system parameters are configured based on the assumption of the default block interval. Consequently, when the block interval is altered, these parameters must be adjusted accordingly:
| parameter | type | origin(3s) | phase one(1.5s) | phase two(0.75s) |
|---|---|---|---|---|
| Epoch | client parameter | 200 | 500 | 1000 |
| GasLimit | client parameter | 140M | 70M | 35M |
| GasLimitBoundDivisor | client parameter | 256 | 1024 | 1024 |
| Blob Target | client parameter | 3 | 3 | 3 |
| Blob Maximum | client parameter | 6 | 6 | 6 |
| Blob MinBlocksForBlobRequests | client parameter | 524288 | 1048576 (524288 × 2) | 2097152 (524288 × 4) |
| BSCGovernor.votingPeriod | contract parameter | $votingPeriod | $votingPeriod × 2 | $votingPeriod × 4 |
| BSCGovernor.minPeriodAfterQuorum | contract parameter | $minPeriodAfterQuorum | $minPeriodAfterQuorum × 2 | $minPeriodAfterQuorum × 4 |
| BSCValidatorSet.misdemeanorThreshold | contract parameter | $misdemeanorThreshold | $misdemeanorThreshold × 2 | $misdemeanorThreshold × 4 |
| BSCValidatorSet.felonyThreshold | contract parameter | $felonyThreshold | $felonyThreshold × 2 | $felonyThreshold × 4 |
| BSCValidatorSet.felonySlashScope | contract parameter | $felonySlashScope | $felonySlashScope × 2 | $felonySlashScope × 4 |
| BSCValidatorSet.TurnLength | contract parameter | 4 | 8 | 16 |
Under the current block producer selection algorithm, if a validator fails to produce a block during its assigned slot, another validator may take over. However, due to the restrictions imposed by MinerHistory(as defined in BEP-404), the replacement validator may also be ineligible during its own slot, which reduces the overall rate of in-turn block production.
BEP-404 introduced logic to clear MinerHistory when the validator set changes, preventing this issue from accumulating over time. However, since this BEP will increase the epochLength to 1000, such off-schedule production issues can now persist and accumulate within a single epoch.
To mitigate this, this BEP proposes clearing outdated entries in MinerHistory based on the latest finalized block. Any entry with a block number less than or equal to the finalized block number will be removed:
MinerHistory map[uint64]Address
latestFinalizedBlockNumber uint64
// Clear entries up to the latest finalized block
for blockNumber := range MinerHistory {
if blockNumber <= latestFinalizedBlockNumber {
delete(MinerHistory, blockNumber)
}
}Refer BEP-520
This feature leverages Fast Finality to optimize the selection of block producers, improving the overall rate of in-turn block production. As a result, interactions with the in-turn block producer can be further optimized—for example, in terms of block production, voting, transactions, and the propagation of builder-generated bids to the next in-turn block producer.
After phase two, the block interval will be reduced to 0.75 seconds, a single validator will produce 16 consecutive blocks per turn, keeping the total block production time at 12 seconds (0.75 × 16). However, the shorter block time significantly reduces the collaboration window for searchers, builders, and validators, impacting the current process and requiring adjustments.
Blob Target and Blob Maximum remain unchanged to preserve compatibility with existing users. At the same time, the increased blob capacity lowers the cost of submitting blob data.
TBD
This BEP will not change the fast finality mechanism, but short block interval could bring some challenges to fast finality, as votes need to be propagated in a shorter time. When fast finality works properly, with this BEP, the average transaction finality time would be reduced from 3.75 seconds to 1.875 seconds. But if fast finality failed, with TurnLength 16 and ValidatorSize 21, for natural block finality, it will be:
- (with >1/2 validator confirmations): 176(11*16) blocks, that is 132 seconds
- (with >2/3 validator confirmations): 240(15*16) blocks, that is 180 seconds
The content is licensed under CC0.