fix(taiko-client): only update the lookahead once per epoch #19483
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull Request Overview
This PR ensures the lookahead is only updated once per epoch by deferring updates until a safe mid-epoch slot and emitting logs on other ticks.
- Added
GetLookaheadfor mutex-protected read access to the shared lookahead - Extended
LookaheadwithLastEpochUpdatedto track when the last update occurred - Changed
cacheLookaheadLoopto update lookahead only once per epoch at slot ≥15 and log on all other slots
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| server/preconf_blocks/server.go | Added GetLookahead() with mutex and left UpdateLookahead() unprotected |
| driver/preconf_blocks/lookahead.go | Added LastEpochUpdated field to Lookahead |
| driver/driver.go | Modified cacheLookaheadLoop() to conditionally update lookahead once per epoch and log otherwise |
if a slot is late and we update the lookahead at slotInEpoch 0, it can be the same as a missed slot - the beacon chain will not update properly and the current/next operators from the contract will not roll over correctly. This will lead to incorrectly adding slot ranges for a sequencer whos not the active sequencer.
Instead, we grab a safe slot - any slot past 16 is fine, mid-epoch it will not change, since we have a delayed whitelist implementation as well. Then on every slot tick, we just emit logs instead, and only update once-per-epoch.
This is fine because we also update the current ranges for the next operator when we update the lookahead already.
IE: if CurrentOperator owns epoch 0 (slots 0-31), and the NextOperator will own epoch 1 (slots 32-63), when we pull down the NextOperator during epoch 0, we update the CurrentRanges for that address already. This is the advantage of "global slot based lookahead sequencing" instead of just using the current/nextoperator - we don't care about missed slots, and now with this fix, we also don't care about late slots at the epoch boundaries.