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

24-03-29 14:14

Read this article in 17 Minutes

AI summary

View the summary

Original title: "Ethereum All Core Developers Execution Call #184 Writeup"

Original author: Christine Kim

Original compilation: Luccy, BlockBeats

Editor's note:

The All Core Developers Consensus Call (ACDE) of Ethereum is held every two weeks to discuss and coordinate the development of Ethereum. Changes to the execution layer (EL). This is ACDE’s 184th conference call. This conference focused on the reasons for the increase in the number of missed blocks on March 27, as well as new research from the Paradigm team on the status and historical growth of Ethereum.

Developers shared discussions at the conference regarding Bloxroute MEV relay issues and two retroactive EIPs in Prague/Electra. Additionally, development updates for EIP 7547 (Inclusion List), EIP 5920 (PAY opcodes), and EIP 7545 (Verkle Proof Verification Precompilation) were discussed.

Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of this meeting in detail. BlockBeasts compiled the original text as follows:

On March 28, 2024, Ethereum developers gathered on Zoom to participate in the All Core Developers Execution (ACDE) call #184 meeting. The ACDE Conference Call is a biweekly series of meetings hosted by Tim Beiko, Head of Protocol Support at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL).

This week, developers shared insights into what caused the rise in missed blocks on March 27. Prysm developer Terence Tsao said the uptick was caused by an issue with the Bloxroute MEV relay, which the Bloxroute team is working on. The developers also discussed key points from new research conducted by the Paradigm team on the state and historical growth of Ethereum. Developers approved the inclusion of two retroactive Ethereum Improvement Proposals (EIPs) in Prague/Electra, EIPs 7610 and 7523.

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

Mainnet Missing Blocks Event

On March 27, the number of missing blocks increased. Typically, 2% to 4% of blocks are missed every 30 minutes on Ethereum. However, during a period when the network was experiencing a large number of Blob transactions, this percentage rose to over 14% in a few hours. The price of blobs during this period increased by more than 10 times. Tsao said that once the Bloxroute team shut down their MEV relay, the issue of missing blocks was immediately resolved. The details of what caused the Bloxroute relay issue are still unclear, and the Bloxroute team is working on a fix that they will share in the coming days, along with a full post-mortem of the issue.

“So, yesterday’s missed blocks are not saying that clients can’t handle this type of workload, because basically all of the missed blocks were caused by Bloxroute issues. But there’s still a fundamental question of what happens with yesterday’s traffic, and I suspect that clients may be importing blocks more slowly than before, but that’s something I don’t have hard evidence for, and that remains to be seen,” Tsao said. In response to the missing block incident, the Lighthouse client team released a “hot fix” version to improve node performance and stability. Additionally, while the investigation is still ongoing, Bloxroute CEO Uri Klarman said on X that he believes the issues are not related to Bloxroute relays, but to the general way blobs are propagated on Ethereum.

Parithosh Jayanthi, developer operations engineer at the Ethereum Foundation, asked whether the incident would cause developers to reevaluate client circuit breaker conditions, which automatically cause validator nodes to fall back to local block production. In most clients, the default value for circuit breaker conditions is an event of five consecutive missed slots. Tsao noted that circuit breaker conditions that are triggered too easily are a potential attack vector that sophisticated MEV actors can exploit.

Prysm developer "Potuz" said that in his opinion, the incident highlighted the lack of client diversity implementation in relays and the lack of communication between relays and protocol developers. "Terence has been talking about these blobs for over a week and no one has noticed this, and once it blew up, it only took a few calls to get the right relays to actually look at their logs. This is unacceptable," Potuz said.

Some developers have suggested creating written posts next time when reporting network breaches to increase visibility of the Ethereum ecosystem. To further discuss the missing block incident, Ethereum Foundation researcher Alex Stokes encouraged developers to attend the next MEV-Boost community call.

Status and historical growth data analysis

Paradigm’s data scientist engineer Storm Slivkoff’s analysis of Ethereum A new analysis of its status and historical growth was conducted. According to his findings, state growth is not the main bottleneck in Ethereum’s scalability. “We found that existing consumer hardware can sustain current national growth rates over a long period of time, probably decades. Note that I’m only talking about storage capacity and memory capacity here. That’s not to say that Read or write to be declared under this framework. In his view, Ethereum’s “silent killer” is historical growth.

In a written analysis, the Paradigm research team explained: “The state is the set of data required to build and verify new Ethereum blocks. The state consists of contract bytes Composed of code, contract storage, account balances, and account nonces. History is the data set required to synchronize a node from genesis to the latest block. History consists of blocks and transactions. State and history are non-overlapping data sets. Slivkoff Adding that the historical growth rate is significantly faster than the Ethereum state. The biggest use cases impacting the historical growth rate are rollups and other types of protocols that require bridging to Ethereum.

Slivkoff suggested that developers seriously consider accelerating the resolution of historically growing EIPs, such as EIP 4444 and EIP 7623, in the next Ethereum upgrade Prague/Electra. He also said that further analysis will be conducted to analyze other scaling bottlenecks on Ethereum , and apply these methods to analyze rollup's expansion bottlenecks as the next step in his team's research. Slivkoff said that all data will be open source for public use, and feedback is welcome.

Following Slivkoff's presentation, developers discussed different ways to address historical growth in the short term. As ACDE #180 , developers are building powerful alternative networks in which historical data over a certain period, such as before a merge upgrade, is In the event that data is not accessible through Ethereum nodes, users can still access the data. For further discussion about historical expiration and alternative options for serving historical data, Geth developer "Lightclient" recommended that developers continue to work on the Ethereum R&D Discord channel Have the conversation in a sub-channel topic titled "History Expiration".

Retrospective EIPIP7610 and 7523

The developers agree 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 beginning of the network to further restrict certain types of behavior on the chain. The benefit of these EIPs is to simplify Ethereum test cases and limit the scope of various edge cases, such as the edge case of creating an empty account. Two EIPs that have been retroactively applied include EIPIP2681 and 3607. The developer agreed to activate two additional retroactive EIPs in Prague/Electra. For background information on what behaviors these EIPs govern, see Previous call history.

EIP 2537, BLS precompilation

The Geth customer team has completed some benchmark tests, To estimate the gas cost of EIP 2537 BLS curve operations. These new businesses will be activated in the Prague/Electra upgrade, and developers are currently weighing pricing for these businesses. A representative from the Reth team said his team will also complete additional benchmarks of BLS curve operations to assist in determining the gas costs of these operations.

EIP 7547, including list

As ACDC #130, the developers are strongly considering including EIP 7547 in Prague /Electra is being upgraded. This week, Ethereum Foundation researcher Mike Neuder shared the latest information on how EIP 7547 can be modified to be forward-compatible with the account abstraction. Account Abstraction is an ongoing initiative to introduce greater flexibility and programmability to External Accounts (EOA), which are user-controlled accounts on Ethereum. Neuder proposed three different ways to resolve compatibility issues between EIP 7547 and the Account Abstraction EIP. Regarding these solutions, Neuder said, "It does feel like the complexity of inclusive design, but I do think these three options do work, and I don't think there's going to be a magic bullet to solve this problem. I don't think we will." Find a better design to solve these problems.

Beiko recommends continuing the discussion of incorporating list design in separate breakout sessions for a limited time.

Other candidate EIPs for Prague/Electra

Next, the developer browsed Prague/ List of other candidate EIPs for Electra upgrade. They include:

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

EIP 7609 (Reducing the base cost of TLOAD/TSTORE): Vyper compiler contributor Charles Cooper reiterates his view that TLOAD and TSTORE opcodes are Pricing should be cheaper in EVM.

EIP 2935 and 7545 (Preserving historical block hashes in state and Verkle proof verification precompilation): Geth developer Guillaume Ballet presented these two proposals as Code changes are proposed that will provide future benefits to the Verkle implementation and, at the same time, help alert the broader Ethereum ecosystem of upcoming Verkle upgrades.

Ethereum Object Format (EOF): Besu client maintainer Danno Ferrin said that the EOF EIP is being implemented by multiple client teams and is being written for them Reference test. He asked developers to refer to the EOF Readiness Matrix for more detailed updates.

EIP 7212 and EIP 3074 (secp256r1 curve support and precompilation of AUTH/AUTHCALL opcodes): Besu developer Matt Nelson highlights what L2 rollup is implementing These two EIPs. He emphasized that in order to encourage compatibility between Ethereum and rollups, these two EIPs should be adopted in Prague.

EIP 7664 (Access Key Opcode): OPLabs developer "Protolambda" proposed a replacement proposal for EIP 3074 that leverages access lists to enhance AUTH/ Function of the AUTHCALL opcode.

EIP 6493 (SSZ Transaction Signature Scheme): Protolambda also expressed support for SSZ-related code changes to improve the security and efficiency of verifying Ethereum data.

The developers did not have time to discuss which EIPs on this list should be prioritized for Prague. Beiko said time will be blocked to review the list again at the start of the next ACDE conference call in two weeks. "Over the next few weeks, we should look more deeply at all of the issues raised today and work on making a decision. I think that means that if we want to move forward, in two weeks anything that hasn't been fully clarified or specified Nothing may enter this fork," Beiko said.