Issue
Lookahead section of Honest Validator spec states:
get_committee_assignment should be called at the start of each epoch to get the assignment for the next epoch (current_epoch + 1). A validator should plan for future assignments by noting at which future slot they will have to attest and joining the committee index attestation subnet related to their committee assignment.
Assume we have two competing forks at the boundary betweenN - 1 and N epochs. For instance, fork B misses last block of N - 1 while A, in opposite, considers that block. Note: these two views of N - 1 epoch results in two different randao mixes affecting N + 1 shuffling. In the result node may join wrong aggregation subnet depending on whether it's been following canonical chain before the lookahead or not.
Possible solutions
- Look back to the fork choice. Once lookahead process done node have to look at the changes of canonical chain that could affect shuffling and re-join subnet in the case when it happens. This approach gives a probability lookahead process which is as strong as far the tip of the chain states from an epoch boundary.
- Use finalized randao mix. Use randao mix of finalized epoch
N - 1 to compute shuffling starting from epoch N + 1 which would give predictable lookahead within one epoch.
Issue
Lookahead section of Honest Validator spec states:
Assume we have two competing forks at the boundary between
N - 1andNepochs. For instance, forkBmisses last block ofN - 1whileA, in opposite, considers that block. Note: these two views ofN - 1epoch results in two different randao mixes affectingN + 1shuffling. In the result node may join wrong aggregation subnet depending on whether it's been following canonical chain before the lookahead or not.Possible solutions
N - 1to compute shuffling starting from epochN + 1which would give predictable lookahead within one epoch.