Remove MIN_VALIDATOR_REGISTRY_CHANGE_INTERVAL

[vbuterin]

Slight simplification. Only substantive change is that if the validator registry stays constant, we don't reshuffle 3 epochs after the last reshuffling (ie. before the reshufflings happened after 1, 2, 3, 4, 8, 16... epochs, now it's just 1, 2, 4, 8, 16...)

[djrtwo]

PR looks good.

But on a related note:
Weren't we originally just utilizing the hash (or repeated hash) of the original see when doing non-validator-change reshufflings? I think the intention there was to have the future shufflings in times of non-finality to be deterministic based upon some agreed upon info at the last point of finality.

With the current continual use of new/recent randao mixes in times of non-finality (attacks, short range forks, etc), I worry we end up making the shuffling extremely subjective and ultimately an attack vector. (for example: easier to construct reasonable looking blocks when the proposer for that slot is not entirely certain)

[vbuterin]

for example: easier to construct reasonable looking blocks when the proposer for that slot is not entirely certain

What would the purpose of this attack be? Just to DoS the client?

Trying to understand better what the threat model is.

[djrtwo]

Yeah, I'm worried about DoS vectors here.

If a client is uncertain of the current shuffling (seed not finalized) and receives a new block that would trigger recomputing the epoch boundary that handles the shuffling with a different seed, then the client can't immediately dismiss the block as from a bad proposer without recomputing the shuffling.

This becomes substantially more unlikely because we are grabbing the seed from EPOCH_LENGTH slots ago rather than from the head, but as long as it we are not grabbing a finalized seed for the shuffling, then there is some amount of a vector here.

This particular vector of blocks from uncertain proposers triggering reshufflings is reduced if utilize the alternative shuffling algorithm proposed in #323

[vbuterin]

This specific PR reduces the number of reshufflings going on, so it should not add any new issues in this regard.

That said, in general I'd agree that if shuffling is a large cost, then requiring clients to store many shufflings if there are many forks of the chain could reduce efficiency quite a bit. Though I'd say switching to number-theoretic shuffle or Feistel shuffle is the way to solve that particular problem.

[djrtwo]

Agreed. Going to think a bit more on shuffling/dos attacks