Reduce validator client proposer duties polling with Fulu proposer lookahead

[jimmygchen]

The validator client polls for proposer duties every slot, creating unnecessary load on beacon nodes. With Fulu activating in less than two weeks, we can use the new proposer_lookahead feature to reduce this.

Problem

• The VC polls proposer duties every single slot (every 12 seconds on mainnet)
• Proposer duties don't change within an epoch (reorgs are already handled via the dependent_root check)
• This means 31 out of 32 requests per epoch return identical data
• There's even a comment acknowledging "0-epoch look-ahead" as a limitation

Proposed Solution

Fulu adds a proposer_lookahead field to the beacon state with proposer indices for min_seed_lookahead + 1 epochs ahead. We should:

• Poll only at epoch boundaries instead of every slot
• Keep the existing dependent_root mechanism for reorgs

Testing

• Monitor VC logs to confirm polling happens only at epoch boundaries
• Check BN HTTP metrics to verify reduced request frequency
• Verify validators still propose correctly
• Test that reorgs trigger duty refreshes

[michaelsproul]

Use the proposer_lookahead field to cache assignments

I don't understand this point, the proposer_lookahead is on the beacon node/beacon state side. It is already being used by the proposer duties endpoint. I think the VC just needs to use the proposer duties endpoint, and can keep its same internal data structures. It can add in polling an epoch in advance post-Fulu.

[jimmygchen]

Use the proposer_lookahead field to cache assignments

I don't understand this point, the proposer_lookahead is on the beacon node/beacon state side. It is already being used by the proposer duties endpoint. I think the VC just needs to use the proposer duties endpoint, and can keep its same internal data structures. It can add in polling an epoch in advance post-Fulu.

Yep you're right, I've removed that bullet point. Thanks!