feat: adding MAXIMUM_GOSSIP_CLOCK_DISPARITY for p2p validation #19783
+351
−22
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mrzeszutko
changed the title
mrzeszutko
force-pushed
the
feature/max-gossip-clock-disparity
branch
from
ef9d4ed to
8828783
Compare
alexghr
reviewed
Jan 21, 2026
Contributor
alexghr
left a comment
alexghr
left a comment
There was a problem hiding this comment.
Looks good, just a couple of questions
| } | ||
|
|
||
| // Check how far we are into the current slot (in milliseconds) | ||
| const { ts: slotStartTs, nowMs } = epochCache.getEpochAndSlotNow(); |
Contributor
There was a problem hiding this comment.
should this check that the epochCache.getEpochAndSlotNow().slot === currentSlot?
| const { ts: slotStartTs, nowMs } = epochCache.getEpochAndSlotNow(); | ||
| // ts is in seconds, convert to ms; nowMs is already in milliseconds | ||
| const slotStartMs = slotStartTs * 1000n; | ||
| const elapsedMs = Number(nowMs - slotStartMs); |
Contributor
There was a problem hiding this comment.
could this return a negative number (e.g. in a e2e test since we mess with time)?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Adds clock tolerance for P2P message slot validation, following Ethereum's
MAXIMUM_GOSSIP_CLOCK_DISPARITYapproach.Problem: P2P message validators currently reject messages (and penalize peers) if the message slot is not the current or next slot. This causes issues when valid messages are sent at the end of a slot and arrive slightly after the slot boundary due to network latency.
Solution: Add a 500ms tolerance window for messages from the previous slot. If we're within 500ms of the current slot start, we accept messages for the previous slot instead of penalizing the peer.
Why only check the previous slot?
The validators already accept messages for both the current slot and the next slot. This means:
Since we already permit early messages for the next slot, the only gap was handling slightly late messages for the previous slot. This change closes that gap.
Key implementation details
MAXIMUM_GOSSIP_CLOCK_DISPARITY_MS = 500(milliseconds) - hardcoded to match Ethereum's current value. Can be made configurable via environment variables in the future if needed.isWithinClockTolerance()helperTest plan
isWithinClockTolerance()with boundary cases (499ms, 500ms, 501ms)Fixes A-319