Defer payload processing to next block

[lodekeeper]

Summary

Defer execution payload processing to the next block for Gloas/ePBS (EIP-7732).

process_execution_payload no longer mutates beacon state. Instead, the CL effects (execution requests, builder payment, availability flag, latest_block_hash) are applied by a new process_parent_execution_payload function at the start of the next block. The builder commits to execution_requests_root in the bid, and the next proposer carries the parent requests in BeaconBlockBody.parent_execution_requests.

What changed

New types and fields

• BeaconBlockBody.parent_execution_requests: ExecutionRequests — proposer delivers the parent execution requests
• ExecutionPayloadBid.execution_requests_root: Root — builder commits to execution requests at bid time
• Store.payload_states: Dict[Root, BeaconState] replaced by Store.payloads: Set[Root] — no longer caches intermediate post-payload states, just tracks which roots have been locally verified
• state_root removed from ExecutionPayloadEnvelope — no longer needed since process_execution_payload does not mutate state

New functions

• process_parent_execution_payload added as the first step in process_block — processes deferred execution requests (deposits, withdrawals, consolidations), queues builder payment, updates availability flag and latest_block_hash

Gossip validation (p2p-interface.md)

• Beacon block topic: REJECT if parent_execution_requests does not match parent bid execution_requests_root (FULL parent) or is not empty (EMPTY parent)
• Execution payload topic: REJECT if hash_tree_root(envelope.execution_requests) != bid.execution_requests_root

Validator guidance (validator.md)

• New section on how proposers populate parent_execution_requests from the parent envelope

Fork boundaries (fork.md)

• upgrade_to_gloas and upgrade_to_heze initialize execution_requests_root = hash_tree_root(ExecutionRequests())

Tests

• New test_process_parent_execution_payload.py — full, empty, cross-epoch, invalid requests, builder payment, deposit ordering
• Fork-choice tests updated for payload_states to payloads migration
• Genesis and anchor helpers updated with execution_requests_root initialization

[nflaig]

this container was added in gloas and didn't exist before, so [Modified in Gloas] in gloas doesn't make any sense, same for the comment you added there, this is fine to note in PR description (like rational why it was removed) but should not be part of the spec

[lodekeeper]

Done — removed the comment entirely. The state_root removal rationale is already in the PR description.

[nflaig]

Suggested change

	# [New in Gloas]
	[New in Gloas:EIP7732]

please make sure to use the right comment

[lodekeeper]

Fixed — using [New in Gloas:EIP7732] now.

[nflaig]

Suggested change

	# [New in Gloas]
	# [New in Gloas:EIP7732]

[lodekeeper]

Fixed.

[nflaig]

this seems inaccurate since is not longer a "state transition" please reconsider how to update the spec in that regard

[lodekeeper]

Reworded — now describes it as a "pure verification function called by fork-choice" instead of referencing "state transition".

[nflaig]

this isn't modified in gloas, the whole function here only exists in gloas, same as I noted in another comment

[lodekeeper]

Removed — the whole function is new in Gloas, no [Modified] annotation needed.

[lodekeeper]

Round 2 review — annotation cleanup + adversarial analysis

Annotation fixes (edae793)

• Removed all inline [New/Modified in Gloas:EIP7732] annotations from new functions (process_execution_payload, on_execution_payload) — section headers establish this per cross-fork convention
• Added :EIP7732 suffix to all our annotations for consistency with the rest of the Gloas spec
• Cleaned up Removed comment and explanatory inline comments

process_execution_payload placement — keep in beacon-chain.md

Ran defender + devil's advocate. Verdict: keep it where it is.

For staying (9/10 confidence): 5 forks of precedent, semantic grouping with verify_execution_payload_envelope_signature, established cross-reference pattern (fork-choice calls beacon-chain, never reverse), multiple consumers (fork-choice + builder.md), pure verification functions already live in beacon-chain (every verify_* helper, is_valid_indexed_payload_attestation, etc.)

For moving (8/10): sole caller is fork-choice, no longer a state transition, fork-choice already defines verification functions. Strongest point: the spec note says "called by fork-choice" — if you have to explain it's for fork-choice, maybe it's in the wrong file.

Historical precedent and the multi-consumer argument win. The note at the section header is sufficient documentation.

Acceptance criteria — 13/14 PASS, 1 FAIL

#	Criterion	Verdict
1	BeaconBlockBody.parent_execution_requests	✅
2	process_parent_execution_payload first in process_block	✅
3	process_execution_payload pure verification	✅
4	state_root removed from envelope	✅
5	payload_states → verified_execution_requests	✅
6	on_block validates requests	✅
7	on_execution_payload buffers requests	✅
8	Validator guide	✅
9	Builder guide	✅
10	Infallibility	✅
11	is_parent_block_full ordering	✅
12	Builder payment epoch rotation	✅
13	Fork boundary handling	❌
14	Gossip validation	✅

Critical finding: Fork boundary (first Gloas block)

upgrade_to_gloas initializes latest_execution_payload_bid.block_hash = pre.latest_execution_payload_header.block_hash (non-zero). The first Gloas block's bid must have bid.parent_block_hash == state.latest_block_hash (same value). So is_parent_full = True in process_parent_execution_payload — it enters the FULL branch for a pre-Gloas parent.

At fork-choice level, get_parent_payload_status accesses parent.body.signed_execution_payload_bid on a Fulu block that lacks this field.

Fix needed: Explicit epoch guard (Option A from gist) in both process_parent_execution_payload and on_block.

Other findings from adversarial analysis

MAJOR:

• verified_execution_requests pruning comment removed — should document it follows same pattern as blocks/block_states
• builder_pending_withdrawals.append has no overflow guard (list limit 2^20)
• p2p gossip: no content-level validation of parent_execution_requests (only gated on parent payload being "seen", not "verified")

MINOR:

• Race between gossip "seen" and fork-choice "verified" — clarify in p2p spec
• Missing defensive assertion parent_epoch <= get_current_epoch(state) in builder payment code

[nflaig]

what's the reason this function is modified?

[lodekeeper]

payload_states was eliminated — all CL state mutations moved to process_parent_execution_payload in the next block's state transition. This function now checks verified_execution_payloads (set of roots for which we received and verified execution payloads) instead of looking up a payload state. Same semantic: "was the parent's payload received and valid?"

Latest commit (5a95ce8) renamed this from verified_execution_requests to verified_execution_payloads and simplified to Set[Root] since execution requests verification moved to the state transition via execution_requests_root on the bid.

[nflaig]

this can be changed to payloads: Dict[Root, ExecutionPayload] = field(default_factory=dict)

[lodekeeper]

One concern: get_forkchoice_store needs the anchor root in this structure for checkpoint sync bootstrapping — without it, get_parent_payload_status returns EMPTY for the first block after anchor, causing valid blocks with FULL parents to fail fork-choice validation (on_block asserts empty parent_execution_requests).

With Set[Root], anchor init is just {anchor_root}. With Dict[Root, ExecutionPayload], we'd need the actual payload at anchor time. In checkpoint sync only the beacon state + block are fetched — the execution payload envelope isn't available. Would require changing get_forkchoice_store signature or fetching additional data.

Is there a downstream use case you have in mind that needs the actual payload stored? Or should we find a way to handle the anchor case (e.g. sentinel value, separate anchor set)?

[nflaig]

this check can be moved to state transition if we add a commitment to the bid

[lodekeeper]

Done in latest commit (5a95ce8). Added execution_requests_root: Root to ExecutionPayloadBid — verification now happens in process_parent_execution_payload during state transition:

assert hash_tree_root(block.body.parent_execution_requests) == parent_bid.execution_requests_root

Fork-choice on_block no longer checks execution requests content. on_execution_payload does a consistency check against the bid commitment. verified_execution_requests: Dict[Root, ExecutionRequests] simplified to verified_execution_payloads: Set[Root].

[ensi321]

State transitions

process_execution_payload is no longer a state transition so this is not accurate.

[lodekeeper]

Fixed in 03cc5af — rewrote the prose to say "validity ... is checked by" instead of treating it as a state transition. Also changed "State transitions that trigger" → "Verification failures that trigger" in the following sentence.

[lodekeeper]

Updated. I removed the State transitions framing around process_execution_payload() and rewrote the section to describe it as a pure verification step returning ExecutionRequests, since the CL state mutations are now deferred into process_parent_execution_payload().

[ensi321]

execution requests are deferred to the next beacon block via

I think this is too specific. Also there are other operations that are deferred too like queueing the builder payment and set latest block hash

[lodekeeper]

Good catch. Fixed in 03cc5af — the prose now lists all four deferred effects: "execution requests, builder payment, payload availability, and latest block hash."

[lodekeeper]

Good catch. I broadened the wording so it no longer singles out execution requests; it now explicitly reflects that multiple effects are deferred (including latest_block_hash, availability tracking, and builder-payment queueing), not just the execution-request application.

[ensi321]

I think these comments need to stay

[lodekeeper]

Restored in 03cc5af. These were accidentally dropped during the refactor.

[lodekeeper]

Restored the explanatory comments around process_execution_payload(). The branch now keeps the rationale/comments in place while still making the function verification-only.

[ensi321]

This is a state mutation. Need to move it either very end or very beginning of the state_transition

[lodekeeper]

Agreed — this state root caching is a real state mutation that contradicts the "does not mutate state" claim. Two options: (a) move the state root caching to the fork-choice caller (on_execution_payload already copies state, so it can do this before calling process_execution_payload), or (b) accept the mutation and document it. Leaning toward (a). Will address in a follow-up commit once we align on the approach.

[lodekeeper]

Moved the availability-bit update to the very beginning of process_parent_execution_payload(), so it happens as part of the next block's durable state transition rather than mid-way through payload verification.

[ensi321]

Suggested change

	This pure verification function should not trigger an exception and does not
	This function should not trigger an exception and does not

[lodekeeper]

The word "pure" was already removed in a prior commit — current text reads: "This function should not trigger an exception and does not mutate state." Matches your suggestion.

[lodekeeper]

Applied the wording change. The builder text now says This function should not trigger an exception and does not mutate state.

[ensi321]

Not a fan of having GLOAS_FORK_EPOCH in the fork choice spec. Find a workaround either mention this as a comment, or put it somewhere in fork.md

[lodekeeper]

Valid concern. The guard exists because pre-Gloas blocks lack signed_execution_payload_bid — accessing it would crash. The cleanest alternative: seed all pre-Gloas block roots into store.payloads during fork activation in fork.md, so fork-choice can assume all entries have the Gloas fields. That would eliminate both epoch checks (this one and the one in on_block). Not yet addressed — will follow up once we align on approach.

[lodekeeper]

Addressed on the branch: I removed the raw GLOAS_FORK_EPOCH workaround from fork-choice and switched the pre-Gloas parent handling to a structural check instead. I also moved the initialization rationale into specs/gloas/fork.md where it belongs.

[ensi321]

Not a fan of having GLOAS_FORK_EPOCH in the fork choice spec. Find a workaround either mention this as a comment, or put it somewhere in fork.md

[lodekeeper]

Same as above — will address together with the get_parent_payload_status guard. Both can be removed if we seed pre-Gloas block roots into store.payloads at fork activation.

[lodekeeper]

Same fix here: the fork-choice workaround no longer relies on GLOAS_FORK_EPOCH; the branch now uses structural parent detection and keeps the initialization note in fork.md instead of encoding the fork epoch into fork choice.

[ensi321]

These should just be in the original for op style

    def for_ops(operations: Sequence[Any], fn: Callable[[BeaconState, Any], None]) -> None:
        for operation in operations:
            fn(state, operation)

[lodekeeper]

Already addressed in a prior commit — for_ops helper is now used in process_parent_execution_payload.

[lodekeeper]

Changed back to the original for_ops(...) style in process_parent_execution_payload() / process_execution_payload() so the loops stay aligned with the surrounding spec style.

[ensi321]

This is interesting. parent_epoch MUST be current or previous epoch.

If parent epoch is more than two epochs old, I am not sure how we should handle. (Maybe just skip updating state.builder_pending_payments? And then payment_index will be calculated based on clock slot)

[lodekeeper]

Good observation. In the base branch this is simpler because process_execution_payload runs same-slot (SLOTS_PER_EPOCH + state.slot % SLOTS_PER_EPOCH). In the deferred model, parent can be from a different epoch.

Currently we handle current_epoch and previous_epoch but silently skip if parent is >2 epochs old. This means the builder payment is forfeit — which seems correct (the chain missed that many slots, the payment window has passed and the slot has been recycled in builder_pending_payments).

Should we add an explicit comment documenting the forfeit behavior, or handle it differently? This is a protocol-level decision with economic consequences for the builder.

[lodekeeper]

I made the parent-epoch handling explicit now. The branch only rotates/applies builder pending payments for current/previous epoch contexts, and I also fixed the cross-fork carryover bug by preserving execution_requests_root across Gloas→Heze / genesis paths so the deferred-payment/deferred-request commitments stay coherent on transition boundaries. Targeted fork tests are green after that fix.

[lodekeeper]

After reviewing the ring buffer mechanics and #epbs channel discussions: if parent is >2 epochs old, the payment entry has already been evicted from builder_pending_payments by process_builder_pending_payments at epoch boundaries. There is nothing left to read — silent skip is the only correct behavior.

This is consistent with the existing quorum-based forfeit mechanism (potuz confirmed in #epbs 2025-07-28: builders not paying when quorum is not met is intentional design).

Added a documenting comment in d84874b.

[lodekeeper]

Upstream p2p-interface.md issues (alpha.4)

Noted during parity check. These exist in the upstream spec, not introduced by this PR.

Fixed here

• envelope.block_root → envelope.beacon_block_root in execution_payload gossip (2 occurrences) — trivial field name bug, fixed in 2ece03d

Deferred (out of scope — require upstream rework)

• beacon_block gossip: parent_bid alias used inline but never declared upfront
• beacon_block gossip: no explicit REJECT for bid.parent_block_hash consistency against parent bid
• beacon_block gossip: "has been seen" / "passes all validation" language is vague for the deferred payload model
• payload_attestation_message gossip: no clarification that payload_present = True means local on_execution_payload acceptance

[lodekeeper]

Closing — Nico is bringing these changes to the spec directly. Thanks for the review!