Follow-up to #23436.
Problem
Direct payload preparation can start a builder only when the requested parent is already the execution layer's fork-choice head. In the normal Gloas FULL path, the execution payload envelope is validated with NewPayload, but that does not move the execution fork-choice head from the bid's EMPTY parent to the delivered payload hash. The ordinary proposal-time fork-choice update performs that move too late to provide warmup.
#23436 therefore limits Gloas preparation to pre-fork and genuine EMPTY paths. It keeps production live by using the normal fork-choice update and by falling back to the consensus-valid EMPTY parent when the materialized proposal head cannot be matched to a resolved payload status.
Desired result
Allow a validator to prime a Gloas FULL-parent local build before its proposal slot, without sending a speculative fork-choice update from the preparation loop.
The preferred design should advance the execution head only from a canonical Gloas fork-choice decision, after the FULL payload has been verified. If that ownership does not fit the existing stage flow, define another safe builder-start contract that preserves the same canonical-head and liveness guarantees.
Requirements
- Bind the FULL decision, execution payload envelope, beacon root, and execution head to one canonical fork-choice view.
- Keep block import, envelope validation, fork choice, and proposal production live under a slow or busy execution layer.
- Do not let speculative preparation own or delay the canonical fork-choice update.
- Preserve normal production as the authoritative fallback when preparation is absent, late, or mismatched.
- Handle FULL, EMPTY, and FULL-to-EMPTY decisions explicitly.
- Add an end-to-end test with the real execution module that follows the live sequence: block import, envelope validation, canonical head update, preparation, production fork-choice update, and collection of the same payload ID.
- Cover head changes and payload-status invalidation during the preparation window.
Specification context
Done when
- A steady-state Gloas FULL-parent proposal receives measurable builder warmup before its slot.
- The preparation path does not issue a speculative fork-choice update.
- The execution head and payload attributes used by preparation match normal production.
- Failure or contention in preparation cannot cause a missed proposal or delay canonical block processing.
Follow-up to #23436.
Problem
Direct payload preparation can start a builder only when the requested parent is already the execution layer's fork-choice head. In the normal Gloas FULL path, the execution payload envelope is validated with
NewPayload, but that does not move the execution fork-choice head from the bid's EMPTY parent to the delivered payload hash. The ordinary proposal-time fork-choice update performs that move too late to provide warmup.#23436 therefore limits Gloas preparation to pre-fork and genuine EMPTY paths. It keeps production live by using the normal fork-choice update and by falling back to the consensus-valid EMPTY parent when the materialized proposal head cannot be matched to a resolved payload status.
Desired result
Allow a validator to prime a Gloas FULL-parent local build before its proposal slot, without sending a speculative fork-choice update from the preparation loop.
The preferred design should advance the execution head only from a canonical Gloas fork-choice decision, after the FULL payload has been verified. If that ownership does not fit the existing stage flow, define another safe builder-start contract that preserves the same canonical-head and liveness guarantees.
Requirements
Specification context
Done when