10259 4 proposer preferences

[mehdi-aouadi]

PR Description

Wires proposer preferences from gossip validation through to bid enforcement and validator client publishing

Fixed Issue(s)

partially fixes #10259

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Medium Risk
Adds a new proposer-preferences signing/publication path and gossips accepted preferences across the network, touching validator API, signing interfaces, and P2P plumbing. Risk is moderate because it changes validation/publishing flows and introduces new periodic background activity, but is mostly additive and fork-gated to Gloas.

Overview
Adds end-to-end support for Gloas proposer preferences: validator clients now periodically create, sign, and submit SignedProposerPreferences for the next epoch via a new ValidatorApiChannel.sendSignedProposerPreferences call.

On the beacon node side, ValidatorApiHandlerGloas validates/stores submitted preferences through ProposerPreferencesManager, exposes separate addLocal/addRemote entry points with subscriber notifications, and wires accepted local preferences to P2P gossip publication (Eth2P2PNetwork/GossipForkManager).

Extends the signing API (Signer) with signProposerPreferences, updates local/deletable/slashing-protected/no-op signers and tests accordingly, adds cache sizing constant MAX_SLOTS_TO_TRACK_PROPOSER_PREFERENCES, and updates integration/metrics/failover/sentry routing to account for the new request type.

^{Reviewed by Cursor Bugbot for commit 572e1f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

[zilm13]

I have some concerns on the way it's integrated into prepareBlockProduction and createAttestationData flows. It looks ok,
but it's important production code path and these changes are not covered with integration tests. And we do everything new prior to the old code. Plus it adds complexity to already big handler. It's a very critical part of the client designed for main validator duties. I'd rather fallback to the previous approach with separate ApiHandler or find another way to clearly skip this logic before Gloas. Also these 2 paths should be covered by tests.
What are your feelings on this?

[mehdi-aouadi]

I have some concerns on the way it's integrated into prepareBlockProduction and createAttestationData flows. It looks ok, but it's important production code path and these changes are not covered with integration tests. And we do everything new prior to the old code. Plus it adds complexity to already big handler. It's a very critical part of the client designed for main validator duties. I'd rather fallback to the previous approach with separate ApiHandler or find another way to clearly skip this logic before Gloas. Also these 2 paths should be covered by tests. What are your feelings on this?

I put back the Gloas implementation fallback logic to avoid any production code impact. Also added Gloas tests in the integration test

[zilm13]

LGTM, great work!

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Reviewed by Cursor Bugbot for commit 572e1f9. Configure here.}