## EPF Week 4 Updates
This week, I gained familiarity with Lighthouse's block proposal and validation flow as to understand the parts of the codebase that we'll need to modify for delayed execution, EIP-7886. Afterwards, I'll be able to add the scope to the project proposal.

In previous posts, I've mentioned that the fields below will be added to the execution payload on the EL's side.

 # Deferred execution outputs from parent block
    pre_state_root: B256    # State root from the parent block
    parent_transactions_root: B256    # Transaction root from parent block
    parent_receipt_root: B256         # Receipt root from parent block
    parent_bloom: Bloom               # Logs bloom from parent block
    parent_requests_hash: B256      # Hash of requests from the parent block
    parent_execution_reverted: bool   # Indicates if parent block's execution was reverted

On the CL side, the new fields will be derived from either the local EL block builder or the MEV boost builder.

Let's take a look at the CL's current block proposal and validation flow to understand what will change:

### Proposal Flow
During block production, `ExecutionLayer::get_payload` chooses between a payload produced locally by an EL client or one obtained from an external builder. Depending upon the profitability of the local vs external payload, one is selected. Note that the builder's block value can be boosted by a configured percentage, the `builder_boost_factor`. For example, if the local payload's value is greater than or equal to the boosted builder value, the local payload is chosen.

Then, the CL's block is assembled by inserting the chosen payload into the `BeaconBlockBody` via `complete_partial_beacon_block`.

Additionally, we'll want to update the `BeaconState`'s `ExecutionPayloadHeader` with the new payload, which happens during the `process_execution_payload` call. Then, the new state root is calculated and inserted into the block header. Finally, the validator will sign and broadcast the payload.

## Validation Flow
The CL receives a new block and passes its payload to the EL to verify fields such as the EL's `block_hash` and `state_root` via `notify_new_payload`. The EL will then recompute these fields and if they match, a `Valid` status will be returned to the CL. Then, `process_execution_payload` is responsible for writing the `ExecutionPayloadHeader` into the canonical `BeaconState`, which ends up on disk via `import_block`.

## Changes for EIP-7886
1. The `ExecutionPayload` struct is included in the `BeaconBlockBody`, so we will need to add a new variant to apply past the fork boundary that will include our new fields.

enum ExecutionPayload<E: EthSpec> {
    Eip7886(ExecutionPayloadGlamsterdam<E>), // new variant
}

2. Additionally, the evergreen `BeaconState` will need to be updated past the fork boundary to have its `ExecutionPayloadHeader` hold the new `parent_*` fields.

3. The EL's block header is RLP encoded and then hashed to obtain the`block_hash`. Since `block_hash` is stored in our `ExecutionPayload`, we'll need an `ExecutionBlockHeader` variant that includes the new fields. The `block_hash` is later recalculated by the EL to check for validity. The `block_hash` will also be persisted in the `BeaconState::ExecutionPayloadHeader`.

4. Lighthouse will JSON serialize the `ExecutionPayload` to send to the EL via the engine api for block validation. Therefore, we'll need a `new_payload_glamsterdam` helper to forward the payload to the engine. Similarly, a `get_payload_glamsterdam` helper will return payloads for block building.

5. Validator clients can request blinded blocks where only a payload header is sent. We'll need to extend this header:

pub struct BlindedPayload<E: EthSpec> {
    execution_payload_header_glamsterdam: ExecutionPayloadHeaderGlamsterdam<E>,
    // existing variants
}

6. Feature gate all of these changes so that they could be merged into the codebase without issue

## Questions for Lighthouse:
1. Since we will want to only have this logic apply after a hypothetical future fork boundary, do you prefer the naming convention for new structs and helpers to be similar to `ExecutionPayloadHeaderGlamsterdam` and `upgrade_to_glamsterdam`?

## Todo This Week
1. Update the project proposal based off the research above
2. Start building this out in lighthouse.

## References
- [Lighthouse GH](https://github.com/sigp/lighthouse)
- [EIP-7886 Delayed Execution](https://eips.ethereum.org/EIPS/eip-7886)