Week 7 EPFsp Recap

Week 7 EPFsp Recap ## Week 5 EPFsp Recap Greetings all, Accomplishments this week: Protocol studies wiki - [chore: add world state trie docs](https://github.com/eth-protocol-fellows/protocol-studies/pull/411) - When 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***. Reth PR's: - [chore: add status enum for handshake to support status69 decoding](https://github.com/paradigmxyz/reth/pull/15543) - I resolved a GH issue by updating the status message handling of the wire protocol to accomodate changes introduced by EIP-7642, which removes the total difficulty field in the Eth69 handshake. Previously, Reth only supported the legacy status format. So if a peer sent an Eth69 status, our decoding would fail. To solve this, I introduced a new `StatusMessage` enum with variants `Status` and `StatusEth69` and then updated the decoding logic to handle the `StatusEth69` variant as well. This solution lets us correctly decode and validate incoming status messages from peers regardless of whether they use the legacy or Eth69 format, without breaking the wire protocol. - Reth PR's: - [chore: implement serde_bincode_compat for envelope](https://github.com/alloy-rs/op-alloy/pull/486) - To support the ongoing migration from Reth's custom transaciton primitives to the standardized `alloy` transaction types, I implemented `SerdeBincodecompat` support for `OpTxEnvelope` within the `alloy` ecosystem. Ths involved porting and adapting the bincode-compatible serialization module from Reth's transaction structures to `alloy::consensus`, ensuring compatibility with multiple EIP-style transaction formats such as Legacy, EIP-2930, EIP-1559, EIP-7702, and Deposits. Studies on Verkle Trie: - Verkle trees are a next-generation state structure for Ethereum, designed to enable stateless clients by dramatically reducing proof sizes while maintaining efficient verification. Each internal node in a Verkle trie uses a KZG commitment to cryptographically commit to 256 child values, which are treated as evaluations of a low-degree polynomial. Specifically, a node encodes its children into a polynomial `f(x)`, where each child value corresponds to `f(i)` for `i=0…255`, and then commits to this polynomial using a KZG scheme that produces a single elliptic curve point. To prove that a specific value exists at index i, a short witness (a KZG evaluation proof) is provided, which allows a stateless verifier to confirm the value is consistent with the commitment using a pairing-based check. In practice, when a stateless Ethereum node receives a block, it uses a witness bundle—composed of these proofs and the necessary sibling commitments—to reconstruct the relevant Verkle trie paths in memory, verify all state accesses against the block’s pre-state root, execute the transactions, and recompute the post-state root for validation. This allows full participation in block validation without needing to store or access the full Ethereum state locally. Additionally, I attended the study group sessions on the Engine Api. I asked some questions during the lecture to gain clarity on some concepts.