ePBS: Proposer Preferences Duty

Covers the new ProposerPreferences duty for the Gloas / EIP-7732 / ePBS fork (SSV-side §5 in SIP-94).

Under Gloas, the pre-fork relay-based builder registration is gone along with blinded blocks. Proposers instead broadcast SignedProposerPreferences on a new proposer_preferences p2p topic; builders listen and use the preferences to construct matching execution_payload_bid objects. Without this broadcast, gossip IGNOREs unmatched bids and the proposer's BN has no trustless external builder options for that slot.

Each SignedProposerPreferences carries dependent_root, proposal_slot, validator_index, fee_recipient, and target_gas_limit, signed under a new DOMAIN_PROPOSER_PREFERENCES with the validator's BLS share. SSV runs this as a validator-scoped, non-QBFT duty: each operator signs locally with its share, partial signatures go through one collection round, and reconstruction succeeds when ≥ 2f+1 operators converge on the same signing root. Same shape as ValidatorRegistration / VoluntaryExit. LH provides the ProposerPreferencesService that drives the polling and publication loop.

Trust model: no QBFT and no shared decided value. Each operator's signing root is determined by its target_gas_limit (per-operator config) and dependent_root (per-operator BN observation); fee_recipient is cluster-consistent in practice. Divergence on either input splits signing roots and silently fails reconstruction, leaving the validator without trustless external builder bids for that slot. The wire carries only the signing root, so a failed reconstruction cannot be attributed to a specific input; Anchor surfaces collection failure via metrics + warn-logs.

Critical path: No. Required for external-builder bid availability under Gloas; self-build still works without it. The cluster's block-signing path (§4) does not require seeing its own preferences before producing a block, because BN-side selection from execution_payload_bid gossip filters non-matching bids before the proposer is asked.

Issue arc:

1. Wire surface (#1062, PR #1106): introduce Role::ProposerPreferences (byte [8, 0, 0, 0]) + PartialSignatureKind::ProposerPreferences = 8 (next free after PTCAttester = 7); message-validator fork-gate on Ethereum ForkName::Gloas read from the consensus fork schedule (no SSV-side fork gate); timing split into an earliness allowance of (1 + MIN_SEED_LOOKAHEAD) * SLOTS_PER_EPOCH (the envelope slot is the duty's future proposal_slot, so the whole proposer lookahead must be accepted) and a lateness TTL of LATE_SLOT_ALLOWANCE (2 slots) past proposal_slot, plus the usual clock margins; per-role bounds, partial-sig binding, and message-counts bucketing. Non-QBFT, so no qbft_manager stub.
2. Sign path (#1063, PR #1125): sign_proposer_preferences runs collect_signature in SingleValidator mode, mirroring sign_validator_registration_data. No slashing-DB writes (CR-1).
3. Service wiring (#1064): spawn LH's ProposerPreferencesService with AnchorValidatorStore as the backend; the service drives the polling and publication loop.
4. RegistrationService fork-gate (#1065): short-circuit register_validators post-Gloas (the relay-builder mechanism is gone). Service stays spawned; pre-Gloas testnets and transition-window operators continue unchanged.
5. Related: reject inbound ValidatorRegistration partial-sigs at/after Gloas (#1115); make ValidatorIndex SSZ encoding architecture-independent (#1132).

Upstream LH status (at PR #1125's pin 81d576943): the service polls every slot and re-emits when dependent_root changes; preferences for the first Gloas epoch publish during the pre-fork epoch (the fork gate is per preference epoch, current and next); the duties/preferences race is fixed (sigp/lighthouse#9309); the publish endpoint is locked in (ethereum/beacon-APIs#608). Still open upstream: sigp/lighthouse#9617 makes signing and publication concurrent so one pending share collection cannot delay sibling validators' publications (relevant to Anchor's distributed signature collection; picked up on a future pin bump). Note unstable currently pins an older LH (4b3a9d3); PR #1125 carries the bump.

Known verification gap: byte layouts were audited as identical to ssv-spec/go-ssv on 64-bit targets (76-byte ProposerPreferences, 172-byte signed, 164-byte one-entry partial-sig payload), but no shared cross-client fixture yet proves each side decodes the other's bytes.

Issues under this milestone are directionally correct, not prescriptive. The implementer should verify against the current SIP, consensus-specs Gloas validator.md, beacon-APIs PR #563 (proposer-duties dependent_root), and the latest Lighthouse VC behavior, and deviate from the suggested approach if a better one emerges. Acceptance criteria are the contract; the sketch is a starting point.