Support Lookahead for the Next Epoch via eth/v1/validator/duties/proposer

[jclapis]

Hello!

We're adding a new feature to the Rocket Pool node operator dashboard which notifies users when they have an upcoming block proposal or sync committee, so they know not to take their systems down for maintenance. We're using the standard Beacon REST API for this. For example, assuming the current Epoch is 61766:

curl -X GET "http://localhost:5052/eth/v1/validator/duties/proposer/61767" -H "accept: application/json"

This returns the following:

{"code":400,"message":"BAD_REQUEST: request epoch 61767 is ahead of the current epoch 61766","stacktraces":[]}

Nimbus and Teku allow us to look ahead a single Epoch like this, but Lighthouse and Prysm do not. We actually had a lengthy discussion in Discord with representatives from all four client teams about this behavior including @macladson, and after some back and forth, the opinion seems to be that the volatility associated with proposer assignment is quite low (though non-zero) when looking at the next Epoch.

For our purposes, it's low enough that we would find this quite useful to have and false-positives won't do any harm other than disappointing the user. We've added an issue to Prysm's Github page to request the behavior there as well if you'd like to track it.

Thank you!

[paulhauner]

Hey @jclapis, thanks for raising this!

I agree that making the next-epoch proposer duties available is reasonable.

In implementation, we'll have to choose whether or not we cache the values in the BeaconProposerCache during API requests. Here's the good and bad if we do cache the values:

• Good: we avoid doing duplicate per-slot and per-epoch processing.
• Bad: we can very easily "wash-out" the cache with speculative next-epoch values.

Perhaps it would be sensible to increase the proposer cache CACHE_SIZE to something like 64. That should mean we can cache API request values and our cache can't get washed out even if someone calls the endpoint for every slot in an epoch.

[eklm]

Hi, I'm interested in picking it up.

I tried to change the condition in the endpoint and it works fine but the cache for the next epoch requests doesn't make much sense as block_root in (epoch, block_root) key is changing every slot (we look at the end of the current epoch). It only helps for the requests inside one slot. So I think of implementing it without cache unless request is done at the very end of epoch (the same like tolerant_current_epoch currently). @paulhauner what do you think?