Analysis of failure of UncleFromSideChain_Merge and UncleFromSideChain_Shanghai. They have the same cause but will take an in-depth dive of UncleFromSideChain_Shanghai as an illustration. Test Description Import block 1 through 8 in order. Block 1 - 3 corresponds to blocknumber 1 through 3 on chainname='A' Block 4 - 8 are on chainname='B'. blocknumber for these blocks is 1, 2, 3, 4, 4 in the respective order Block 7 is intentially be a bad block Timestamp of block 8 is greater than block 3 Expected outcome upon calling eth_getBlockByNumber for the latest block should be block 8 but Besu returns block 3

Introduction This is an analysis on the consensus, p2p and beacon api spec on the usage of pubkeyCache - a collection of pubkey2Index and index2Pubkey, and whether they require the knowledge of validators whose initial deposit is not yet finalized (See the rationale of unfinalized cache in background). These are the places that require validator's index or pubkey to perform signature verification where bls.Verify() or bls.FastAggregateVerify() is used. Background The use of pubkeyCache (pubkey2Index and index2Pubkey) cache is critical for CL clients to allow efficient lookup of public keys and indices of validators in many places particularly during state transition. The populating of said cache happen during deposit processing which assign indices to new validators. In the current deposit flow, the indices assigned to new validators are uniform across all branches in the block tree due to the large follow distance of Eth1Data poll. Therefore, a single global fork-independent pubkeyCache is sufficient. EIP-6110 proposes a refrom to the deposit flow that 1) Shifts the deposit inclusion and validation to EL 2) Deprecates the Eth1Data voting mechanism, CL no longer has a large follow distance and hence a validator index becomes fork dependent ie. a validator with the same pubkey can have different indices in different block tree branches.

To implement ePBS on Lodestar. PBS is an important component on the Ethereum roadmap that provides many benefits such as censorship-resistence to transactions and fairness between hobbyist and insitutional validators. Although MEV-boost has already provided the separation of proposers and builders, the out-of-protocol solution is deemed to be brittle from recent attacks that targeted MEV-boost relays. There is also a significant cost is time and labour to maintain the compatibility between CL clients and relays especially during hard forks. As such, there is a demand of ePBS advocated by the community which provides a in-protocol solution for PBS. Through implementing ePBS on Lodestar, it serves as an initiative of slowly transitioning ePBS from research stage to a concrete stage of engineering. Project Description There are a lot of ideas and designs floating around for ePBS. However the community has not agreed on a single design yet. PTC is one of the more mature designs among them and we shall head to the direction of experiementing with it on Lodestar as well as proposing updates to the specification of all the affected components in the Ethereum protocol until the community holds strong opinion for an alternative design. Area of Focus This is a non-exhaustive list of areas we would like to focus on. If there is any change to the PTC design or any sort of unforseenable blockage, the list might change.

Background EIP-6110 was initally funded by ESP in February 2023. The previous estimation of the project length was two months and therefore we received two months of funding. However due to various challenges, we realized extra time is needed to complete the project. The project is semi-wrapped up in mid July after our presentation on ECH and ACDC albeit there is still a single outstanding item. Project Description https://hackmd.io/@n0ble/deposit-reform-prototype Item Breakdown Action Description Status

Initial implementation of ePBS on Lodestar. PBS is an important component on the Ethereum roadmap that provides many benefits such as censorship-resistence to transactions and fairness between hobbyist and insitutional validators. Although MEV-boost has already provided the separation of proposers and builders, the out-of-protocol solution is deemed to be brittle from recent attacks that targeted MEV-boost relays. There is also a significant cost is time and labour to maintain the compatibility between CL clients and relays especially during hard forks. As such, there is a demand of ePBS advocated by the community which provides a in-protocol solution for PBS. Through implementing ePBS on Lodestar, it serves as an initiative of slowly transitioning ePBS from research stage to a concrete stage of engineering. Project Description There are a lot of ideas and designs floating around for ePBS. However the community has not agreed on a single design yet. PTC is one of the more mature designs among them and we shall head to the direction of experiementing with it on Lodestar as well as proposing updates to the specification of all the affected components in the Ethereum protocol until the community holds strong opinion for an alternative design. This is a non-exhaustive list of areas we would like to focus on. If there is any change to the PTC design or any sort of unforseenable blockage, the list might change. Consensus Specs

Case Fail Description Can be found in tests (Non-exhaustive) Comment 1 can't get genesis: Post "http://172.17.0.10:8545": dial tcp 172.17.0.10:8545: connect: connection refused envInfo,invalidDiffPlaces, opcDDDiffPlaces, idPrecomps and more Seems to happen pretty randomly. When it happens, Hive attempts to call Besu before Besu finish initializing.