Summary of the latest meeting of Ethereum core developers: Mainnet status and growth data analysis, Prague upgrade proposal

Original Title: “Ethereum All Core Developers Execution Call #184 Writeup”
Original Author: Christine Kim
Compiled by: Luccy, BlockBeats

Editor’s Note:

The Ethereum All Core Developers Execution (ACDE) call is held every two weeks, primarily to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 184th ACDE call, which focused on the reasons behind the increase in missed blocks on March 27, as well as new research from the Paradigm team regarding Ethereum's state and historical growth.

Developers shared insights on the Bloxroute MEV relay issue and discussed two retroactive EIPs in Prague/Electra. Additionally, development updates on EIP 7547 (inclusion list), EIP 5920 (PAY opcode), and EIP 7545 (Verkle proof verification precompile) were discussed.

Christine Kim, Vice President of Research at Galaxy Digital, took detailed notes on the key points of the meeting, and BlockBeats compiled the original text as follows:

On March 28, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #184. The ACDE call is a bi-weekly series hosted by Tim Beiko, Director of Protocol Support at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL).

This week, developers shared insights regarding the reasons behind the increase in missed blocks on March 27. Prysm developer Terence Tsao stated that this increase was caused by issues with the Bloxroute MEV relay, which the Bloxroute team is currently addressing. Developers also discussed key points from the Paradigm team's new research on Ethereum's state and historical growth. They approved the inclusion of two retroactive Ethereum Improvement Proposals (EIPs) in Prague/Electra, namely EIP 7610 and 7523.

Finally, they shared development updates on other candidate EIPs, such as EIP 7547 (inclusion list), EIP 5920 (PAY opcode), and EIP 7545 (Verkle proof verification precompile).

Mainnet Missed Block Event

On March 27, the number of missed blocks increased. Typically, 2% to 4% of blocks are missed on Ethereum every 30 minutes. However, during a period of high Blob transactions, this percentage rose to over 14% within a few hours. The price of blobs surged more than tenfold during this period. Tsao mentioned that once the Bloxroute team shut down their MEV relay, the issue of missed blocks was immediately resolved. The details leading to the Bloxroute relay issue remain unclear, and the Bloxroute team is investigating a fix, which they will share in the coming days along with a complete post-mortem analysis of the issue.

"So, the missed blocks yesterday do not imply that clients were unable to handle that type of workload, as essentially all missed blocks were caused by the Bloxroute issue. However, there is still a fundamental question of what would happen under yesterday's traffic, and I suspect that the speed at which clients import blocks may be slower than before, but that is something I have no concrete evidence for and remains to be seen," Tsao said. To address the missed block event, the Lighthouse client team released a "hotfix" version to improve node performance and stability. Additionally, while the investigation is ongoing, Bloxroute's CEO Uri Klarman stated on X that he believes these issues are unrelated to the Bloxroute relay but rather pertain to the general propagation of blobs on Ethereum.

Ethereum Foundation Developer Operations Engineer Parithosh Jayanthi inquired whether this event would lead developers to reassess client circuit breaker conditions, which automatically cause validator nodes to revert to local block production. In most clients, the default for circuit breaker conditions is the event of missing five consecutive slots. Tsao noted that overly sensitive circuit breaker conditions could serve as potential attack vectors that complex MEV actors could exploit.

Prysm developer "Potuz" expressed that, in his view, this event highlights the lack of client diversity implementation in relays and the lack of communication between relay and protocol developers. "Terence has been talking about these blobs for over a week, and no one noticed until it exploded; it only took a few calls to get the right relays to actually check their logs. This is unacceptable," Potuz said.

Some developers suggested creating written posts for future reports of network violations to increase awareness within the Ethereum ecosystem. To further discuss the missed block event, Ethereum Foundation researcher Alex Stokes encouraged developers to participate in the next MEV-Boost community call.

Analysis of State and Historical Growth Data

Storm Slivkoff, a data scientist engineer at Paradigm, conducted a new analysis of Ethereum's state and historical growth. According to his findings, state growth is not the primary bottleneck for Ethereum's scalability. "We found that existing consumer-grade hardware can sustain the current state growth rate for a long time, potentially for decades. Note that I am only talking about storage capacity and memory capacity here. This is not to say that there are no read or write claims to be made under this framework." In his view, Ethereum's "silent killer" is historical growth.

In a written analysis, the Paradigm research team explained: "State is the dataset required to build and validate new Ethereum blocks. State consists of contract bytecode, contract storage, account balances, and account nonce. History is the dataset required to sync a node from genesis to the latest block. History consists of blocks and transactions. State and history are non-overlapping datasets." Slivkoff added that the growth rate of history is significantly faster than that of Ethereum's state. The primary use case impacting historical growth rates is rollups and other types of protocols that need to bridge to Ethereum.

Slivkoff suggested that developers seriously consider accelerating solutions to historical growth in the next Ethereum upgrade Prague/Electra, such as EIP 4444 and EIP 7623. He also stated that further analysis will be conducted to examine other scalability bottlenecks on Ethereum and apply these methods to analyze rollup scalability bottlenecks as the next step in his team's research. Slivkoff mentioned that all data will be open-sourced for public use and feedback is welcome.

Following Slivkoff's presentation, developers discussed various ways to address historical growth in the short term. As discussed in ACDE #180, developers are building robust alternative networks where historical data, such as data prior to the merge upgrade, can still be accessed by users even when that data cannot be accessed through Ethereum nodes. For further discussion on historical expiration and serving historical data alternatives, Geth developer "Lightclient" suggested that developers continue the conversation in the Ethereum R&D Discord channel under a sub-channel topic titled "Historical Expiration."

Retroactive EIPs 7610 and 7523

Developers agreed to implement EIP 7610 and 7523. These are retroactive EIPs that will add rules to the Ethereum protocol that can be applied retroactively from the start of the network to further restrict certain types of on-chain behavior. The benefit of these EIPs is that they simplify Ethereum test cases and limit the scope of various edge cases, such as edge cases for creating empty accounts. The two retroactively applied EIPs include EIP 2681 and 3607. Developers agreed to activate two additional retroactive EIPs in Prague/Electra. For background information on what behaviors these EIPs constrain, please refer to the previous call notes.

EIP 2537, BLS Precompile

The Geth client team has completed some benchmarking to estimate the gas costs of EIP 2537 BLS curve operations. These new operations will be activated in the Prague/Electra upgrade, and developers are currently weighing the pricing of these operations. A representative from the Reth team stated that their team will also complete additional benchmarks for BLS curve operations to assist in determining the gas costs of these operations.

EIP 7547, Inclusion List

As discussed in ACDC #130, developers are strongly considering including EIP 7547 in the Prague/Electra upgrade. This week, Ethereum Foundation researcher Mike Neuder shared the latest information on how to modify EIP 7547 for forward compatibility with account abstraction. Account abstraction is an ongoing initiative aimed at introducing greater flexibility and programmability for externally owned accounts (EOAs) on Ethereum, which are accounts controlled by users. Neuder proposed three different approaches to address the compatibility issues between EIP 7547 and account abstraction EIPs. Regarding these solutions, Neuder stated, "It does feel like the complexity of inclusive design, but I do believe these three options are indeed valid, and I don't think there will be a silver bullet to solve this issue. I don't think we will find a better design to address these problems."

Beiko suggested continuing the discussion on inclusion list design in a separate breakout session within a limited timeframe.

Other Candidate EIPs for Prague/Electra

Next, developers reviewed the list of other candidate EIPs for the Prague/Electra upgrade. They include:

EIP 5920 (PAY opcode): Ethereum Foundation researcher Sam Wilson noted that testing work for this opcode has begun.

EIP 7609 (lowering the base cost of TLOAD/TSTORE): Charles Cooper, a contributor to the Vyper compiler, reiterated his view that TLOAD and TSTORE opcodes should be priced cheaper in the EVM.

EIP 2935 and 7545 (saving historical block hash values in state and Verkle proof verification precompile): Geth developer Guillaume Ballet presented these two proposals as code changes that would provide future benefits for Verkle implementation while helping to remind the broader Ethereum ecosystem of the upcoming Verkle upgrade.

Ethereum Object Format (EOF): Besu client maintainer Danno Ferrin stated that the EOF EIP is being implemented by multiple client teams, and reference tests are being written for them. He requested developers to refer to the EOF readiness matrix for more detailed updates.

EIP 7212 and EIP 3074 (support for secp256r1 curve and precompile for AUTH/AUTHCALL opcodes): Besu developer Matt Nelson highlighted these two EIPs that are being implemented by L2 rollups. He emphasized that to encourage compatibility between Ethereum and rollups, these two EIPs should be adopted in Prague.

EIP 7664 (access key opcode): OPLabs developer "Protolambda" proposed an alternative to EIP 3074 that leverages access lists to enhance the functionality of AUTH/AUTHCALL opcodes.

EIP 6493 (SSZ transaction signature scheme): Protolambda also expressed support for code changes related to SSZ to improve the security and efficiency of validating Ethereum data.

Developers did not have time to discuss which EIPs on this list should be prioritized for Prague. Beiko stated that time will be blocked at the start of the next ACDE call in two weeks to review this list again. "In the coming weeks, we should delve deeper into all the issues raised today and commit to making decisions. I think this means that if we want to move forward, anything that is not fully clarified or specified in two weeks may not make it into this fork," Beiko said.