Skip to content

Fix gossip bid rejection at epoch boundaries and on the head's parent - #10061

Merged
mergify[bot] merged 2 commits into
sigp:unstablefrom
jimmygchen:fix-gossip-bid-parent-randao
Sep 23, 2026
Merged

mergify[bot] merged 2 commits into
sigp:unstablefrom
jimmygchen:fix-gossip-bid-parent-randao

Conversation

@jimmygchen

@jimmygchen jimmygchen commented Sep 16, 2026

Copy link
Copy Markdown
Member

Issue Addressed

Valid payload bids can be dropped with EpochOutOfBounds when the cached head is from the previous epoch. Bids on the head's parent can also be rejected with InvalidPrevRandao because validation uses the head's RANDAO mix.

Proposed Changes

Validate prev_randao against the bid's beacon parent using the existing head_random and parent_random helpers. Add a regression for a head in the previous epoch. Head-parent RANDAO spec coverage is tracked in consensus-specs#5645.

Additional Info

The Gloas gossip rule uses the parent post-state's current epoch. Related to #9924.

@jimmygchen jimmygchen added bug Something isn't working gloas ready-for-review The code is ready for review labels Sep 17, 2026
@jimmygchen
jimmygchen marked this pull request as ready for review September 17, 2026 06:10
jtraglia added a commit to ethereum/consensus-specs that referenced this pull request Sep 21, 2026
…5645)

Adds a gossip validation test for an execution payload bid that builds
on the parent of the head beacon block. The head and parent states have
different RANDAO mixes. The test checks that a bid with `prev_randao`
from the state identified by `parent_block_root` is accepted, and fails
if validation uses the head state's mix.

Related Lighthouse fix: sigp/lighthouse#10061

Co-authored-by: Justin Traglia <95511699+jtraglia@users.noreply.github.com>

@michaelsproul michaelsproul left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need this for the next spec (my LLM reimplemented it)

I'll merge this first

@michaelsproul michaelsproul added ready-for-merge This PR is ready to merge. and removed ready-for-review The code is ready for review labels Sep 23, 2026
@mergify mergify Bot added the queued label Sep 23, 2026
@mergify

mergify Bot commented Sep 23, 2026

Copy link
Copy Markdown

Merge Queue Status

  • Entered queue2026-09-23 06:06 UTC · Rule: default · triggered by rule Add ready-to-merge labeled PRs to merge queue
  • Checks passed · on draft merge queue: checking #10061 on unstable (b1bdd31) #10113
  • Merged2026-09-23 06:36 UTC · at 4b1f3c204a7a93855b70484a8c67976848da9a1d · squash

This pull request spent 29 minutes 56 seconds in the queue, including 28 minutes 29 seconds running CI.

Required conditions to merge

@mergify
mergify Bot merged commit 4b1f3c2 into sigp:unstable Sep 23, 2026
45 of 49 checks passed
@mergify mergify Bot removed the queued label Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working gloas ready-for-merge This PR is ready to merge.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants