feat: cache the last 2 PayloadEnvelopeInputs

[twoeths]

Motivation

• We should not prune PayloadEnvelopeInput from seenPayloadEnvelopeInputCache right after we persist to DB, because block production needs it (next-slot getParentExecutionRequests and prepareExecutionPayload read the cached envelope synchronously).

Description

• Keep the last 2 PayloadEnvelopes in memory (head + head.parent), needed to pass finalizedSync.test.ts in feat: gloas range sync #9242 (part of feat: gloas alpha.5 speed run #9219).
• In the worst case, we fall back to loading from DB.
• This PR just cherry-picks the relevant commit from feat: gloas range sync #9242.

AI Assistance Disclosure

Used Claude Code to assist with implementation and review.

[gemini-code-assist]

Code Review

This pull request refactors the management of execution payload envelopes by introducing a database fallback for cache misses in getParentExecutionRequests, which has been updated to be asynchronous. It also implements a slot-based pruning mechanism (pruneBelow) for the seenPayloadEnvelopeInputCache, triggered during slot preparation and finalization. Furthermore, BeaconStateView was updated to process ExecutionRequests instead of full envelopes. A review comment suggests restoring a cache check in the gossip validation path to enable faster duplicate detection before executing expensive state regeneration and signature verification.

[gemini-code-assist]

The check against seenPayloadEnvelopeInputCache for duplicate detection was removed. While forkChoice is the authoritative signal, it is only updated at the end of the import process. Checking the cache provides a faster way to IGNORE duplicate gossip messages before proceeding to expensive operations like state regeneration and signature verification.

Suggested change

	const envelopeBlock = chain.forkChoice.getBlockHex(blockRootHex, PayloadStatus.FULL);
	const payloadInput = chain.seenPayloadEnvelopeInputCache.get(blockRootHex);
	if (envelopeBlock || payloadInput?.hasPayloadEnvelope()) {
	if (envelopeBlock) {
	throw new ExecutionPayloadEnvelopeError(GossipAction.IGNORE, {
	code: ExecutionPayloadEnvelopeErrorCode.ENVELOPE_ALREADY_KNOWN,
	blockRoot: blockRootHex,
	slot: payload.slotNumber,
	});
	}
	const envelopeBlock = chain.forkChoice.getBlockHex(blockRootHex, PayloadStatus.FULL);
	const payloadInput = chain.seenPayloadEnvelopeInputCache.get(blockRootHex);
	if (envelopeBlock || payloadInput?.hasPayloadEnvelope()) {
	throw new ExecutionPayloadEnvelopeError(GossipAction.IGNORE, {
	code: ExecutionPayloadEnvelopeErrorCode.ENVELOPE_ALREADY_KNOWN,
	blockRoot: blockRootHex,
	slot: payload.slotNumber,
	});
	}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2a3586e6b2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve pending payload inputs when pruning by slot

pruneBelow() now evicts every entry older than the cutoff, including PayloadEnvelopeInputs that still do not have an envelope. That breaks late-envelope recovery paths: UnknownBlockSync.fetchPayloadEnvelope() and validateExecutionPayloadEnvelope() both require an existing payload input to attach/validate fetched envelopes, so once these entries are pruned, delayed envelopes for still-relevant blocks are ignored and dependent blocks can remain stuck in PARENT_PAYLOAD_UNKNOWN processing.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Fall back to archived envelope DB before throwing

The cache-miss fallback only reads db.executionPayloadEnvelope (hot DB) and throws if absent, but finalized envelopes are migrated to executionPayloadEnvelopeArchive. In cases where block production needs execution requests from a FULL parent whose envelope has already been archived, this path will throw a false invariant violation even though the data exists; it should mirror getExecutionPayloadEnvelope() and check archive storage too.

Useful? React with 👍 / 👎.

[nflaig]

this isn't really the final head, we might still build on headRoot at the start of the slot, the updatedHeadRoot is just our prediction we make here in case we wanna reorg the current head (due to proposer boost reorg) but the head we build on is only final when we call chain.getProposerHead(slot) at t=0 of the proposal slot