optimize: extended expire time for sequencer block broadcasting #106
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR incorporates modifications to the block validator within the op-node, which is utilized by both the sender (sequencer) and receiver. The block expiration check has been increased from 60 seconds to 20 minutes. This change was prompted by scenarios where the sequencer could not maintain a block production rate of one block per second. Under the previous validation logic, if blocks were produced slowly for a period and the anticipated block time was more than 60 seconds apart from the current time, the sequencer would fail the check and be unable to broadcast the block, preventing other nodes from syncing unsafe blocks. With this change, the time has been increased to 20 minutes. Please note that the 20-minute duration is not the time we maintain synchronization, but a relative time difference. (For example, if the sequencer’s block production speed drops to half, at 2 seconds per block, then the actual duration for which the sequencer continues broadcasting blocks would be approximately 40 minutes.)
Rationale
Two adjustments have been made:
1.The time duration within the block validator has been extended from 60s to 20min.
2.Enhancements were made to the seenMessagesTTL and blockHeightLRU caches to guard against potential stale block attacks that could arise due to the validator changes. The seenMessagesTTL serves as a preliminary logic cache before entering the validator, where a block hitting this cache would not proceed to further validation and processing. The blockHeightLRU cache is used to keep track of the number of validations for duplicate blocks to signal other nodes with an 'ignore' or 'reject'. As our validation effective time has increased from 1 minute to 20 minutes, the corresponding caches also required expansion to prevent possible block broadcast attacks.
Example
N/A
Changes
Notable changes: