fix(pbs): derive a proposal's fork from its slot, not the JSON decode - #487
Merged
Conversation
ninaiiad
approved these changes
Aug 11, 2026
ltitanb
approved these changes
Aug 11, 2026
ManuelBilbao
approved these changes
Aug 11, 2026
JasonVranek
force-pushed
the
fix/blinded-block-fork
branch
from
August 11, 2026 19:53
aa4e16f to
4f2afff
Compare
JasonVranek
added a commit
that referenced
this pull request
Aug 11, 2026
Adds the ePBS (gloas) builder-API surface and the strict header rulings, rebased onto main so it sits on top of the SSZ rewrite (#468) and the fork-from-slot fix (#487). ePBS endpoints: - getExecutionPayloadBid, submitBuilderPreferences, submitSignedBeaconBlock, with per-builder routing by SignedRequestAuth.data (no Eth-Builder-Url). - SSZ-first request/response with JSON fallback; the bid poll ladder honors the proposer's timing headers. Header discipline (builder-specs #165): - Eth-Consensus-Version required for JSON and SSZ on the request-auth endpoints; absent -> MissingVersionHeader, present-but-unsupported -> InvalidVersionHeader, both 400. The accepted set is Gloas only; any other fork name is a client bug. - A relay bid whose response fork is not Gloas on the Gloas-only endpoint is a bad relay response: dropped, never forwarded under the wrong fork. Status + observability: - zero addressed builders accepting an ePBS submission maps to 500, not 502 (neither endpoint declares 502); new PbsClientError::NoBuilderResponse. - decode/accept rejections counted in BEACON_NODE_STATUS via record_client_error; dropped relay responses in pbs_relay_invalid_response_total{reason,endpoint,relay_id}. Legacy PBS, the websocket get_header stream (#483), and the #487 fork fix are unchanged. Suite green, clippy clean.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Addresses an issue with the current [unreleased] SSZ code.
While testing on Kurtosis, prysm submitted a blinded block as JSON with
Eth-Consensus-Version: fulu. Our JSON decode path ignored that header (only the SSZ path was using it) and fell back to serde's untagged matching.SignedBlindedBeaconBlockis an untagged enum, so it takes the first variant that parses, and an Electra blinded block is field-identical to a Fulu one. So a Fulu block quietly decoded as Electra. We then read the fork straight off that decoded value and told the relayEth-Consensus-Version: electra. Helix checked the claimed fork against the slot and rejected the submission with "data for an unexpected fork was provided".So this PR just makes sure we handle the header + JSON case.
Nothing released is affected. This is just for upcoming the SSZ optimizations.