Gloas process epoch

[shane-moore]

Changes per spec

• process_slot modified (per_slot_processing)
• process_epoch modified (per_epoch_processing)
  • process_builder_pending_payments added
  • get_builder_payment_quorum_threshold added

How this works

process_slot will now unset the next slot's BeaconState. execution_payload_availability, which contains a ring buffer indexed per slot. We clear the next slot's bit at every slot boundary as to start the slot off as a "no payload yet" state.

process_epoch will now run process_builder_pending_payments at the end. The sole focus of this new function is to loop over the state.builder_pending_payments left over from the previous epoch that did not get converted to state.builder_pending_withdrawals during the fast past conversion because they were associated with CL blocks that did not release their corresponding execution envelopes. So process_builder_pending_payments will check that if the accumulated weights for these state.builder_pending_payments from last epoch are higher than a quorum value. If so, they'll be converted to builder_pending_withdrawal with a withdrawable_epoch.

@ethDreamer

[ethDreamer]

So this isn't actually epoch processing. If you look at what calls this process_epoch() function, you will see it is only used in tests and in generating an epoch summary. The actual epoch processing is in process_epoch_single_pass() which uses an optimized single pass version of epoch processing. Michael did an algorithmic description here. I would have a look at how process_proposer_lookahead() was implemented if you want to do this.

[shane-moore]

@ethDreamer, great catch! should be in good shape for review now, after the last couple of commits.

Additionally, the prerequisite consensus spec PR to keep minimal changes to the single pass flow has been merged. hence, I updated this PR to have process_builder_pending_payments run before effective balance updates. Saves us a lot of pain since process_builder_pending_payments -> state.compute_exit_epoch_and_update_churn expects the validator's effective balance to be for the current epoch, i.e. before effective balance updates during single pass.

probably should have @michaelsproul take a look at this one as well, since I understand single pass is quite particular

[ethDreamer]

LGTM!