Check gas limit consistency with the target#5236
Merged
Merged
Conversation
jtraglia
reviewed
May 11, 2026
finterne
suggested changes
May 11, 2026
nflaig
reviewed
May 12, 2026
nflaig
reviewed
May 12, 2026
nflaig
reviewed
May 12, 2026
nflaig
approved these changes
May 12, 2026
jtraglia
approved these changes
May 15, 2026
| EIP-1559 transition rule from ``parent_gas_limit``. | ||
| """ | ||
| max_gas_limit_difference = max(parent_gas_limit // 1024, 1) - 1 | ||
| min_gas_limit = parent_gas_limit - max_gas_limit_difference |
Contributor
There was a problem hiding this comment.
Don't we have to worry about overflow here? What if parent_gas_limit is really small (or 0, as we encountered at default Gloas genesis).
Contributor
There was a problem hiding this comment.
Actually nvm, it's fine because of how max_gas_limit_difference is calculated (parent_gas_limit <= 1024 implies max_gas_limit_difference == 0).
james-prysm
added a commit
to ethereum/beacon-APIs
that referenced
this pull request
May 20, 2026
twoeths
added a commit
to ChainSafe/lodestar
that referenced
this pull request
May 21, 2026
**Motivation** - alpha.8 spec **Description** - implement ethereum/consensus-specs#5236 **AI Assistance Disclosure** - codex --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
2 tasks
nflaig
added a commit
to ethereum/beacon-APIs
that referenced
this pull request
Jun 29, 2026
Supersedes #593 with ethereum/consensus-specs#5196, ethereum/consensus-specs#5236 added Adds the proposer preferences API for Gloas, deprecates the legacy fee-recipient/gas-limit endpoints, and tightens `beacon_committee_subscriptions` for CGC bookkeeping. ## Added - `POST /eth/v1/validator/proposer_preferences` — VC submission of signed preferences and publishes them on the `proposer_preferences` gossipsub topic. - `proposer_preferences` SSE event for messages passing gossip validation. - `Gloas.ProposerPreferences` / `Gloas.SignedProposerPreferences` types, including `dependent_root` (used for gossip dedup and validation). ## Deprecated - `POST /eth/v1/validator/prepare_beacon_proposer` — superseded by signed proposer preferences. Pre-Gloas support is REQUIRED; post-Gloas the endpoint MAY be a no-op or removed. - `POST /eth/v1/validator/register_validator` — fee recipient and gas limit move to signed proposer preferences. Same pre/post-Gloas support rules apply. ## Updated - `POST /eth/v1/validator/beacon_committee_subscriptions` — from Gloas onwards, BNs use the subscription set to identify which validators are using the node and to size the node's custody group count (CGC). VCs SHOULD submit one entry per attached active validator per attestation duty, including when multiple validators share the same `(slot, committee_index)`, so the BN tracks every attached validator rather than only one per subnet. Fixes #570 --------- Co-authored-by: Nico Flaig <nflaig@protonmail.com>
nflaig
reviewed
Jun 29, 2026
| - _[IGNORE]_ `bid.parent_block_hash` is the block hash of a known execution | ||
| payload in fork choice. | ||
| payload in fork choice and | ||
| `is_gas_limit_target_compatible(parent_gas_limit, bid.gas_limit, proposer_preferences.target_gas_limit)` |
Member
There was a problem hiding this comment.
just realized this but shouldn't this be a REJECT if is_gas_limit_target_compatible = False? we do the same if fee recipient is incorrect, wondering if we used IGNORE just because it's combined with "known execution payload in fork choice" condition
Member
There was a problem hiding this comment.
Yes, I think it should. Can you open a PR for this?
Member
There was a problem hiding this comment.
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
5 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.
This is one approach to check that the builder's bid is compatible with the user's preference. In this approach this consistency check is not part of consensus as discussed during ACDT 79. In this approach the bid is required to have the actual gas limit in the payload and the CL just imposes compatibility with proposer preferences at the gossip layer rather than the consensus layer.
This relies on getting the parent gas limit from cached information in the node.
Another approach to make it part of consensus as discussed in ACDT would be to store the latest gas limit in the beacon state and make this part of
verify_execution_payload_envelope. This avoids this computation on gossip validation but requires an extra cache in the beacon state.A third approach is to send the preferences to the engine on
notify_newPayloadand require the EL to make this check.