Advice in validator guide about lookahead is contradictory

[michaelsproul]

This paragraph in the validator guide implies that sync committees can't be computed except at the period boundary:

Note: The data required to compute a given committee is not cached in the BeaconState after committees are calculated at the period boundaries. This means that calling get_sync_commitee() in a given epoch can return a different result than what was computed during the relevant epoch transition. For this reason, always get committee assignments via the fields of the BeaconState (current_sync_committee and next_sync_committee) or use the above reference code.

However I don't think this is the case, because the sync committee indices only rely on:

1. The seed from the base_epoch, which is <1024 epochs back (we have 64k epochs of history in the randao_mixes vec)
2. The active validators at the same base_epoch, which can be computed accurately at any epoch after the base_epoch

Further, the state transition relies on recomputing the sync committees in arbitrary epochs: in process_sync_committee a call is made to get_sync_committee_indices.

The reason for my deep-dive on this issue is that in Lighthouse we've implemented a cache for the committee indices, which can get recomputed at arbitrary points (e.g. if a state is loaded from the DB and lacks the cache it could be built anew). I just wanted to check that we're not missing something that would make this unsound.

[ralexstokes]

the sync committee indices only rely on:

that computation also relies on effective_balance which we don't keep historical record of in the state. this is the same as with the proposer shufflings and why validators should re-compute proposer shufflings every epoch (rather than say w/ 1 epoch of lookahead) -- its a small chance but the effective_balance could change enough to shift the shuffling.

this rationale inspired the note in the validator guide where you don't have any lookahead on the sync committee shufflings other than 1 sync committee period bc we track the "next" committee.

the state transition relies on recomputing the sync committees

this may be a bug! we may need to do a 'pubkey to index' lookup here based on state.current_sync_committee rather than use get_sync_committee_indices.

[michaelsproul]

Ah the effective balances! Damn!

Thanks for looking into it

[djrtwo]

resolved in #2394