Original title: 《Ethereum All Core Developers Execution Call#185Writeup》

Original author: Christine Kim

Original translation: Lucy, BlockBeats

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 had a heated debate on the proposals and reached a preliminary consensus on whether some of them should be included in Prague. However, there were some disputes, such as the discussion on whether EOF should be bundled with the Verkle upgrade. At the end of the meeting, developers agreed on the next work plan and decided to further test and evaluate the impact of various 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. 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, Prague hard fork. Prague will be activated at the same time as the CL upgrade Electra, which is expected to be activated before the end of 2024.

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

EIP 2537, Precompilation of BLS12-381 curve operations

EIP 6110, on-chain provisioning of validator deposits

EIP 7002, EL Triggered Exit

EIP 7251, increasing the maximum effective balance

EIP 7549, moving committee indexing out of authentication

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 gas costs for hash functions) from Prague. Developers strongly prefer to bundle EIP 7667 with Verkle in Osaka, the next EL upgrade after Prague. Currently, 10 Ethereum Virtual Machine Object Format (EOF) EIPs and EIP 7623 (increasing calldata costs) are still under consideration for inclusion in Prague.

Review of what's included in Prague

Before diving into the list of EIPs under consideration in Prague, the 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 effective balances 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 a validator 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 staked 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 merges an action triggered by smart contracts on EL. Ethereum Foundation researcher Alex Stokes highlighted his paper on how in-protocol merges 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 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.

Debate what else Prague should include

Prior to this week’s call, the EL client team provided a written update on the additional EIPs they would like to see included in Prague, in addition to the five they have 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 Predilection

Reth Preference

Nethermind Preferences

Geth Preferences

Mega EOF Endgame

During a discussion of other EIPs to be included in Prague, Geth developer Guillaume Ballet voiced opposition to including EOF’s changes 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, countered that EOF would be “100% compatible” with the 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 assess 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 spec for EOF for him to review. A developer shared a link to the latest EOF spec in a Zoom chat. Links to client-side implementations of EOF readiness were 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 broadly, client teams are pushing back on the idea that the code changes would be 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 this code change. Protolambda re-proposed his proposal, EIP 7664, which aims to fix a vulnerability in the EIP 3074 logic when interacting with access lists. Geth developer and EIP 3074 co-author Matt Garnett, also known as "Lightclient," said he thought EIP 7664 was a good idea. Another developer asked how EIP 3074 would affect the ORIGIN opcode, which returns the address that originated the transaction. Beiko said that these effects are laid out in the EIP and asked if any developers objected to the inclusion of this code change in Prague. There were no objections.

EIP 2935, save historical block hash state

Ballet introduced EIP 2935 at ACDE #184, a code change that will bring future benefits to Verkle's implementation. The Reth client team had a "neutral to positive" attitude towards this EIP, and said that 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 it included a larger code change like EOF. Beiko suggested continuing the discussion of other EIPs and revisiting EIP 2935 later in the call.

EIP 7667, increasing the gas cost of hash functions

Ethereum co-founder Vitalik Buterin has proposed an EIP that aims 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 re-pricing 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 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’s easy to underestimate how common ZK proofs will become, not only for verifying things like layer-2 rollups, but also layer-1 blockchains like Ethereum. “I think even in a year or two, we may have the ability to prove Ethereum L1 in real time,” 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.”

Ferrin suggested implementing this EIP along with Verkle, given the changes to gas pricing and scheduling that will be made in the Osaka upgrade due to 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 might be implemented on Layer-2 rollups first, while Ethereum developers further investigate their 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 "CFI" or "Consideration for Inclusion" status. No objections.

EIP 7623, increasing calldata cost

EIP 7623 co-author and EF researcher Toni Wahrstätter shared his update proposing to increase calldata costs 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 presented 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 one later in the call.

EIP 7645, renames 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 proposed path to change the behavior of the opcode requires 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, including list

Beiko asked developers what they thought about including EIP 7547 in Prague. Judging from 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 for adjustment of the issuance curve

Dietrichs proposed a proposal to reduce the issuance of Ethereum. Given that this change primarily affects Ethereum’s execution layer, Beiko suggested that 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 were proposed for Prague but have 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 are complex and doing them at the same time 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 was still no consensus on EOF. Developers ultimately agreed to continue working on EOF, especially the required testing, and determine 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 the decisions made during 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.