Ethereum Improvement Proposals to watch in 2024

The latest Ethereum All Core Developers meeting finally put some tentative dates on the upgrade schedule for the next mainnet hard fork, Dencun.

With the caveat that it’s only “if no major issues arise,” Ethereum devs are eyeing the following dates for forking Ethereum’s public testnets:

Goerli: Jan. 17
Sepolia: Jan. 30
Holesky: Feb. 7

This will be the last time that Goerli is included in the testing regimen, as the network is slated for deprecation.

They also discussed what comes next — the as-yet-un-nicknamed Prague/Electra upgrade. The Ethereum community is considering whether to focus on a large core feature — which could take a year of work — or structure the upgrade around multiple smaller improvements, which could be feasible for late 2024.

A decision will come in the new year, but for now, here are some of the improvements to watch in 2024 in the wake of Dencun:

EIP-4844 (Proto-Danksharding)

This is the big kahuna among Dencun EIPs, which were the focus of many news stories in 2023.

The upgrade “will reduce the cost of data availability across all layer-2s,” StarkWare co-founder Eli Ben-Sasson told Blockworks. “So that’s something that Starknet is very much anticipating so that users can have lower costs.”

It’s at the “forefront” of what Lucas Henning, chief technology officer of Web3 wallet developer Suku, calls “a year of groundbreaking improvements for Ethereum.”

“[EIP-4844 is] a transformational enhancement” that will slash rollups gas fees “by up to 100x,” Henning told Blockworks.

Account abstraction comes into its own

Also at the top of Henning’s mind are improvements taking advantage of account abstraction: ERC-4337 and its extension, ERC-6900.

ERCs are a subset of EIPs focusing specifically on token standards within the Ethereum ecosystem. They define rules for token implementations to ensure interoperability. Unlike some EIPs that modify the core protocol, ERCs typically don’t require a hard fork.

ERC-4337 went live in March and the concept of account abstraction “will play a pivotal role as the most significant changes for the end-user,” Henning said.

“Account abstraction is set to revolutionize the way we perceive and interact with wallets, making gasless transactions the standard and secure social logins the new norm, fundamentally reshaping the Ethereum user experience,” he said.

Traditionally, Ethereum has two types of accounts: externally owned accounts (EOAs) controlled by private keys and contract accounts controlled by their code. Account abstraction blurs this distinction, allowing users to create accounts that behave more like smart contracts.

It can enhance both user experience and security, and allows for more complex account logic, such as multisig wallets or social recovery of lost keys.

ERC-6900, introduced the concept of “delegated transactions.” This standard, which also did not require changes to Ethereum’s mainnet consensus, allows users to delegate the ability to send transactions on their behalf, for instance, to make one approval for a batch of actions to save time and hassle.

EIP-1153 (transient storage opcodes)

This proposal, part of Dencun, aims to introduce a new mechanism for handling temporary or transient storage during smart contract execution.

Traditional storage operations on Ethereum are permanent and consume gas. This can be inefficient for temporary data that doesn’t need to persist for longer than one transaction.

EIP-1153 is an opcode (operational code) that would allow smart contracts to use transient storage — storage that would be wiped clean at the end of transaction execution.

The Uniswap team lobbied for 1153 to be included, and wanted it already in Shapella, but they couldn’t rally enough support to reach consensus among the core developers. The upgrade is expected to play a significant role in enhancing the capabilities and efficiency of Uniswap’s upcoming v4 protocol.

By enabling temporary storage, EIP-1153 can reduce the gas costs associated with storing data during contract execution and provide developers more flexibility in designing smart contracts.

And by reducing the burden on permanent storage and minimizing state bloat, EIP-1153 can contribute to the overall scalability of the Ethereum network.

EIP-4788 (Beacon block root commits)

Imagine Ethereum as a vast library with two main sections: the Ethereum Virtual Machine (EVM) section, which is like the reading room where people come to read books (execute smart contracts), and the Beacon Chain section, which is like the library’s catalog system, keeping track of all the books and their locations (consensus and coordination of the Ethereum network).

Before EIP-4788, these two sections functioned somewhat independently. The EVM section doesn’t have direct access to the up-to-date catalog; it has to rely on indirect methods to understand what’s happening in the Beacon Chain section.

EIP-4788 proposes to put a “Beacon Block Root” (a summary or hash tree root of the parent block) into each EVM block.

It’s like moving from an outdated card filing system in a library — inefficient and sometimes inaccurate — to a system with a real-time, accurate and direct link to the main library database.

In this modern library, every time a new book is added, moved or removed (the Beacon Chain updates), the readers (EVM) have immediate and accurate information. Readers can trust they’re getting the most current information and the library operations (like executing smart contracts) are more aligned with the overall catalog system (the state of the consensus layer).

All this happens in a trust-minimized manner, eliminating the need for external oracles to provide this data, and thereby reducing potential points of failure or manipulation.

This change is particularly beneficial for liquid staking protocols such as Lido, smart contract-based bridges and restaking solutions, as it allows these protocols to access crucial data like validator balances and states directly from the consensus layer, enhancing their security and operational efficiency.

EIP-4788 essentially introduces a protocol-level oracle, relaying Ethereum’s consensus state throughout the mainnet.

Misha Komarov, founder of Nil Foundation, which is deploying a zkOracle for Lido, called it “definitely helpful.”

“They need the consensus layer state root within their application logic (right now it is being proven by Casper FFG proof done via zkLLVM to the execution layer within the zkOracle design,” he told Blockworks.

EIP-5656 (MCOPY opcode)

The EVM operates using a set of opcodes that dictate various operations.

EIP-5656 introduces a new opcode called MCOPY, which is proposed to optimize the process of copying data in memory during the execution of smart contracts.

In the current EVM architecture, copying large data segments can be inefficient and costly when using existing opcodes. MCOPY offers a more efficient way, one which is expected to reduce the gas fees associated with these operations, while improving performance.

Faster memory operations mean quicker execution of contracts, and developers would have more tools at their disposal to optimize their smart contracts — particularly when dealing with large data structures or complex operations that involve memory manipulation.

EIP-6780 (restrict SELFDESTRUCT)

In Ethereum, the SELFDESTRUCT opcode allows a smart contract to delete itself from the blockchain.

When executed, it removes the contract’s code and storage from the state and sends the contract’s remaining ether to a specified address.

However, this feature has led to several issues, including complexity in state management and potential security vulnerabilities.

By restricting SELFDESTRUCT, Ethereum can better manage its state size, leading to a more stable and predictable blockchain.

This is crucial for the network’s long-term scalability and maintenance, as it will simplify future Ethereum upgrades.

Start your day with top crypto insights from David Canellis and Katherine Ross. Subscribe to the Empire newsletter.