Ethereum Roadmap Part 4: The Splurge

The final roadmap element, the Splurge, looks at further refining everything that does not fit into any other explicit part of the roadmap.

Most of the Splurge applies to creating the endgame for various different aspects of Ethereum. This includes the endgame EVM, which includes Ethereum Object Format (EOF) and other EIPs that improve the efficiency and ease of development within the EVM, the endgame EIP-1559 that updates how fees are calculated to reduce congestion and better react to changes in demand, and the endgame account abstraction leading to smart contract wallets as the norm for enhanced user experience.

Endgame EVM

A few elements of the roadmap have to do with upgrading the EVM, with two separate tracks for simplification and improvement. Simplification refers to, as the name suggests, simplifying certain aspects of the EVM that already exist, and is technically part of the Purge but fits in nicely within the Endgame EVM. This includes banning SELFDESTRUCT, an opcode that is the root of many issues. It is the only opcode that can contribute to an unbounded number of state objects being altered in a single block, break code immutability of smart contracts, and change account balances without consent. The plan to change the functionality of SELFDESTRUCT can be found in EIP-6780, and is set to be implemented in Cancun-Deneb. This track also includes simplifying some smaller gas mechanics that Vitalik addresses here and getting rid of precompiled contracts (contracts implemented through client code that do not touch the EVM for quicker processing) in favor of more direct EVM implementations.

The improvement track consists of EVM Object Format (EOF), a group of EIPs focused on EVM bytecode when it gets deployed. Specifically they will help separate code and data for ease of use and gas savings, make new features easy to deploy, and improve the ability to detect invalid code from valid code. This is when things get very technical so bear with me here. The three primary EIPs are the following:

• EIP-3540 (EOF v1) defines the structure of EOF code, which creates a new EOF header beginning with EF00 so that the EVM can interpret EOF code differently than legacy code, and separates executable-code from non-executable data. Here is an example of EOF code in relation to legacy code: