[MegaRedHand]

Why

The chain actor awaited every engine_newPayload inside the block import. The head moved only after the EL round trip plus the state transition, and the actor handled nothing else (gossip, ticks, other imports) while it waited. Gloas envelopes did the same.

What

A pre-gloas block that is an optimistic candidate now imports as optimistic as soon as its consensus checks pass, and a gloas envelope applies with its payload NOT_VALIDATED. The newPayload question goes out first, from a tokio task that reports back with a NewPayloadAnswered message. The answer is applied then, the way optimistic-sync.md applies a verdict. Optimism already gates attestation data (503), so validators still attest only to validated payloads.

EL answer	Pre-gloas block	Gloas payload
VALID	validated with its optimistic ancestors; head sent again without the optimistic flag	VALID, held children released
SYNCING / ACCEPTED	stays optimistic	stays NOT_VALIDATED, held children released
INVALID with a hash	branch removed (invalidate_block_payload, shared with the FCU path)	condemned (condemn_payload_chain)
INVALID with no hash	as above	taken back out (revert_envelope): only that copy is refused
no answer	kept, asked again next slot	kept, asked again next slot

Rules (module docs in crates/blockchain/src/beacon_new_payload.rs):

• Order. A payload is sent only once the payload it builds on has been answered, at most MAX_NEW_PAYLOADS_IN_FLIGHT (4) at once. The Engine API orders only forkchoiceUpdated (common.md), the engine client's connection pool can reorder requests, and a payload whose parent the EL hasn't seen is answered SYNCING and may start a peer sync.
• forkchoiceUpdated names the newest payload on the head's chain whose request is not queued or in flight, and is sent again when the head's answer arrives. Skipping the call instead would starve the EL of a head for the whole of a catch-up, where the newest block's request always waits behind its parent's.
• Bound. At most MAX_PAYLOADS_AWAITING_VERDICT (128) payloads wait. Past that the import is held (a pre-gloas block is written as a pending block; an envelope waits in awaiting_engine) until answers free room.
• Children of a FULL payload wait for its answer, not just for its envelope. That way nothing is built on an envelope that gets taken back out. Lighthouse (get_parent_import_status) and Prysm (ParentPayloadReady) hold the same blocks, since their FULL node exists only after the answer.
• Hash mismatch. Since engine_newPayloadV2 a block hash mismatch is answered INVALID with a null latestValidHash (INVALID_BLOCK_HASH is "supplanted by INVALID", execution-apis shanghai.md). Lighthouse (unstable 25b9b75) and Prysm (develop bf0db8c) both reject only the envelope there and condemn nothing. This PR matches that by reverting the applied envelope. The code comment calling this an ethrex quirk is corrected.
• Inline path kept. Two cases still wait for the answer inline: blocks that are not optimistic candidates (merge transition), and a server with no mailbox (offline replay).

Spec deviation

optimistic-sync.md says a block the EL gave no answer for MUST NOT be applied to fork choice. Here it already is, so it stays optimistic and is asked again each slot. This is documented in docs/spec_deviations.md ("Payloads are applied before the execution client answers"), which replaces the gloas-only entry.

Relation to other PRs

• Supersedes perf(blockchain): run the beacon state transition while the engine verdict is in flight #755's speculative state transition: the transition no longer waits for anything. nightly will conflict in process_block.
• Complements feat(p2p): refuse execution payloads whose block hash is not their header's #770 (gossip block-hash check). With it, structural mismatches are refused before they are applied, so the revert path is rarely reached.

Testing

• ethlambda-blockchain --lib --features beacon-spec-tests (with consensus-spec-tests v1.7.0-beta.2): 353 passed. New tests cover:
  • the queue: parent ordering, the cap, re-asking, forkchoice_head, the bound;
  • the pre-gloas verdicts (VALID/SYNCING/INVALID/no answer/stale);
  • the hold for room;
  • gloas: applied before the answer with its child held; the child arriving after the envelope but before the answer; the revert on a null-hash INVALID; condemnation on a real-hash INVALID; no answer then a re-ask.
• The six existing tests that encode "no verdict means not imported" now cover the inline path, unchanged.
• cargo test --workspace --lib --bins, make lint.
• Not covered: the actor seam (the #[started] hook that records the actor's reference, and dispatch of NewPayloadAnswered through the real mailbox). Every test feeds answers through a channel. A follower run is the end-to-end check.

New metrics: lean_engine_new_payload_in_flight, lean_engine_payloads_awaiting_verdict, lean_engine_new_payload_answers_total{kind,outcome} (in docs/metrics.md).