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 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 Enter fullscreen mode Exit fullscreen mode 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.