Skip to content

Gloas alpha spec 8 - #9315

Merged
mergify[bot] merged 51 commits into
sigp:unstablefrom
eserilev:gloas-alpha-spec-8
May 22, 2026
Merged

mergify[bot] merged 51 commits into
sigp:unstablefrom
eserilev:gloas-alpha-spec-8

Conversation

@eserilev

Copy link
Copy Markdown
Member

@eserilev
eserilev requested a review from jxs as a code owner May 18, 2026 12:20
@eserilev eserilev added the gloas label May 18, 2026
@eserilev eserilev added the ready-for-review The code is ready for review label May 18, 2026
@mergify

mergify Bot commented May 18, 2026

Copy link
Copy Markdown

Some required checks have failed. Could you please take a look @eserilev? 🙏

@mergify mergify Bot added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels May 18, 2026
@eserilev
eserilev requested a review from pawanjay176 May 20, 2026 14:41

if proposal_epoch < current_epoch || proposal_epoch > current_epoch.saturating_add(1u64) {
if proposal_epoch < current_epoch
|| proposal_epoch > current_epoch.saturating_add(spec.min_seed_lookahead)

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.

ethereum/consensus-specs#5215 also says that

is_valid_proposal_slot(state, preferences) returns True, where
state is the checkpoint state at the epoch compute_epoch_at_slot(preferences.proposal_slot) - MIN_SEED_LOOKAHEAD and
the root preferences.dependent_root.

We use the head_state here which seems correct and given our previous discussion on not wanting to accept all preferences that force us to load old states. I think that is fine. Do you think this changes?

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.

We also need to update BeaconState::is_valid_proposal_slot to use min_seed_lookahead right?

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.

The PR also changes it in get_upcoming_proposal_slots but I don't see any direct usage of it in our codebase. This spec change is so annoying.

@pawanjay176 pawanjay176 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 have reviewed the non fork choice changes and they look good. Mostly nits

execution_layer
.get_proposer_gas_limit(proposer_index)
.await
.unwrap_or(parent_gas_limit),

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.

Shouldn't this be the default that we have configured in lighthouse instead of the parent gas limit?

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.

Yeah agree, I think there's no harm in setting a higher gas limit here, because this is just the target. It also solves the problem I found which is that this isn't actually the parent_gas_limit anyway:

#9315 (comment)

"No proposer gas limit configured, falling back to parent gas limit"
);
}
proposer_gas_limit.or(Some(pre_payload_attributes.parent_gas_limit))

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 couldn't find the relevant part of the spec where we fall back to the parent gas limit instead of the configured default in lighthouse

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

Looks good. I think maybe we just add a TODO for the parent gas limit issue I raised, seeing as it is only used as a fallback, and even then is only used as a target gas limit (it can't break anything I don't think).

Comment on lines +5087 to +5091
cached_head
.snapshot
.beacon_state
.latest_execution_payload_bid()?
.gas_limit

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 think this is wrong in the case where we build on the Full variant of the parent. The payload has not yet been applied to state in this case, so its gas limit won't be stored in state.latest_execution_payload_bid.

I think we would need to thread the proposer_head_payload_status through here, or maybe just the proposer head payload envelope, and then load the gas limit from that envelope.

@michaelsproul

Copy link
Copy Markdown
Member

Actually, Pawan's suggestion is even cleaner. Get rid of parent_gas_limit from PrePayloadAttributes entirely and just use the process-level default gas limit as fallback.

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

LGTM.

let payload_parameters = PayloadParameters {
parent_hash: parent_block_hash,
parent_gas_limit,
parent_gas_limit: target_gas_limit.unwrap_or(DEFAULT_GAS_LIMIT),

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.

Wait sorry I don't think this is right. The parent_gas_limit just reports the gas limit of whatever we are building on right?

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.

yeah my bad, I thought we didn't need an accurate parent gas limit but maybe we do?

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.

Actually I think this is basically unrelated to Gloas. AFAICT the parent_gas_limit in PayloadParameters is only used in verify_builder_bid, which isn't active post-Gloas.

Still, we could safely (and correctly) initialise here by using the parent payload envelope, which is available earlier in the call stack.

We can also fully delete parent_gas_limit from PrePayloadAttributes I think

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.

Ohh that makes sense. I was wondering why we are passing it in the payload attributes when the EL already knows about the parent gas limit.

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.

Applied my idea in:

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

Latest fix looks good. Lets merge 🚀

@pawanjay176 pawanjay176 added ready-for-merge This PR is ready to merge. and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels May 22, 2026
@mergify mergify Bot added the queued label May 22, 2026
@mergify

mergify Bot commented May 22, 2026 •

Copy link
Copy Markdown

Merge Queue Status

This pull request spent 23 minutes 9 seconds in the queue, including 21 minutes 34 seconds running CI.

Waiting for
  • check-success=local-testnet-success
  • check-success=test-suite-success
All conditions

Reason

The merge conditions cannot be satisfied due to failing checks

Hint

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

mergify Bot added a commit that referenced this pull request May 22, 2026
@mergify mergify Bot added dequeued and removed queued labels May 22, 2026
@michaelsproul

Copy link
Copy Markdown
Member

@mergify requeue

@mergify

mergify Bot commented May 22, 2026 •

Copy link
Copy Markdown

Merge Queue Status

This pull request spent 29 minutes 14 seconds in the queue, including 27 minutes 33 seconds running CI.

Required conditions to merge

@mergify mergify Bot added queued and removed dequeued labels May 22, 2026
mergify Bot added a commit that referenced this pull request May 22, 2026
@mergify
mergify Bot merged commit 60abd4b into sigp:unstable May 22, 2026
38 checks passed
@mergify mergify Bot removed the queued label May 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gloas ready-for-merge This PR is ready to merge.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants