Ethereum core developers' latest meeting summary: EIP-2935 and EIP-3074 will be included in the Pectra upgrade.

Bitget App

Trade smarter

Bitget

News

View original

律动BlockBeats2024/04/12 05:25

By:律动BlockBeats

Original Title: "Ethereum All Core Developers Execution Call #185 Writeup"

Original Author: Christine Kim

Original Translation: Luccy, BlockBeats

Editor's Note:

Ethereum All Core Developers Consensus Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 185th ACDE call, where developers had in-depth discussions and evaluations on the code changes required for the upcoming Prague hard fork and other EIPs.

Developers engaged in heated debates on various proposals, reaching preliminary consensus on whether some proposals should be included in Prague. However, there were also controversies, such as discussions on whether EOF should be bundled with the Verkle upgrade. At the end of the meeting, developers reached an agreement on the next steps of the work plan and decided to further test and evaluate the impact of various proposals in future development networks.

Christine Kim, Vice President of Research at Galaxy Digital, detailed the key points of this meeting, and BlockBeats translated the original text as follows:

On April 11, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #185 meeting. The ACDE call is a bi-weekly series of meetings supported by the Ethereum Foundation protocol manager Tim Beiko, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed the code changes to be added to the upcoming Ethereum EL upgrade - the Prague hard fork. Prague is expected to be activated simultaneously with the CL upgrade Electra, with activation expected to be completed by the end of 2024.

Initially, developers agreed to define the scope of Prague/Electra (Pectra) to include five Ethereum Improvement Proposals (EIPs). They are:

EIP 2537, precompile for BLS12-381 curve operations

EIP 6110, on-chain supply verification deposits

EIP 7002, EL trigger-based exits

EIP 7251, increase maximum effective balance

EIP 7549, remove committee index from authentication

This week, they unanimously agreed to include EIP 3074 (AUTH and AUTHCALL opcodes) and EIP 2935 (save historical block hashes in state) in the above list. They also decided to exclude EIP 7547 (contain lists) and EIP 7667 (increase gas cost of hash functions) from Prague. Developers strongly lean towards bundling EIP 7667 with Verkle in the next EL upgrade after Prague, Osaka. Currently, there is consideration to include 10 Ethereum Object Format (EOF) EIPs and EIP 7623 (increase calldata cost) in Prague.

Review of Included Content in Prague

Prior to delving into the EIP list under consideration for Prague, developers spent a short time reviewing the issues existing in the EIPs already included in the upgrade.

EIP 7251

One of the EIPs, EIP 7251, will allow node operators to merge validators with effective balances of up to 32 ETH into a single large validator with an effective balance of up to 2048 ETH. Effective balance refers to the staked ETH balance from which validators receive issuance rewards. Balances over 32 ETH do not bring additional issuance rewards to validators, which is why node operators must run multiple validators to increase their issuance rewards. EIP 7251 aims to reduce the number of active validators on Ethereum by enabling validator merging and automatic compounding of staking rewards. Following discussions with major Ethereum staking pools like Lido, developers have agreed to consider changes to the EIP to make validator merging an operation triggered by a smart contract on the EL. Ethereum Foundation researcher Alex Stokes emphasized his paper on how internal merging operates and requested feedback from client teams on the code changes he proposed during the call.

EIP 2537

Stokes also shared the latest on EIP 2537, which adds operations to the Ethereum Virtual Machine (EVM) allowing developers to efficiently perform cryptographic signature verification using the BLS12-381 curve. This is a more secure and faster way than using the secp256k1 curve on the EL to generate ECDSA signatures. Stokes mentioned that initial benchmarking work on pricing these operations has been completed, and developers can expect final updates on their exact gas costs in the coming weeks. Meanwhile, client teams are encouraged to implement the EIP within the current scope for the first Pectra developer test network, pectra-devnet-0.

Debate on What Else Prague Should Include

Prior to this week's call, EL client teams provided written updates on additional EIPs they wished to include in Prague, beyond the five EIPs they had already agreed to include in the upgrade. Beiko linked EL client teams' preferences in the call agenda and provided the following for long-term reference:

Erigon preference

Besu preference

Reth preference

Nethermind preference

Geth preference

Mega EOF Endgame

When discussing additional EIPs to include in Prague, Geth developer Guillaume Ballet expressed opposition to changes involving EOF in the upgrade. He was concerned that these changes might make it difficult or impossible to implement Verkle in the upgrade following Prague (referred to as Osaka). In response, Danno Ferrin, Chief Software Engineer at Swirlds Labs, presented a counterpoint, stating that EOF could be "100% compatible" with Verkle code changes. Ballet expressed skepticism towards Ferrin's assessment, reiterating his previous comments from an ACDE call about wanting to see EOF on a Verkle test network. Beiko explained that evaluating EOF's compatibility with Verkle based on its functionality in future hard fork test networks is not reasonable and asked Ballet to clarify specific concerns about EOF's compatibility with Verkle. Ballet did not respond, stating that there were no EOF code specifications for him to review. A developer shared the latest EOF specification link in the Zoom chat. The chat also shared a link on EOF readiness based on client implementations.

Geth developer Marius van der Wijden inquired about how many opcodes EOF would add or update. Beiko pointed out that according to the latest specification, EOF will change 18 opcodes. EOF is a bundle of EVM code changes from 10 different EIPs. Van der Wijden noted his main concerns about EOF were its complexity and how much work client teams would need to fully test all edge cases in EOF. Nethermind developer Marek Moraczyński agreed that EOF could potentially "introduce many new consensus bugs" and would need "careful testing," but not implementing these EIPs would mean waiting another two to three years for these improvements to the EVM.

Ferrin pointed out that when developers debated whether EOF should be included in the Shanghai upgrade, they opposed the narrow scope of these code changes. Now, Ferrin and other developers have been working to broaden EOF, but client teams are against it due to the complexity and difficulty of implementing the code changes. Ferrin said, "We can't get a consistent request from all core developer groups." He added that hearing complaints about two versions of EOF was "frustrating." Reth and Erigon client teams also expressed their concerns.

The client team support in Prague includes EOF. Beiko suggested that developers shift the discussion to other EIPs and revisit the discussion on EOF later in the conference call. EIP 3074, AUTH and AUTHCALL Opcodes Beiko asked the client team about their thoughts on EIP 3074, specifically the introduction of AUTH and AUTHCALL opcodes. These opcodes will allow smart contracts to authorize transactions from EOAs (externally owned accounts) and add more programmability to user-controlled accounts. Many developers on the call, including Georgios Konstantopoulos, Danno Ferrin, and "protolambda," supported this code change. Protolambda reintroduced his proposed EIP 7664, aimed at fixing the logic of EIP 3074 when interacting with access lists. Geth developers and co-author of EIP 3074, Matt Garnett, also known as "Lightclient," expressed support for EIP 7664. Another developer inquired about how EIP 3074 would affect the ORIGIN opcode, which returns the address that initiated the transaction. Beiko stated that these impacts are listed in the EIP and asked if any developers opposed including this code change in Prague. There were no objections. EIP 2935, Saving Historical Block Hash State Ballet introduced EIP 2935 in ACDE #184, a code change that will bring future benefits to the implementation of Verkle. The Reth client team expressed a "neutral to positive" attitude towards this EIP and mentioned that, considering it is a simple change, they do not oppose its inclusion in Prague. The Erigon client team shared a similar attitude but noted that their confidence in including it in Prague would be lower if larger code changes like EOF were included. Beiko suggested continuing discussions on other EIPs and revisiting EIP 2935 later in the conference call. EIP 7667, Increasing Gas Cost of Hash Functions Ethereum co-founder Vitalik Buterin proposed EIP 7667 to increase the gas cost of hash function opcodes and precompiles to align with the execution cost through zero-knowledge (ZK) systems like ZK EVMs. For more information on ZK EVMs, please refer to the Galaxy Research report. Regarding the motivation for repricing Ethereum hash function operations, Buterin wrote in the EIP 7667 document: "The gas costs of hash function opcodes and precompiles were originally set based on the time it takes to execute them on a regular CPU. However, subsequently, another equally important use case emerged: zero-knowledge proofs (ZK-SNARK) systems. By that standard, these opcodes and precompiles are underpriced relative to other operations." Buterin further mentioned in the conference call that it is easy to underestimate the increasing prevalence of ZK proofs, not only for verifying Layer-2 rollups but also involving Layer-1 blockchains like Ethereum. He stated, "I think that even within a year or two, we might have the ability to do real-time proofs for Ethereum L1. So, I think it's important to adapt to the fact that there's no longer a distinction between ZK chains and non-ZK chains. We're basically entering a mode where every serious chain is a ZK chain." Considering that the Verkle upgrade in the Osaka hard fork will change gas pricing and schedules, Ferrin suggested implementing this EIP alongside Verkle. EF researcher Carl Beekhuizen mentioned that this EIP requires extensive research, and developers must analyze carefully how these gas changes will impact smart contracts on Ethereum. Van der Wijden agreed with Beekhuizen's cautious approach towards advancing this EIP. Ferrin also suggested potentially implementing these changes first on Layer-2 rollups and then investigating their impact on Layer-1 Ethereum further. Beiko agreed with this approach and suggested developers consider including EIP 7667 with Verkle in the Osaka upgrade, giving it a "CFI" or "consider for inclusion" status. There were no objections. EIP 7623, Increasing calldata Cost Co-author of EIP 7623, EF researcher Toni Wahrstätter, shared his proposal to increase the cost of calldata and asked the client team for their opinions. EF researcher Ansgar Dietrichs and Nethermind developer Ahmad Bitar expressed their support. Beekhuizen added that there were no objections to implementing EIP 7623 when it was proposed at the latest Rollcall meeting, a series of meetings between Layer-2 rollup teams. Beiko suggested continuing discussions on other EIPs and revisiting this EIP later in the conference call. EIP 7645, Renaming ORIGIN to SENDER Beiko inquired about the client team's thoughts on EIP 7645, which aims to change the behavior of the ORIGIN opcode to prevent smart contract misuse. Cyrus Adkisson, an early Ethereum investor and author of EIP 7645, pointed out that updating the ORIGIN opcode has three possible paths, each with different trade-offs. Ferrin mentioned that paths proposing changes to opcode behavior require careful review by security professionals and audit firms, as Ethereum protocol developers cannot fully assess the impact of such changes on existing smart contracts and end users. Beiko suggested that, for time considerations, developers continue discussing other EIPs. EIP 7547, Inclusion List Beiko asked developers about their opinions on including EIP 7547 in Prague. Based on the response from the EL client team, there doesn't seem to be widespread support for this code change. Beiko suggested excluding it from the upgrade. There were no objections. Proposal to Adjust the Issuance Curve Dietrichs proposed a reduction in the issuance of Ethereum. Considering that this change mainly affects Ethereum's execution layer, Beiko suggested that developers further discuss the advantages of this proposal in the ACDC conference call. Revisiting EOF, EIP 7623, and 2935 for Prague Developers then revisited the EIPs proposed for Prague that had not reached a consensus. Beiko inquired whether EOF could be bundled with the Verkle upgrade. Ballet strongly opposed this idea, stating that both code changes are complex, and implementing them simultaneously would be "too risky." Protolambda emphasized that EIP 7664 is another EIP that should be considered for inclusion in Prague. Garnett added that EIP 7639, a proposal regarding client stop providing historical data before the merge upgrade (September 2022), should also be considered. Concerns were raised about the additional burden that including EOF would place on the client team, with Reth developer Georgios Konstantopoulos encouraging developers to "go all-in." However, there was still no consensus on EOF. Developers ultimately agreed to continue working on EOF, especially the required testing, and decide later whether it should be included in Prague. They also agreed to postpone the decision on EIP 7623. Regarding EIP 2935, developers agreed to include it in Prague. Summarizing all decisions made during the conference call, Beiko stated that developers would include EIP 3074 and EIP 2935 in the first development network of the Pectra upgrade. After this development network, they agreed to decide whether to include EOF and/or EIP 7623 in the second Pectra development network. [Original Article Link] Welcome to join the official community of BlockBeats: Telegram Subscription Group: https://t.me/theblockbeats Telegram Communication Group: https://t.me/BlockBeats_App Twitter Official Account: https://twitter.com/BlockBeatsAsia

Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.

PoolX: Locked for new tokens.

APR up to 10%. Always on, always get airdrop.

Lock now!