Summary of the latest Ethereum core developer meeting: EIP-2935 and EIP-3074 will be included in the Pectra upgrade

Editor's note:

The 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 debated the proposals vigorously and reached a preliminary consensus on whether some of them should be included in Prague. However, there were also some disputes, such as the discussion on whether EOF should be bundled with the Verkle upgrade. At the end of the meeting, the developers agreed on the next steps and decided to further test and evaluate the impact of the proposals in the future development network.

Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points of the meeting, and BlockBeasts compiled the original text as follows:

 

On April 11, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #185. The ACDE call is a bi-weekly 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 discussed code changes that should be added to the upcoming Ethereum EL upgrade, the Prague hard fork. Prague will be activated at the same time as the CL upgrade Electra, and is expected to be activated before the end of 2024.

 

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

 

EIP 2537, precompiles for BLS12-381 curve operations

EIP 6110, on-chain provisioning of validator deposits

EIP 7002, EL triggered exits

EIP 7251, increasing the maximum valid balance

EIP 7549, moving committee indexes out of attestation

 

This week, they unanimously agreed to include EIP 3074 (AUTH and AUTHCALL opcodes) and EIP 2935 (saving historical block hashes in the state) in the above list. They also decided to exclude EIP 7547 (inclusion list) and EIP 7667 (increasing the gas cost of hash functions) from Prague. Developers are strongly leaning towards bundling EIP 7667 with Verkle in Osaka, the next EL upgrade after Prague. Currently, 10 Ethereum Virtual Machine Object Format (EOF) EIPs and EIP 7623 (increase calldata cost) are still being considered for inclusion in Prague.

 

Review of what’s already included in Prague

 

Before diving into the list of EIPs being considered in Prague, developers took a short moment to review the issues with the EIPs already included in the upgrade.

 

EIP 7251

 

One of the EIPs, EIP 7251, will allow node operators to merge validators with an effective balance of up to 32 ETH into a single large validator with an effective balance of up to 2048 ETH. The effective balance refers to the staked ETH balance that a validator uses to earn issuance rewards. Balances above 32 ETH do not earn validators more issuance rewards, 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 mergers and automatic compounding of staking rewards.

 

Based on discussions between developers and large Ethereum staking pools such as Lido, they have agreed to consider changes to the EIP to make validator mergers an action triggered by smart contracts on EL. Ethereum Foundation researcher Alex Stokes highlighted his paper on how in-protocol mergers work, and asked for feedback on his proposed code changes from client teams on the call.

 

EIP 2537

 

Stokes also shared an update on EIP 2537, a proposal that adds operations to the Ethereum Virtual Machine (EVM) that enable developers to efficiently perform cryptographic signature verification using the BLS12-381 curve construction . This is a more secure and faster way to verify than using ECDSA signatures generated using the secp256k1 curve construction on EL. Stokes said that initial benchmarking work on the pricing of these operations has been completed, and developers can expect final updates on their exact gas costs in the coming weeks. In the meantime, client teams are encouraged to implement the EIP as currently scoped for the first Pectra developer testnet pectra-devnet-0 .

 

Debating What Else Should Be Included in Prague

 

Ahead of this week’s call, the EL client team provided a written update on what other EIPs they would like to see included in Prague, beyond the five they’ve already agreed to include in the upgrade. Beiko linked the EL client team’s preferences in the call agenda, and for long-term preservation, the link is below:

 

Erigon Preferences

Besu preference

Reth preference

Nethermind preference

target="_blank">Geth Preferences

 

Mega EOF Endgame

 

During discussion of other EIPs to be included in Prague, Geth developer Guillaume Ballet expressed opposition to including changes to EOF in the upgrade. He was concerned that these changes could make it difficult or impossible to implement Verkle in the upgrade following Prague, known as Osaka. In response, Danno Ferrin, lead software engineer at Swirlds Labs, raised objections, saying that EOF would be "100% compatible" with Verkle code changes. Ballet expressed skepticism about Ferrin's assessment, reiterating comments from a previous ACDE call about wanting to see EOF on the Verkle testnet. Beiko explained that it was not reasonable to evaluate EOF's compatibility with Verkle based on its functionality on a testnet in a future hard fork, and asked Ballet if he could clarify specific concerns about EOF's compatibility with Verkle. Ballet did not respond. He said there was no code specification for EOF for him to review. A developer shared a link to the latest EOF specification in the Zoom chat. A link to the readiness of EOF based on client implementations was also shared in the chat.

 

Geth developer Marius van der Wijden asked how many opcodes EOF will add or update. Beiko noted that according to the latest spec, EOF will change 18 opcodes. EOF is a bundle of code changes to the EVM from 10 different EIPs . Van der Wijden said his main concern about EOF is its complexity and how much work it will take for client teams to adequately test all edge cases in EOF. Nethermind developer Marek Moraczyński agreed that EOF could "introduce many new consensus bugs" and will require "careful testing," but the negative impact of not implementing these EIPs means these improvements to the EVM will have to wait another two or three years.

 

Ferrin noted that when developers were debating whether EOF should be included in the Shanghai upgrade, they objected to the code changes being too narrow in scope. Now that Ferrin and other developers have pushed to make EOF more widespread, client teams are pushing back as code changes that are too complex and difficult to implement. “We couldn’t get a consistent request from all core developer groups,” Ferrin said, adding that it was “frustrating” to hear complaints about two versions of EOF. The Reth and Erigon client teams supported including EOF in Prague. Beiko suggested that developers move on to discussing other EIPs and revisit the EOF discussion later in the call.

 

EIP 3074, AUTH and AUTHCALL opcodes

 

Beiko asked the client teams what they thought of EIP 3074, the introduction of the AUTH and AUTHCALL opcodes. These opcodes will add more programmability to user-controlled accounts by allowing smart contracts to authorize transactions from EOAs (externally owned accounts in Ethereum). Many developers on the call, including Georgios Konstantopoulos, Danno Ferrin, and "protolambda," supported the code change. Protolambda re-proposed his proposal, EIP 7664, which aims to fix a vulnerability in EIP 3074's logic when interacting with access lists. Geth developer and EIP 3074 co-author Matt Garnett, also known as "Lightclient," said he thinks EIP 7664 is a good idea. Another developer asked how EIP 3074 would affect the ORIGIN opcode, which returns the address that originated the transaction. Beiko said these impacts were listed in the EIP and asked if any developers objected to including this code change in Prague. There were no objections.

 

EIP 2935, Preserving Historical Block Hash State

 

Ballet introduced EIP 2935, a code change that will provide future benefits to Verkle's implementation, at ACDE #184 . The Reth client team had a "neutral to positive" attitude towards the EIP and said they had no objection to its inclusion in Prague given that it was a simple change. The Erigon client team had a similar attitude but noted that they would be less confident in its inclusion in Prague if a larger code change like EOF was included in Prague. Beiko suggested continuing the discussion on other EIPs and revisiting EIP 2935 later in the call.

 

EIP 7667, Increase Gas Costs for Hash Functions

 

Ethereum co-founder Vitalik Buterin has proposed an EIP to increase the gas costs of hash function opcodes and precompiles to match the cost of execution via zero-knowledge (ZK) systems such as ZK EVMs. For more information on ZK EVMs, read 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 took to execute them on a regular CPU. However, subsequently, another equally important execution substrate emerged: zero-knowledge proof (ZK-SNARK) systems. By this standard, these opcodes and precompiles are underpriced relative to other operations."

 

Buterin added on the call that it is easy to underestimate how common ZK proofs will become, not only for verifying things like Layer-2 rollups, but also involving Layer-1 blockchains like Ethereum. “I think we may even have the ability to do live proofs on Ethereum L1 in a year or two,” he said. “So I think it’s important to get used to the fact that there’s no longer a distinction between ZK chains and non-ZK chains. We’re now in a mode where basically every serious chain is a ZK chain.”

 

Given the changes to gas pricing and scheduling that will be made by Verkle in the Osaka upgrade, Ferrin suggested that this EIP be implemented along with Verkle. EF researcher Carl Beekhuizen said that this EIP requires a lot of investigation and developers must be "very careful" in analyzing how these gas changes will affect smart contracts on Ethereum. Van der Wijden agreed with Beekhuizen's view on cautiously moving forward with this EIP. Ferrin also suggested that these changes may be implemented on Layer-2 rollups first, while Ethereum developers further investigate its impact on Layer-1. Beiko agreed with this view and suggested that developers consider EIP 7667 for inclusion in the Osaka upgrade along with Verkle and give it a status of "CFI" or "Consideration for Inclusion". No objections.

 

EIP 7623, Increase calldata cost

 

EF researcher Toni Wahrstätter, co-author of EIP 7623, shared his update proposing to increase calldata cost and asked client teams what they thought about it. EF researcher Ansgar Dietrichs and Nethermind developer Ahmad Bitar agreed. Beekhuizen added that when EIP 7623 was brought up at the latest Rollcall meeting, a series of meetings between layer-2 rollup teams, there was no opposition to its implementation. Beiko suggested continuing the discussion on other EIPs and revisiting this EIP later in the call.

 

EIP 7645, renaming ORIGIN to SENDER

 

Beiko asked the client team what they thought of EIP 7645, a proposal to change the behavior of the ORIGIN opcode to prevent smart contract misuse. Cyrus Adkisson, who invested in Ethereum early and wrote EIP 7645, pointed out that there are three possible paths to update the ORIGIN opcode, each with different trade-offs. Ferrin said that the paths proposed to change the behavior of the opcode require careful review by security professionals and audit firms, because Ethereum protocol developers cannot fully assess the impact of such changes on existing smart contracts and end users. Beiko suggested that developers continue to discuss other EIPs for the sake of time.

 

EIP 7547, inclusion list

 

Beiko asked the developers what they thought about including EIP 7547 in Prague. Judging from the response from the EL client team, there does not seem to be widespread support for this code change. Beiko suggested excluding it from the upgrade. There was no opposition.

 

Issuance Curve Adjustment Proposal

 

Dietrichs proposed a proposal to reduce the issuance of Ethereum. Given that this change primarily affects Ethereum's execution layer, Beiko suggested that the developers further discuss the merits of this proposal on the ACDC call.

 

Revisiting EOF, EIP 7623, and 2935 for Prague

 

Developers then revisited the EIPs that had been proposed for Prague but had not yet reached consensus. Beiko asked if EOF could be bundled with the Verkle upgrade. Ballet strongly opposed the idea, saying that both code changes were complex and doing them simultaneously would be "too risky." Protolambda highlighted EIP 7664 as another EIP that should be considered for inclusion in Prague. Garnett added that EIP 7639, a proposal for clients to stop providing historical data before the merge upgrade (September 2022), should also be considered.

 

In response to concerns that the inclusion of EOF would add too much additional burden to client teams, Reth developer Georgios Konstantopoulos encouraged developers to "go all in." However, there is still no consensus on EOF. The developers ultimately agreed to continue working on EOF, especially the needed testing, and to determine later whether it should be included in Prague. They also agreed to postpone the decision on EIP 7623. Regarding EIP 2935, the developers agreed to include it in Prague.

 

Summarizing all the decisions made on the call, Beiko said that the developers will 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 title: 《Ethereum All Core Developers Execution Call #185 Writeup》

Original author: Christine Kim

Original translation: Lucy, BlockBeats