1. Summary
Shorten the block interval from 1 second to 500 milliseconds to adapt BSC shorter block interval change and also enable faster transaction confirmation, improving user experience.
2. Abstract
BSC has started to shorten block intervals(BEP-524) to sub-seconds. As the L2 of BSC, opBNB needs to adapt to the change. As design opBNB’s block interval should be less than BSC’s. Lower block time intervals can provide quicker transaction confirmation and better user experience.
This BEP is mainly to reduce the opBNB block time from 1 second to 500 milliseconds.
3. Motivation
After BSC moves to the 750 millisecond block time interval, opBNB will never be able to sync to the latest cross-chain messages and stop producing blocks. It is required that opBNB reduces the block time interval to adapt. And besides this, reducing block time intervals will make opBNB more competitive and better meet users’ expectations.
4. Specification
4.1 Millisecond Representation in opBNB Block Header
Referencing BEP-520, the millisecond time for opBNB is also stored in the Header.MixDigest. This field is populated by the value from the Header.MixDigest of the BSC. Consequently, the last two bytes of opBNB’s Header.MixDigest are utilized to store the BSC millisecond time. To prevent any potential conflicts, opBNB has reserved the first two bytes specifically for its own millisecond time.
After the hard fork, all modules of opBNB will switch from second-level timestamps to millisecond-level timestamps, and a flag will be set in the Header.MixDigest field to indicate that it has started storing milliseconds.
This careful structuring ensures compatibility while optimizing both chains’ functionality.
The opBNB BlockTime is calculated by op-node and distributed to op-geth through PayloadAttributes. Therefore, the millisecond timestamp will be written into PayloadAttributes and then copied to the opBNB Block Header.
To ensure forward compatibility, millisecond timestamps can be identified by checking h.MixDigest == (common.Hash{}); if not enabled, the timestamps will continue to be in second-level format.
MilliTimestampreturns the millisecond-level block timestamp to enable opBNB to support sub-second block production.NextMilliTimestampmay be called when verifying the time relationship between parent and child blocks.NextSecondsTimestampandSecondsTimestampwill be called when checking for forks, as forks still use second-level timestamps.
4.2 Timestamp of RawSpanBatch
RawSpanBatch serves as a streamlined storage format for L2Block on opBNB and does not have reserved unused fields for storing millisecond timestamps. The timestamps within RawSpanBatch are converted from second-level timestamps to millisecond timestamps after the hard fork.
4.3 Parameter Changes
A multitude of system parameters are configured based on the assumption that the default block interval is 1 second. Consequently, when the block interval is altered, these parameters must be adjusted accordingly:
| parameter | type | origin(1s) | new(500ms) |
|---|---|---|---|
| L1EpochPollInterval | op-node parameter | 3s | 1.5s/750ms |
| BlockTime | op-node parameter | 1(s) | 500(ms) |
| MaxSequencerDrift | op-node parameter | 1800 | 3600/7200 |
| SeqWindowSize | op-node parameter | 14400 | 28800/57600 |
| ChannelTimeout | op-node parameter | 1200 | 2400/4800 |
| MaxChannelDuration | op-batcher parameter | 32 | 64/128 |
| TargetNumFrames | op-batcher parameter | 6 | 3/2 |
The items in the list that depend on BSC’s block time will have two new values, primarily relying on the timing of the BSC hard forks for BEP-520 and BEP-524.
The BlockTime configuration, which was previously specified in seconds, will transition to a millisecond-based unit. For instance, if it was originally set to 1 to represent 1 second, it must now be adjusted to 1000 post-upgrade to preserve the same functionality. Additionally, it is advisable to avoid configuring block times shorter than 100 milliseconds.
5. Rational
5.1 SeqWindowSize and MaxSequencerDrift
SeqWindowSize and MaxSequencerDrift are measured in block numbers.
SeqWindowSize origin value 14400 means that if opBNB fails and does not recover within 14400 * 3s (BSC BlockTime) = 24 hours, opBNB will be permanently irrecoverable.
MaxSequencerDrift origin value 1800 means that after BSC stops producing blocks, opBNB can still produce blocks, but if it exceeds 1800 * 1s (opBNB BlockTime) = 30 minutes, it will stop producing blocks.
Therefore, although both are measured in block numbers, they indeed reflect a measurement of time. With the forks that BSC and opBNB, the time for handling exceptional situations cannot be shortened, so these parameters need to be adjusted proportionally.
5.2 ChannelTimeout and MaxChannelDuration
ChannelTimeout and MaxChannelDuration are both measured in BSC block numbers, representing the timeout periods for uploading and downloading L2 blocks in the channel. As the BSC BlockTime shortens, the configuration for storing the same amount of data in the pipeline needs to be increased proportionally.
5.3 op-proposer propose interval
The interval for op-proposer to propose the state root remains 3600(30min), instead of 7200(1h), primarily considering the following three points:
- The recovery time after a sequencer restart remains the same or even becomes faster.
- Compatibility for users obtaining withdrawal proofs based on the Block Number (the most recent Block Number divisible by 3600).
- The waiting time for users to prove a withdrawal initiated in opBNB has been reduced from 1 hour to 30 minutes.
5.4 op-batcher commit Blob data
As BEP-520 describes, the block handles 1 blob per second, blob maximum is 2. Op-batcher will adjust the configuration item TargetNumFrames accordingly.
6. Backward Compatibility
6.1 DApp Developers And Users
The impact on DApp developers and users is similar to that of BEP-520, primarily affecting Timing Based on Block Numbers and Indexing Based on block.timestamp. A common solution is to use the block hash instead.
7. License
The content is licensed under CC0.