Gloas process epoch #8287
Gloas process epoch #8287
Conversation
shane-moore
force-pushed
the
epbs-process-epoch
branch
from
c9a10c8 to
0c81169
Compare
| // Post-Gloas | ||
| process_builder_pending_payments(state, spec)?; | ||
| } | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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
shane-moore
force-pushed
the
epbs-process-epoch
branch
from
40a1a6f to
ae5d8a2
Compare
shane-moore
force-pushed
the
epbs-process-epoch
branch
from
a6b2638 to
b1d539b
Compare
3 participants
Changes per spec
process_slotmodified (per_slot_processing)process_epochmodified (per_epoch_processing)process_builder_pending_paymentsaddedget_builder_payment_quorum_thresholdaddedHow this works
process_slotwill now unset the next slot'sBeaconState. 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_epochwill now runprocess_builder_pending_paymentsat the end. The sole focus of this new function is to loop over thestate.builder_pending_paymentsleft over from the previous epoch that did not get converted tostate.builder_pending_withdrawalsduring the fast past conversion because they were associated with CL blocks that did not release their corresponding execution envelopes. Soprocess_builder_pending_paymentswill check that if the accumulated weights for thesestate.builder_pending_paymentsfrom last epoch are higher than a quorum value. If so, they'll be converted tobuilder_pending_withdrawalwith awithdrawable_epoch.@ethDreamer