Auditing Ethereum Gloas (EIP-7732 ePBS): State Transition Invariants, Builder Pending Payments & PTC Fork-Choice

How EIP-7732 (Enshrined Proposer-Builder Separation) Reshapes Consensus Layer Security In Ethereum's Gloas (EIP-7732) upgrade, execution payload validation is decoupled from beacon block processing. Instead of embedding a full ExecutionPayload inside the BeaconBlockBody, the proposer commits to a SignedExecutionPayloadBid from an in-protocol staked Builder, and the builder subsequently reveals a SignedExecutionPayloadEnvelope attested to by the Payload Timeliness Committee (PTC). This architectural shift introduces a dual-variant fork-choice tree (EMPTY vs. FULL payload states for the same beacon block root) and an in-protocol builder payment state machine that must remain 100% deterministic across all Consensus Layer clients (prysm, lighthouse, teku, lodestar, nimbus-eth2, grandine). 1. Critical Invariant #1: Builder Pending Payment Quorum & Self-Build (BUILDER_INDEX_SELF_BUILD) When a proposer self-builds (builder_index == BUILDER_INDEX_SELF_BUILD), the bid value must be 0 and no BuilderPendingPayment should be queued. For external builders (builder_index < len(state.builders)), process_execution_payload_bid records a pending payment in state.builder_pending_payments[SLOTS_PER_EPOCH + slot % SLOTS_PER_EPOCH]. During process_payload_attestation, if the PTC attests that payload_present == True, weight is accumulated toward the 60% quorum threshold (get_builder_payment_quorum_threshold). A subtle bug class arises if a client: Fails to clear state.builder_pending_payments after process_execution_payload promotes the payment to state.builder_pending_withdrawals, causing a double withdrawal at the epoch boundary (process_builder_pending_payments), or Mutates shared TransitionCaches (BuilderIndexCache) across competing forks when builder indices are reused. 2. Critical Invariant #2: EMPTY vs. FULL Fork-Choice Tie-Breaking (should_extend_payload) In Gloas LMD-GHOST fork choice, a node steps into PENDING(block_root) using the whole-block weight (EMPTY + FULL), and then chooses between extending the FULL payload or the EMPTY beacon block: def get_payload_status_tiebreaker(store, node) -> int: if not is_previous_slot_payload_decision(store, node.root): return node.payload_status # FULL (1) > EMPTY (0) for older slots if node.payload_status == PAYLOAD_STATUS_EMPTY: return 1 elif node.payload_status == PAYLOAD_STATUS_FULL: return 2 if should_extend_payload(store, node.root) else 0 If a client only evaluates should_extend_payload when proposer_boost_root is non-zero, it will erroneously prefer FULL over EMPTY at the start of a slot even when the PTC voted that the previous slot's payload or PeerDAS data columns were unavailable.