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:

In the Ethereum community, the All Core Developers Consensus Call (ACDE) is held every two weeks to discuss and negotiate improvements to the Ethereum Execution Layer (EL). This is ACDE’s 184th conference call. This conference will focus on the reasons for the increase in the number of incorrect blocks on March 27, as well as the Paradigm team’s new research on the status and historical growth of Ethereum.

Developers shared at the conference a discussion about 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.

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

On March 28, 2024, the Ethereum development community convened a Zoom meeting for the All Core Developers Execution (ACDE) call #184. The ACDE call is a biweekly series of meetings where decisions related to Ethereum's development are discussed and coordinated. Tim Beiko, the main coordinator supported by the Ethereum Foundation, led the developers in the discussion and consensus-building on proposed changes to the Ethereum Improvement Proposals (EIPs).

This week, developers shared insights into what caused the rise in the number of incorrect 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 List), EIP 5920 (PAY Opcodes), and EIP 7545 (Verkle Proof Verification Precompilation).

Mainnet missing block 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 periods when the network experiences a large number of blob transactions, this percentage rises to over 14% within a few hours. Blob prices increased more than 10x during this period. Tsao said the issue of missing blocks was immediately resolved once the Bloxroute team shut down their MEV relay. The details causing the Bloxroute relay issue are unclear, and the Bloxroute team is working on a fix, which they will share along with a full postmortem of the issue in the coming days.

"So, yesterday's missed blocks are not to say that customers cannot handle this type of workload, because basically all missed blocks are caused by Bloxroute issues. But there is still a basic problem, which is that yesterday What will happen with the traffic, I suspect, customers may be importing blocks slower than before, but that is something I have no conclusive evidence for, it remains to be seen,” Tsao said. In response to the missing block incident, the Lighthouse client The team released a "hotfix" version to improve node performance and stability. Additionally, while the investigation is ongoing, Bloxroute CEO Uri Klarman stated on

Parithosh Jayanthi, Developer Operations Engineer at the Ethereum Foundation, asked whether the incident would cause developers to re-evaluate client circuit breaker conditions that automatically cause validator nodes to fall back to local block production. In most clients, the default value for the circuit breaker condition is an event that misses five slots in a row. Tsao noted that circuit breaker conditions that are triggered too easily are potential attack vectors that sophisticated MEV actors can exploit.

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

Some developers have suggested creating written posts next time when reporting network violations 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 has conducted a new analysis of the status and historical growth of Ethereum. 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, possibly 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 data set required to build and verify new Ethereum blocks. The state consists of contract bytecode, contract storage, account balance and account nonce Composed. History is the set of data required to sync a node from genesis to the latest block. History is made up of blocks and transactions. State and history are non-overlapping sets of data. Slivkoff added that history is growing significantly faster than Ethereum The biggest use cases impacting the historical growth rate are rollups and other types of protocols that need to be bridged to Ethereum.

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

Following Slivkoff’s presentation, developers discussed different ways to address historical growth in the short term. As discussed at ACDE #180, Developers are building powerful alternative networks where historical data over a certain period, such as before a merge upgrade, can still be accessed by users in the event that the data is inaccessible through Ethereum nodes. Regarding historical expiration and services For further discussion of alternatives to historical data, Geth developer "Lightclient" recommends that developers continue the conversation on the Ethereum R&D Discord channel 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 actions these EIPs govern, see the previous call transcript here.

EIP 2537, BLS precompiled

The Geth customer team has completed some benchmarks 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, inclusion list

As discussed on ACDC #130, the 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 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 that addresses these issues.

Beiko proposes to continue discussions on incorporating the list design in separate breakout sessions for a limited time.

Other Candidate EIPs for Prague/Electra

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

EIP 5920 (PAY opcode): Ethereum Foundation researcher Sam Wilson noted that this operation Testing of the code has begun.

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

EIP 2935 and 7545 (Preserving historical block hashes in state and Verkle proof verification precompilation): Geth developer Guillaume Ballet raised these two proposals as code changes that will provide future benefits to the Verkle implementation, At the same time, it helps to remind the broader Ethereum ecosystem of the upcoming Verkle upgrade.

Ethereum Object Format (EOF): Besu client maintainer Danno Ferrin said that the EOF EIP is being implemented by multiple client teams and reference tests are being written for them. 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 these two EIPs being implemented in L2 rollup. 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" has proposed a replacement proposal for EIP 3074 that leverages access lists to enhance the functionality of the AUTH/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 bifurcation," Beiko said.

The above is the detailed content of Summary of the latest meeting of Ethereum core developers: Mainnet status and growth data analysis, Prague upgrade proposal. For more information, please follow other related articles on the PHP Chinese website!