Answering the question of why EOF is Scheduled For Inclusion in Fusaka. Many have given great arguments in depth already, which I'll link below. This is a higher-level summary of the best arguments I have seen. Why EOF at all? EOF represents an acceptance that the EVM is not ready for ossification and should instead become a good base for innovations to happen on Ethereum "The EVM is like a 1950s computer and EOF makes it like a 1990s computer" - Tim Beiko To pay down the tech debt created by a hastily built EVM now that we have the benefit of years of usage and feedback "It simplifies the surface of contact with the EVM while also providing the necessary prerequisites to make future extensions easier to implement." - Solidity It is the culmination of ~10 years of research and development, iterating towards the current solution EOF Unlocks

Clients MAY drop pre-merge blocks and receipts (not headers) after May 1st 2025 https://notes.ethereum.org/_XVO7jmXTGOwZmhR5-3T9Q Besu Status Quo Use Cases Staking use case SNAP -> spec-compliant CHECKPOINT @ [deposit contract block] -> non-spec-compliant Archive use case

Previous release regression test, 27.7.0-RC1: https://hackmd.io/@siladu/HJeeuUqDA TL;DR No regression found compared to previous release, 24.7.0. Sync Time 24.7.1-RC1 SNAP (started 26/07/2024): 31 hours - dev-elc-bu-tk-mainnet-simon-perf-24.7.1-RC1-snap-01

TL;DR No regression found compared to previous release, 24.6.0. Already known memory issue noted: https://github.com/hyperledger/besu/issues/5969 Sync Time 24.7.0-RC1 (started 07/07/2024) CHECKPOINT: 21.5 hours - dev-elc-bu-tk-mainnet-simon-release-24.7.0-RC1-cp-01 20.5 hours - dev-elc-bu-tk-mainnet-simon-release-24.7.0-RC1-cp-02

Testing https://github.com/hyperledger/besu/pull/6965 Acceptance Criteria 1 node networkWhen no txs and no emptyBlockPeriodSeconds, empty blocks produced on block period When txs and no emptyBlockPeriodSeconds, blocks produced on block period When no txs and emptyBlockPeriodSeconds, empty blocks produced on empty block period When txs and emptyBlockPeriodSeconds, blocks produced on block period Block -> EmptyBlock produces after empty block period EmptyBlock -> Block produces after block period blockPeriodSeconds transitions are respected

dev-elc-bu-tk-holesky-burn-24.5.0-RC1-full-forest Java heap OOMs are bottom red arrows... besu_logs_and_memory_dev-elc-bu-tk-holesky-burn-24.5.0-RC1-full-forest Besu Starts/Restarts grep "Starting Besu" 2024-05-07T02:03:06 <-- node launch 2024-05-08T01:16:13 <-- maintenance restart

24.5.0-RC1 vs 23.3.0 Equivalent versions were used as exact versions weren't available: :::spoiler 24.5.0-RC1 24.5.0-RC1 is currently still burning in, but it is functionally equivalent to the test run on these nodes last week (24.4.0-RC3 + haltfix2) Version string: besu/v24.5-develop-c5b97d2/linux-x86_64/openjdk-java-21 commit sha is from https://github.com/hyperledger/besu/pull/7059

Date of analysis: 23/04/2024 Current state - last 30 days: Screenshot 2024-04-23 at 3.43.22 PM The node had some blocks behind spikes but finally couldn't recover start around 08/04/2024 01:00:00 - let's call this the "incident". Based on the drop in peers, this time appears to match with a (manual?) restart of one of both of the clients, but we are missing the older log so can't be sure. Screenshot 2024-04-23 at 3.48.27 PM

We introduced two new storage-saving features in Besu version 24.3.0: --Xbonsai-limit-trie-logs-enabled storage x-trie-log prune Details of the announcement here: https://wiki.hyperledger.org/display/BESU/Limit+Trie+Logs+for+Bonsai Bonsai and trie logs Besu's popular BONSAI data storage format enables a node to only store the world state for the latest, block greatly reducing storage requirements. It achieves this by maintaining state diffs between blocks called trie logs. More details about BONSAI and trie logs: https://consensys.io/blog/bonsai-tries-guide

Q: When do we trigger it? Q: Describe the algorithm Relevant Spec engine_forkchoiceUpdatedV1 https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#specification-1 Client software MAY initiate a sync process if forkchoiceState.headBlockHash references an unknown payload or a payload that can't be validated because data that are requisite for the validation is missing. The sync process is specified in the Sync section. engine_newPayloadV1

TL;DR Fork was a success. There is no required follow-up for Besu developers and no reason for Besu to delay the Mainnet fork. Overall Goerli network participation dropped to ~30% and stopped finalising, likely due to nodes with lots of validators not being updated in time, but it starting finalising again after 1.5 hours. We are now back at ~80% participation. Summary of issues No outstanding known issues with Besu Goerli nodes. Besu's Goerli validator EL logs had no errors throughout (we have one node for each CL and 4/5 had some errors in CL logs but all recovered).