It's everyone's favorite time of year! Network upgrade scoping, i.e. Ethereum Governance - Scoping Boogaloo. This year, many priorities are competing for the limited attention of the client teams, and the Besu team thinks we must seize the moment to ship some key UX improvements for both users and developers before we focus on transitioning the Ethereum state trie to Verkle trees, a huge endeavor and a huge unlock for the roadmap. First, let's catalog the state of the fork:

EIPs Included in the Pectra Fork

  • EIP-2537: Precompile for BLS12-381 curve operations

  • EIP-2935: Save historical block hashes in state

  • EIP-3074: AUTH and AUTHCALL opcodes

  • EIP-6110: Supply validator deposits on chain

  • EIP-7002: Execution layer triggerable exits

  • EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

  • EIP-7549: Move committee index outside Attestation

  • EIP-7685: General purpose execution layer requests

EIPs Being Considered for Inclusion

While EIP-7547 Inclusion Lists is Considered for Inclusion, the Besu team does not think we should pursue it in this hard fork.

Currently, Core Devs are slated to include some key upgrades to cryptography (the BLS precompile), some easy changes to prepare for Verkle (Block hashes in state), and some gas costing changes post-Cancun. The teams are committed to improving Externally Owned Accounts (EOAs) in one form or another while the Account Abstraction roadmap advances. Devnet-0 was launched following a successful interop event in Kenya, with most of these EIPs included in their preliminary iteration. Our sights are set on Devnet-1 without consensus among the Execution Layer teams on the scope. 

Mega Fork

Many other teams have presented their opinions, and we encourage you to check them out (especially Ethereum Foundation DevOps laying out some fork structures). If there is one thing that has become clear in scoping Pectra, it is that it is hard to get 15+ teams to agree on a particular approach. This is not a bug of Ethereum governance but a feature. It means the best ideas bubble to the top and become enshrined in the protocol. This sometimes manifests as scope creep and delays on upgrades, however. 

To that end, the Besu team endorses the Mega Fork structure outlined by Ethereum Foundation DevOps. All client teams have experience delivering huge forks, and we have even more tools than before to get them done. In committing to an early 2025 timeline on one fork, we can avoid having two forks with lengthy scoping discussions and delays for Verkle. There is also the operational overhead of node-operator and developer outreach related to a hard-fork that should not be understated, alongside testnet forks, network disruptions, and client hotfixes, which are necessary but delay critical client work. As we settle on a fork-a-year (or faster) cadence, we should prioritize shipping major features that provide long-tail benefits like EOF, PeerDAS, and EOA upgrades. This lays the foundation for success in advance so that we are prepared to scale Ethereum when needed.

EVM Object Format (EOF), EOAs, and Boosting UX 

Shipping EOF has tremendous unlocks on L1 and L2s as we hope to keep our increasingly fragmented chains tethered to the gold-standard VM in the EVM. EOF improves many aspects of this VM. It is a collection of smaller changes aiming at paying down a significant amount of technical debt that the EVM has accrued over nearly a decade and preparing the EVM so that ossification can occur on a robust foundation. EOF does not fundamentally change the execution of the EVM, instead, it introduces a container format and migrates key instructions to new formats that resolve long-standing problems, such as eliminating dynamic jumps and the associated JUMPDEST analysis. Generally speaking, there are four major themes addressed, including: 

  1. Making EVM code O(n) to JIT/AOT compile and easier for direct ZK compilation

  2. Eliminating Code Introspection 

  3. Eliminating Gas Introspection 

  4. Make “Quality of Life” improvements easier

The last bullet point enables features in future forks and L2 usages of the EVM. L2s can more safely perform wholesale changes to their gas schedule. Experimental and non-conforming EVM features (such as new opcodes) can be signaled with extra header fields. And because JUMPDEST analysis is replaced with deploy time code validation, the contract size limit could be safely increased or even uncapped. Team Ipsilon has launched a webpage with a more comprehensive list of features. 

The Besu team views the need for EIP-7702 as an unlock and an opportunity cost. If we do not ship something in Prague, we run the risk of not supporting Account Abstraction in EOAs on L1 for the next 1 to 2 years. The innovation unlock that comes from harmonizing smart contract wallets, and EOAs is more than just aligning Account Abstraction roadmaps. Bringing EOAs along for the ride means more users running smart accounts, better UX for all wallets, more live feedback on what we are building in Account Abstraction and EIP-4337, and a less fragmented ecosystem. 

Our client and dev(s) have spearheaded the EOF implementation since its inception and are committed to improving testing, aiding other clients in their implementations, and pushing EOF over the goal line with the smallest possible risk. PeerDAS made tremendous progress with existing and battle-tested P2P components in an astonishingly short period of time. The Besu team is committing to this scope and the anticipated timeline of Q1 2025 to ensure we do not further delay Verkle and make the transition more complex. With this scope, we ensure Ethereum can scale as we onboard the next billion users and ensure that the EVM continues to be the de facto and proliferated Smart Contract environment next to competing VMs in the space.


Ethereum Client teams are picking up velocity and getting good at shipping. Let's lean in and give ourselves a meaningful and worthwhile challenge. Follow our team on X @hyperledgerBesu for opinions, updates, and opinions, or chat with us on Discord.