# EPF Week 3 Updates

This week, I had the opportunity to present my project, [EIP-7886](https://eips.ethereum.org/EIPS/eip-7886), to some core devs. During my presentation, I mentioned that one challenge would be to perform E2E testing of the implementation in a devnet since the required CL changes would not be ready by the time I finish this project. Afterwards, a core dev encouraged me to perform the CL implementation as well, in [Lighthouse](https://github.com/sigp/lighthouse). Then, I should be able to run a local devnet setup using [Kurtosis](https://github.com/ethpandaops/ethereum-package) and perform E2E as well as benchmarking.

The CL changes required seem relatively lightweight. Essentially, the `BeaconBlockBody`'s `ExecutionPayload` will have to pass the new fields required by the EL for delayed execution:

# Pre-execution state root - this is the state root before executing transactions
    pre_state_root: Root  

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

At the conference, I met with a Lighthouse dev, and he will connect me with someone from their team in order to get on the same page for the scope.

Overall, this is pretty awesome since I'll now be able to get some CL and EL exposure from the project. Both stacks are fascinating, and I look forward to diving into Lighthouse codebase.

Additionally at the conference, I attended a 3 hour EthMagicians forum where we discussed topics regarding draft EIP's and the structure of [eth-magicians](https://ethereum-magicians.org/) vs [ethresearch](https://ethresear.ch/). The consensus was that these could be combined in order for ease of use by newbies. Additionally, we discussed the pros and cons of delayed execution vs [epbs](https://eips.ethereum.org/EIPS/eip-7732), which is a more CL focused approach to give you the same benefits. It seems that there are some client implementations of epbs, which has helped make the spec feel quite solid at this point. However, delayed execution does not have similar client implementations, so my hope is that by building this out in reth + lighthouse, it can aid in the decision making process.

## Week 4 TODOs
Next week, I plan to:
- Investigate lighthouse codebase to understand required changes
- Study CL mechanisms to ensure I have enough context to build this out
- Update project proposal to include CL component + Kurtosis testing