Improve beacon proposer selection logic

[JustinDrake]

Sample proposer from the full set of active validators (as opposed to just the first committee) and make proposer slashing per-slot (as opposed to per-epoch).

• improved liveness: The beacon chain can progress with just one validator (as opposed to SLOTS_PER_EPOCHS, an unintended design flaw). Improved liveness with low validator count may be useful for testing, fuzzing, and private consortium beacon chains.
• reduced complexity: Avoid calling get_committee_count, get_start_shard and get_crosslink_committee. Reduce get_beacon_proposer_index line count by 20% (from 15 lines to 12 lines).
• improved fairness: Ensure that the probability of being selected as a proposer is proportional to the effective balance. The current design gradually breaks fairness as the number of validators decreases.
• more natural design: Block proposing is natively per-slot, not per-epoch. Block proposing is orthogonal from the notion of committees, and per-slot slashing is more natural than per-epoch slashing.

Edit: I've abstracted away compute_proposer_index for reuse in phase 1.

[djrtwo]

This needs adjustments to the validator guide (being part of a committee is no longer a warning of potential proposal) and I want to run a couple of tests on the min-validator requirement of the chain now.

I'm a little resistant to the change due to the spec freeze especially since we don't really have a criteria for evaluating if something like this should go in other than "it's better".

[terencechain]

I'm a little resistant to the change due to the spec freeze especially since we don't really have a criteria for evaluating if something like this should go in other than "it's better".

Why not put this under Phase 1 miscellaneous beacon chain changes?

[djrtwo]

Updated the v-guide accordingly.
Confirmed that a lot more of the tests pass with less than SLOTS_PER_EPOCH vals, but haven't fully confirmed the low val count. Too many of our tests assume there is a committee available at a slot to make attestations (which is a sane way to test in general). Have on my todo to add some tests for handling empty operations and things.

Last thing here: I don't think we can do the filter in get_beacon_proposer_index by slashed. That would remove the predictable property within an epoch

[djrtwo]

@JustinDrake

Bump on my above comment

Last thing here: I don't think we can do the filter in get_beacon_proposer_index by slashed. That would remove the predictable property within an epoch

Looking for an agreement and then I'll merge this

[JustinDrake]

Confirmed that a lot more of the tests pass with less than SLOTS_PER_EPOCH vals

👍

I don't think we can do the filter in get_beacon_proposer_index by slashed. That would remove the predictable property within an epoch

Oh right :)

On that note get_active_validator_indices(state, epoch) can return a different value depending on when called. It's temping to add assert_invariant(epoch <= get_current_epoch(state) < compute_activation_exit_epoch(epoch)) 😂

[djrtwo]

Closing in favor of #1413