feat: align proposer preferences api with latest spec#9570
Conversation
There was a problem hiding this comment.
Code Review
This pull request moves the proposer preferences submission and retrieval endpoints from the beacon pool API to the validator API. Specifically, the submitSignedProposerPreferences and getPoolProposerPreferences endpoints have been removed from the beacon pool routes, and a new submitProposerPreferences endpoint has been introduced under the validator routes. The list type size for signed proposer preferences has also been updated to use (MIN_SEED_LOOKAHEAD + 1) * SLOTS_PER_EPOCH, and the event emitter version resolution for proposer preferences now dynamically resolves the fork name based on the proposal slot. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
|
||
| /** | ||
| * Get signed proposer preferences from operations pool | ||
| * Retrieves proposer preferences known by the node but not necessarily incorporated into any block. |
There was a problem hiding this comment.
incorporated into any block
what? since when are proposer preferences incorporated into a block? 😂
Performance Report✔️ no performance regression detected Full benchmark results
|

Aligns our implementation with ethereum/beacon-APIs#608
/eth/v1/beacon/pool/proposer_preferences-->/eth/v1/validator/proposer_preferencesGET /eth/v1/beacon/pool/proposer_preferencesendpoint, we can reconsider adding a/lodestarendpoint for this if it would be useful for debugging or propose it to the spec, but for now I don't think it's that useful to have(MIN_SEED_LOOKAHEAD + 1) * SLOTS_PER_EPOCHper specEth-Consensus-Versionheader and eventversionfrom proposal slot