## Week 9 EPF Updates

This week, I implemented part of the builder bid payment to the proposer logic in [PR](https://github.com/shane-moore/lighthouse/pull/2) and added the new payload attestations flow in [PR](https://github.com/shane-moore/lighthouse/pull/3).

While implementing the builder bid payment logic, I realized various parts of the block processing lifecycle are impacted. Let's examine each step so that we fully understand it as to build it out properly.

### Process Block Operations (sequentially ordered)
Under epbs, we no longer have an EL payload in the CL block that would dictate withdrawals, so builder payments to the proposer become CL-originated, and the payment accounting is handled by modifying new `BeaconState` accessors, `builder_pending_payments` and `builder_pending_withdrawals`, at various stages of the block processing lifecycle, which are detailed below.

#### process_withdrawals ([PR](https://github.com/shane-moore/lighthouse/pull/2))
First, we need to obtain the withdrawals from the state by calling `get_expected_withdrawals`. It will loop over the current `state.builder_pending_withdrawals` list and check if any are past their withdrawable epoch. If so,`process_withdrawals` will decrease the balance of the builder accordingly and remove the withdrawal(s) from the `state.builder_pending_withdrawals` queue. Note that in reality, once they've hit their withdrawable epoch, they may not immediately get processed since each block has a max on how many withdrawals can be later swept to the EL.

#### process_execution_bid ([PR](https://github.com/shane-moore/lighthouse/pull/2))
`process_execution_bid` will then check sum up the `builder_pending_payments` + `builder_pending_withdrawals` + the bid amount to ensure it is less than their validator balance. If so, we record their bid as a new entry in `state.builder_pending_payments`.

#### process_operations::process_attestation ([PR](https://github.com/shane-moore/lighthouse/pull/2))
`process_attestation` has been modified to add weight to `state.builder_pending_payments` based off the validator's `effective_balance`.

#### Payload Arrival (TODO)
`process_execution_payload` will run once the payload is released by the builder. It will find the bid in the `builder_pending_payments` list corresponding to the current slot and port it over to the `builder_pending_withdrawals` list.

#### Epoch Boundary (TODO)
We need a fallback option to ensure the proposer still gets paid in the event that the execution payload is never released. To handle this,
`process_builder_pending_payments` will run at the start of each epoch and check if any entries in `builder_pending_payments` have a weight higher than the quorum threshold. If so, they are added to the `builder_pending_withdrawals` and deducted from `builder_pending_payments`.

#### notify_forkchoice_updated
No changes here. Just noting this is where the list of withdrawals are sent to the builder for inclusion in an EL block.

Now, we have a full understanding of the builder bid lifecycle. This week, the block processing related payment updates have been completed. Stay tuned for the rest!

## Todo next week
- build out `ptc` cache
- `process_slot` and `epoch_processing` changes
- `is_merge_transition_complete` and `validate_merge_block` updates
- Move on to execution payload processing architectural decisions