The validator spec states:
The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahead on the validator's upcoming committee assignments for attesting dictated by the shuffling and slot. Note that this lookahead does not apply to proposing, which must be checked during the epoch in question.
However, the shuffling for current_epoch + 1 depends on the RANDAO mix for current_epoch + 1 - MIN_SEED_LOOKAHEAD, i.e. current_epoch with the lookahead set to 1 as it currently is. But this RANDAO mix for the current epoch changes every time a block is processed (as per process_randao). Put another way: once a validator has transitioned to some epoch, they use the RANDAO mix from the previous epoch to determine their shuffling, and this RANDAO mix is changing right up until the last slot of the previous epoch.
In Lighthouse we were contemplating deleting our cache of the shuffling for the next epoch for this reason! See: https://github.com/sigp/lighthouse/issues/407
It would be good to have some clarity on whether the behaviour of the validator spec or of the beacon chain spec is what we really want. If the lookahead behaviour _is_ desired (which seems reasonable to me), I think we should update the beacon chain spec to account for the RANDAO mix changing in the current epoch.
This looks like an off-by-one error. nice catch. I suppose in our tests, we are always getting the committees just in time for processing. Will add some to catch this scenario.
We should be getting the mix from get_randao_mix(state, Epoch(epoch + EPOCHS_PER_HISTORICAL_VECTOR - 1 - MIN_SEED_LOOKAHEAD)) in get_seed (additional - 1) as the randao lookup.
Need to either adjust the constant to 2 as you noted or add the -1. Need to think about the semantics a bit.
Off today through the weekend. Will pick this up monday
Yeah I think the additional -1 is clearer than setting MIN_SEED_LOOKAHEAD to 2. Unless we change the name of the variable to make sense with the 2 value meaning "look at the randao from 2 epochs back".
close via #1296
Most helpful comment
This looks like an off-by-one error. nice catch. I suppose in our tests, we are always getting the committees just in time for processing. Will add some to catch this scenario.
We should be getting the mix from
get_randao_mix(state, Epoch(epoch + EPOCHS_PER_HISTORICAL_VECTOR - 1 - MIN_SEED_LOOKAHEAD))inget_seed(additional - 1) as the randao lookup.Need to either adjust the constant to
2as you noted or add the-1. Need to think about the semantics a bit.Off today through the weekend. Will pick this up monday