add /eth/v1/validator/duties/sync/{epoch}

[rolfyone]

create a spec for sync committee duties for altair.

I'm open to making this more clearly altair specific, for now I've worked it into the typing information.

Basically I transcribed @mcdee hackmd from https://hackmd.io/@QYHAVYiHRg65pdI_CEm7Eg/syncommitteeapi#POST-ethv1validatordutiessyncepoch

[rolfyone]

@mcdee follow up questions:

• if i request 10 validator indexes, and only 1 is in a subcommittee, then the output would be only the 1 that is in a subcommittee?
• if the head epoch is pre-altair, should an error be raised or return an empty committee response? It's looking like we can't look forward from altair-1 to get the altair committee duties, so this will be relatively important to have a consistent approach... Our current theory is an empty committee response, but open to opinions on that...

[mpetrunic]

LGTM, would love to get feedback from some implementers from other teams though

[mcdee]

if the head epoch is pre-altair, should an error be raised or return an empty committee response? It's looking like we can't look forward from altair-1 to get the altair committee duties, so this will be relatively important to have a consistent approach... Our current theory is an empty committee response, but open to opinions on that...

I think an empty response makes most sense here, and as a general method of approaching this problem for future calls. It isn't a mistake to ask for sync committees for epoch 0, there just weren't any due to the function not being present in the beacon chain at that point.

[dapplion]

What's the range of correct epoch values if you want to get the nextSyncCommittee duties? i.e. any epoch

epoch >= currentEpoch - currentEpoch % EPOCHS_PER_SYNC_COMMITTEE_PERIOD + EPOCHS_PER_SYNC_COMMITTEE_PERIOD
&&
epoch < currentEpoch - currentEpoch % EPOCHS_PER_SYNC_COMMITTEE_PERIOD + 2 * EPOCHS_PER_SYNC_COMMITTEE_PERIOD

[dapplion]

In relation to #144 and the comment above I believe it would be simpler if we change the route to

/eth/v1/validator/duties/sync/{period}

sync committees should be though with periods not epochs

[rolfyone]

Query by epoch is fine, the server side can calculate the period trivially. Introducing a new parameter to query by is likely to be more confusing rather than helpful.

The server will need to be able to get an appropriate state to process the request, so if it's too far ahead, or the beacon node is not storing old states, then the window will be limited for what is going to be a serviceable request. Any node that's not syncing should be able to respond with the current sync committee period and next, so that's a lot of epochs that will be valid.

All the client wants is 'give me the sync committee duties at epoch X', and it the beacon node can figure out the details.

In terms of when to re-query, at the simplest clients can re-query each epoch if they desire and it shouldn't be a drain. if they want to save some queries, then the sync committee period is well documented in the spec...

The valid epochs should be from the altair fork epoch to a sync committee period ahead of the current epochs committee period.

[dapplion]

Already this PR in Lodestar. I would merge.

if i request 10 validator indexes, and only 1 is in a subcommittee, then the output would be only the 1 that is in a subcommittee?

Yes

if the head epoch is pre-altair, should an error be raised or return an empty committee response? It's looking like we can't look forward from altair-1 to get the altair committee duties, so this will be relatively important to have a consistent approach... Our current theory is an empty committee response, but open to opinions on that...

Empty response is good