Skip to content

Distinguish absent PTC votes from negative votes - #5180

Merged
jtraglia merged 9 commits into
ethereum:masterfrom
wemeetagain:track-ptc-nay
Apr 29, 2026
Merged

Distinguish absent PTC votes from negative votes#5180
jtraglia merged 9 commits into
ethereum:masterfrom
wemeetagain:track-ptc-nay

Conversation

@wemeetagain

@wemeetagain wemeetagain commented Apr 28, 2026

Copy link
Copy Markdown
Contributor

This updates Gloas fork-choice to represent PTC payload votes as Optional[boolean] instead of boolean.

Previously, False represented both "nay" and "no vote observed" for
payload_timeliness_vote and payload_data_availability_vote.
Now None vs False can allow the fork-choice to
distinguish missing votes from explicit negative votes.

This distinction is useful for detecting and attributing builder timing
games, especially repeated cases where bids are made but payloads or blob data
are not available to the PTC by the relevant deadline.

@github-actions github-actions Bot added the gloas label Apr 28, 2026
Comment thread specs/gloas/fork-choice.md Outdated
@jtraglia jtraglia changed the title Track nay PTC votes Distinguish absent PTC votes from negative votes Apr 29, 2026

@jtraglia jtraglia 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.

I like this. Nice.

@etan-status etan-status left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The conditions are still the same, this seems to be a pure preparation for some future PR without any semantic change. fine for me.

@jtraglia
jtraglia merged commit ac6a121 into ethereum:master Apr 29, 2026
28 checks passed
jtraglia pushed a commit that referenced this pull request May 14, 2026
In the event the proposer has seen the payload timely and its local view
of DA passes, the node will have the payload verified. However, if the
PTC is signalling that the Payload blob data is not available, the
proposer MUST reorg the payload.

This PR implements this mechanism with a few caveats.

- Most importantly, currently it is very aggressive and if there are no
PTC attestations the proposer will be forced to reorg the payload. There
are many solutions to this problem like simply counting the PTC
attestations (which is also a way of counting the NAY votes) or using
#5180. If we go with #5180 this PR needs to be accomodated to that and
actually count the NAY votes.
- The threshold could be different than 50%.
- The proposer may have all the data available locally and decide to
build on full even though the PTC voted no. I think it's better to leave
that unspecified.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants