Skip to content

Use should_build_on_full for bid parent block hash #5310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jtraglia merged 6 commits into from
Jun 1, 2026
Merged

Use should_build_on_full for bid parent block hash #5310

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
700ef2a
Use `should_build_on_full` for bid parent block hash
nflaig May 29, 2026
ddca02c
refactor
nflaig May 29, 2026
c952259
simplify
nflaig May 29, 2026
7b52b44
Merge branch 'master' into bid-use-should-build-on-full
nflaig May 29, 2026
9b4fef8
review
nflaig May 29, 2026
fc29f37
remove "either"
nflaig May 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 10 additions & 11 deletions specs/gloas/validator.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,6 +182,9 @@ def get_proposer_preferences_signature(

#### Constructing the `BeaconBlockBody`

Let `head = get_head(store)` be the parent block the proposer is building on,

@nflaig nflaig Jun 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

we might wanna use get_proposer_head here cc @michaelsproul

@michaelsproul michaelsproul Jun 1, 2026

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.

yes!

@nflaig nflaig Jun 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@jtraglia we can't use get_proposer_head because it returns Root and not ForkChoiceNode, but we can make that change separate from this PR which makes it just a 1-line change later

@jtraglia jtraglia Jun 1, 2026

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.

Sounds good. I'm going to merge this now & let you make the follow up PR.

@nflaig nflaig Jun 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

let you make the follow up PR.

you mean the ForkChoiceNode refactor? no idea what's the effort for this or how to do it correctly as I haven't look into that but seems same refactoring we wanna do to FCR cc @mkalinin

in any case, there is no rush to do this, our implementation uses get_proposer_head already and I suspect all other clients that implement proposer boost reorg do too

@jtraglia jtraglia Jun 1, 2026

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.

Hmm okay. So we should merge this PR & deal with the refactor after the release?

@nflaig nflaig Jun 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I don't see how it matters for the release, we can even use get_proposer_head already, I don't think the linter catches this?

@jihoonsong jihoonsong Jun 8, 2026

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.

Handled in this PR.

from which `state` was derived.

##### Signed execution payload bid

To obtain `signed_execution_payload_bid`, a block proposer building a block on
Expand All @@ -202,7 +205,7 @@ top of a `state` MUST take the following actions in order to construct the
- The `bid.slot` is for the proposal block slot.
- The `bid.parent_block_hash` equals
`state.latest_execution_payload_bid.block_hash` if
`should_extend_payload(store, block.parent_root)` is true, otherwise
`should_build_on_full(store, head)` is true, otherwise
`state.latest_execution_payload_bid.parent_block_hash`.
- The `bid.parent_block_root` equals the current block's `parent_root`.
- Select one bid and set
Expand Down Expand Up @@ -232,8 +235,7 @@ construct the `payload_attestations` field in `BeaconBlockBody`:
##### Parent execution requests

The `parent_execution_requests` field contains the execution requests from the
parent's execution payload. Let `head = get_head(store)`. The proposer
constructs this field as follows:
parent's execution payload. The proposer constructs this field as follows:

- If the parent block is pre-Gloas (first Gloas block), set
`parent_execution_requests` to an empty `ExecutionRequests()`.
Expand All @@ -245,14 +247,11 @@ constructs this field as follows:

##### ExecutionPayload

*Note*: `prepare_execution_payload` is modified in Gloas to take `store` and
`head` as additional parameters. `head` is the return value of `get_head(store)`
and must correspond to the parent that `state` was derived from. It consults
`should_build_on_full(store, head)` to decide whether to build on the parent's
full payload or its empty variant, selecting both the withdrawals source and the
execution head for the new payload. When building on a full parent,
`apply_parent_execution_payload` is called so that withdrawals are computed
against the post-processing state.
*Note*: `prepare_execution_payload` is modified to build on the parent's full
payload or its empty variant, as decided by `should_build_on_full(store, head)`,
which determines the withdrawals source and the execution head for the new
payload. When building on a full parent, `apply_parent_execution_payload` is
called so that withdrawals are computed against the post-processing state.

```python
def prepare_execution_payload(
Expand Down