Only clear builder payment if the slashed validator is the proposer

[luca-zanolini]

Summary

In Gloas, process_proposer_slashing clears the BuilderPendingPayment IOU for a slot using only the slot number from the slashing evidence (header_1.slot), with no check that the slashed validator was that slot's proposer.

consensus-specs/specs/gloas/beacon-chain.md

Lines 1816 to 1823 in 5e032ed

	slot = header_1.slot
	proposal_epoch = compute_epoch_at_slot(slot)
	if proposal_epoch == get_current_epoch(state):
	payment_index = SLOTS_PER_EPOCH + slot % SLOTS_PER_EPOCH
	state.builder_pending_payments[payment_index] = BuilderPendingPayment()
	elif proposal_epoch == get_previous_epoch(state):
	payment_index = slot % SLOTS_PER_EPOCH
	state.builder_pending_payments[payment_index] = BuilderPendingPayment()

The grief vector

process_proposer_slashing validates a slashing by checking only that the two headers are consistent with each other — never that the proposer was the one actually assigned to the slot. Because the IOU is then cleared using only header_1.slot, the slashed validator does not have to be the slot's proposer for the clear to fire.

Concretely:

1. Honest proposer P proposes the canonical block at slot N with a positive bid, arming a BuilderPendingPayment at slot N's index.
2. A different slashable validator V signs two distinct block headers that both claim slot = N. These are valid slashing evidence (V is equivocating), even though V was never slot N's proposer and the headers point to no real block.
3. That slashing is included while slot N is still in the 2-epoch payment window. The clear keys on header_1.slot = N, so it zeroes P's IOU.

Result: P's payment is cancelled — the proposer is never credited, the builder is never charged — purely because V equivocated on the same slot number.

Impact

A validator can be sacrificed (one slashing) to cancel an honest proposer's builder payment. It applies to payments not yet settled via an on-chain payload reveal.

Fix

Bind each IOU to the proposer that armed it, and clear it only on a match:

• Add proposer_index: ValidatorIndex to BuilderPendingPayment.
• Set it from block.proposer_index in process_execution_payload_bid.
• In process_proposer_slashing, clear the entry only when payment.proposer_index == header_1.proposer_index.

The arming proposer can't be recomputed at slashing time for the previous-epoch case (proposer_lookahead no longer covers it), so the binding is stored on the entry. block.proposer_index is sound to record because process_block_header (run before the bid) asserts it equals get_beacon_proposer_index(state).

[potuz]

Very nice catch! This looks good to me, we need a regression test only. Perhaps we can have a solution without modifying the container, but looking for the proposer index in the previous epoch is awkward. I don' t see much problem in having the proposer index in the pending payments though.

[luca-zanolini]

Thanks! Added the regression test (test_builder_payment_not_deleted_foreign_equivocation): it records a slot's payment for one proposer, slashes a different validator equivocating on the same slot, and asserts the payment is left intact. I also extended the shared check_proposer_slashing_effect to expect the entry cleared only when the slashed validator is the payment's proposer (mirroring the new guard), and updated the slashing-test helper to record the payment for the slashed proposer by default.

On avoiding the container change: I went the same way you did -- the proposer can't be recomputed at slashing time for the previous-epoch case (proposer_lookahead only covers current and future epochs), so storing proposer_index on the pending payment seemed the cleanest option.

Ran the full gloas fork suite + the eip8025 shard + make lint locally, all green.

[jtraglia]

LGTM, thank you @luca-zanolini!