(See #128, #218, #322 for takes 1, 2, 3.)
Below is a list of miscellaneous suggestions for phase 0, most of which were discussed on the researcher's call on Feb 19. This issue keeps track of some of the phase 0 work remaining.
state to reconstruct the current block's previous_block_root. Implemented in #649.SECONDS_PER_SLOT, SHARD_COUNT, etc. based on benchmarks.exit_validator by initiate_validator_exit in process_ejections.GENESIS_EPOCH - 1 for previous_shuffling_epoch and maybe previous_shuffling_epoch.start_shard offsets: For fairer crosslinking latency across shards.DepositData: See #760.block.body.deposits.SECONDS_PER_BEACON_SLOTand SECONDS_PER_SHARD_SLOT, e.g. to 8/4, 12/3 or 16/4.
- Immediately withdrawable if bad proof of possession: See #657.
We decided during the call to not do that, correct?
- Increase proposer rewards: See #621. Need to check incentive compatibility with inclusion distance reward.
If we are going to do this, then making proposer rewards proportional to balance should arguably be in there as well. But it's not yet clear to be that we should do this; as I mentioned in the call, proposer rewards are already an expected 1/9 of validator's total revenue, and expected to increase in phase 1 due to minor rewards from the various custody objects.
Also, did we want to add a mandatory minimum time that a validator must have been deposited before they can exit? This would (i) ensure stability of persistent committees and (ii) help put a cap on validator registry modification events.
- Improved rate limiting: Change the rate limiting logic (for entry/exit/withdrawal) based on this Ethresear.ch post.
I asked econoar to study more to make sure this is a good idea.
13a and 13b
- No backfilling of latest_active_index_roots: Only set the active index root for the first slot.
Why? In the light client spec, I use the latest_active_index_roots as a way of getting the historical proposal committee, and removing the backfilling would require me to add extra special case logic there for the near-genesis case.
- Double justifications: Specify fork choice rule when there are two justified blocks at the same height. (Possible solution: ignore both and fallback to the previous highest justified block.)
I'd say we just use the same rule we do in other contexts and sort lexicographically by hash.
Closing in favour of #1053 and #1054 馃帀
Most helpful comment
I asked econoar to study more to make sure this is a good idea.