EIP-7732 Checklist Beacon Chain Changes Introduction [X] Constants[X] Domain typesShane - PR [X] Misc [X] Preset

EPF Week 6 Updates Recently, I had a conversation with lighthouse about delayed execution, and their stance is that since eip-7732, epbs, is likely to go into Glamsterdam, my efforts would be better used to aid them in building out epbs. The headliner decision for the hard fork will be August 7th, but almost all signals point towards eip-7732. Since the whole point of the EPF program is to provide an opportunity towards long-term core dev work, it seems like an obvious choice to take lighthouse up on their offer to help out. A nice article on the pros and cons of delayed execution verses epbs are laid out here. In a nutshell, you get the same execution block size scaling benefits via epbs as you do in delayed execution but additional wins like trustless payments between block builders and proposers + much more time to propagate blobs. After diving pretty heavily into the epbs specs, I can see how the aforementioned benefits align with Ethereum's pillars of scaling the base layer and expanding blob capacity. At it's core, epbs splits a consensus block from an execution payload, which lends naturally to the separation we have today between the CL and EL. It's pretty exciting, the more you look into it! This week, I have started implmenting new EthSpec constants and new containers per epbs consensus spec in PR: Constants > Domain types Preset > Misc + Max Operations per block ContainersPayloadAttestationData

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

EPF Week 5 Updates This week, I focused on incorperating the Lighthouse related requirements for delayed execution into my project proposal. Then, I submitted the project proposal for review via PR. The proposal's timeline is updated to reflect building out the lighthouse pieces first followed by reth. However, from talking to lighthouse's team, they're working on a glamsterdam template, which would be useful for me to build my POC on top of, since it will contain a lot of the boilerplate I will need to mimic a hardfork for delayed execution. In the meantime, I started working on the Header changes required for delayed execution to support the new pre_state_root and related fields in PR. These changes were made in a fork of the alloy repo, which contains primitive types utilized by reth. TLDR of changes: Extended Block Header fieldsAdded new header fields for delayed executionUpdated the Header struct with new eip-7886 fields Made new fields Option<…> so pre-fork headers remain unchanged After fork, include new fields and deprecate use of original state_root, transactions_root, receipts_root, logs_bloom.

Delayed Execution splits block validation into two steps. When you receive block N, the execution layer only checks its header and verifies that it correctly references block N – 1’s execution results (state root, receipts, logs). Running block N’s transactions happens later, so the validator can vote on the block much faster. A nice overview of the delayed execution proposal, EIP-7886, is detailed in https://nerolation.github.io/delayed-execution-docs/. Motivation Reduce block validation and attestation latency Significant throughput improvements across the network Higher block gas limit Project Description

The following checklist will be used to track progress of CL related changes for EIP-7886, delayed execution. Engine API New Structs[ ] Define JsonExecutionPayloadEip7886 with all EIP‑7886 fields [ ] Implement From / TryFrom conversions between JsonExecutionPayloadEip7886 and ExecutionPayloadEip7886 HTTP constants [ ] Add ENGINE_NEW_PAYLOAD_EIP7886 [ ] Add ENGINE_GET_PAYLOAD_EIP7886

This week, I had the opportunity to present my project, 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. Then, I should be able to run a local devnet setup using Kurtosis 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

Before this week, I mostly studied the static validation updates that will be required for EIP-7886, delayed execution. This week, I wanted to take a closer look at the post-validation phase in a slot, from the EL's perspective, which is when the transaction execution will take place. Project Updates Execution Phase With delayed execution, we'll be processing the tsx after the block itself has been validated, hence the decoupling of block validation and execution. To support this decoupling, we'll modify process_transactions in a few ways:

This week, I started off by building some additional familiarity of reth via a couple FOSS contributions: chore: add node synced helper chore: add block gas limit to block added log Building small features for the codebase is teaching me the team's preferred coding patterns, which I believe will make it easier to implement my project. Project Updates In my previous post, I dove into the engine api updates that will be required to implement for delayed execution. This week, I investigated EIP-7886's EL static validation flow updates as to gain a solid understand about why each aspect is important.

References TL;DR EIP-7886 Delayed Execution Delayed Execution splits block validation into two steps. When you receive block N, the execution layer only checks its header and verifies that it correctly references block N – 1’s execution results (state root, receipts, logs). Running block N’s transactions happens later, so the validator can vote on the block much faster. Engine Api Overview The engine api is primarily used by the CL to alert the CL of a new block tip via LMD-Ghost's fork choice rules and also to notify the EL that there is a new block ready to be validated. Block Proposals

Week 7 EPFsp Recap Week 5 EPFsp Recap Greetings all, Accomplishments this week: Protocol studies wiki chore: add world state trie docsWhen an aspiring core dev would stumble through the EPF wiki, they would land upon the execution layer data structures page and just see a stub for the World State Trie, which is sad. Now, the section describes the World State Trie rather robustly. I found it important to highlight how this trie differs from the Receipt Trie and Transaction Trie in that the World State Trie is persistent across blocks since it holds the current state of Ethereum accounts whereas the other tries are recreated for each block. I also added some color regarding the account specific data held in each leaf node of the trie, [nonce, balance, storageRoot, codeHash], and how to traverse the trie using nibbles derived from the sha256 hash value of the 20 byte account address. In addition, I described how the World State Trie is a Merkle Patricia Trie based data structure where the state root is a cryptographic commitment to the current state of Ethereum. Additionally, account specific info such as balances can easily be verified by knowing the state root and a Merkle Proof containing the account and it's sibling nodes needed to recreate the state root.

Week 5 EPFsp Recap Greetings all, I've been having so much fun with the EPFsp and learning core concepts of the EL and CL. Since a big factor in being a successful EPF member is one's ability to write clearly, I've decided to start documenting my journey here. Accomplishments this week include some PR's to the protocol studies wiki: chore: add merkle patricia trie diagramI found that the existing description of the Merkple Patricia Trie didn't provide enough detail as to how the trie traversal worked and why that makes it an efficient data structure for data storage. Therefore, I added a diagram and example trie traversal flow to explain how node edges have compressed path representations that make tries more compact leading to storage efficiency and efficent lookups. I added a Merkle Patricia Trie Diagram as well and gave a full trie traversal example to help readers understand how traversal and hashing work together to store verifiable data for scenarios like when a proposed block is rerun by other full nodes to check that state root hash is correct or when a light client needs a merkle proof to verify a value from account trie for example.