NewsFlash Articles Data Fundraising BlockBeats Pro

Summary of the latest meeting of Ethereum core developers: Dencun will be activated on the mainnet on March 13th, and Pectra is an upgrade candidate EIP.

Read this article in 18 Minutes

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

Author: Christine Kim

Translation: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Execution (ACDE) call is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This was the 182nd call, during which developers discussed the final testing of the Dencun upgrade, candidate EIPs for the Pectra upgrade, and other related topics.

Some EIPs with potential controversy, such as code changes related to account abstraction, have attracted widespread attention and debate among developers. In addition, discussions were held on other EIPs related to the Pectra upgrade, changes to the engine API and JSON RPC. The meeting also proposed plans and suggestions for the roadmap of future light clients and a new Ethereum client version aimed at saving node bandwidth.

Christine Kim, Vice President of Research at Galaxy Digital, made a detailed record of the key points of this meeting, which BlockBeats has translated as follows:

On February 28, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #182 meeting. The ACDE conference is a bi-weekly series hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed test updates for the Dencun upgrade and several candidate EIPs for Pectra. In Pectra, the most controversial EIP discussed involved code changes related to account abstraction. Account abstraction (AA) aims to introduce higher levels of programmability for externally owned accounts (EOAs) controlled by users on Ethereum, rather than smart contract code.

Dencun Latest Developments

The Ethereum Foundation's development and operations engineer, Barnabas Busa, shared the latest progress of the Dencun upgrade. On Tuesday, February 27, 2024, the Ethereum Foundation announced that the upgrade has now been officially scheduled to be activated on the Ethereum mainnet on March 13, 2024. According to discussions during last week's ACD conference call, developers are testing the final versions of client software on the shadow fork of the mainnet, which is a test network that mimics the blockchain state and activity of the Ethereum mainnet. Busa stated that developers have conducted various types of "spam tests" on the shadow fork of the mainnet. Nodes have shown high resilience in these tests, and network participation rates have remained stable, approaching 100%. Although no issues have arisen, Busa pointed out that spam testing has put significant pressure on nodes in terms of computing resources, especially RAM and CPU expenses.

Busa then reminded everyone on the conference call that the Goerli test network will soon be deprecated. Anyone using this test network should transfer their operations to another Ethereum test network before April 17th. Busa noted that he had already seen some large validation node operators retire their machines on Goerli. This led to a finality delay on the Goerli network on February 28th, but the network seems to have recovered. Ryan pointed out that network participation on Goerli is already quite low, at around 70%. "To be honest, I don't expect participation to continue until April 17th," Busa said. "Nevertheless, it's still an interesting observation."

Busa asked his team when they should shut down Devnet 12, a test network launched by the client team in November last year to test their Dencun upgrade implementation. If there are any last-minute client releases that need to be tested on Dencun after it goes live, developers agree to shut down Devnet 12 shortly after the Dencun upgrade goes live on the Ethereum mainnet.

Pectra Traceability EIP for Upgrades

Later, developers discussed two retrospective Ethereum Improvement Proposals (EIPs) for the upgrade of Pectra. Retrospective EIPs refer to code changes made to the Ethereum protocol, mainly to retrospectively supplement constraints that already exist but need further clarification to resolve specific edge cases. The first retrospective EIP is EIP 7610, which extends a rule that limits the creation of smart contracts to addresses with pre-existing storage. For more background on this code change, please refer to the previous call record.

One concern about EIP 7610 is whether the code change will affect Verkle, a code change prepared by developers for the Pectra upgrade. Gary Rong, a Geth developer, explained that EIP 7610 will not cause any problems for the Verkle upgrade in the future. Danno Ferrin, an engineer at Hedera Hashgraph and maintainer of the Besu client, expressed some prominent concerns about the potential impact of EIP 7610 on Verkle and stated that he will share these concerns in writing in the EIP 7610 Ethereum Magicians thread.

The second retrospective EIP discussed by developers is EIP 7523, which will formalize rules to prohibit empty accounts from appearing in the state of Ethereum and its test networks. Ryan stated that he will verify with analysts again to ensure that if this rule is implemented, it will not affect any accounts on the Ethereum network (mainnet or testnet), and will bring up this discussion again at the next ACDE conference call.

Pectra Account Abstract EIP

Next, developers discussed the account abstraction EIP that may be included in the Pectra upgrade. On February 28th, some developers gathered together for a meeting specifically about AA. They discussed the broad goals of the initiative and various EIPs that could be implemented in the short and long term. Regarding the goals of AA, Ethereum co-founder Vitalik Buterin said, "So the long-term goal is that we must eventually have an account system that allows for key rotation and key revocation to allow for our quantum resistance. It also allows for smaller features such as batch transactions and sponsored transactions. Of course, the first two goals are clearly not achievable with EOAS, which clearly indicates the need to move the ecosystem beyond EOA centralization. But this also sparked a discussion about how to achieve this goal, some specific details have not been resolved, and what is the actual short-term roadmap that can achieve people's short-term goals while being compatible with longer-term goals."

Short-term, developers are evaluating three main AA EIPs, namely EIP 3074, 5806, and 7377. There is a disagreement among developers on the pros and cons between EIP 3074 and 5806. The main confusion is whether EIP 3074 requires users to double-sign transactions and whether it relies on the protocol-external AA standard ERC 4337 to sponsor transactions in a decentralized manner, as well as other debates on the relative complexity and security of EIP 3074 compared to EIP 5806. Developers generally believe that EIP 7377 is the least controversial AA EIP because it is orthogonal to the other two AA EIPs in use cases. EIP 7377 aims to help users easily migrate their assets in EOA to a new smart contract wallet, while the other two EIPs mainly focus on creating new AA features to support batch transaction authorization and gas sponsorship.

Developers have not yet reached a consensus on these three EIPs and have agreed to continue discussions in the coming weeks.

Other Pectra EIPs

Developers briefly discussed several other candidate EIPs for Pectra, including:

· EIP 7623, Increase Call Data Cost: This proposal suggests increasing the cost of regular transactions on Ethereum that primarily use blockchain for data availability. By adjusting the gas cost of call data on Ethereum, this EIP reduces the number of call data transactions that can reasonably fit in a block, thereby reducing the maximum size of blocks. The reduction in block size can allow for more blob transactions. Danny Ryan suggested that developers review this EIP in the coming weeks during a conference call.

· EIP 2537, Precompiled for BLS12-381 Curve Operations: This proposal introduces a new cryptographic signature scheme to Ethereum and has been approved for inclusion in the Pectra upgrade. One of the authors of the proposal, Antonio Sanso, raised a question about its implementation. Danny Ryan suggested documenting the issue in writing and further discussing it with developers outside of a conference call.

· EIP 5920, PAY Opcode: This proposal adds an operation that allows users to send ETH to an address without triggering any functions in that address. Geth developer Marius van der Wijden stated that further discussions with other teams revealed that testing for this EIP is more complex than expected. Van der Wijden also pointed out that the proposal's specifications are not clear enough. Ferrin added that the PAY Opcode is currently designated to use the same code number as another Opcode, AUTH, and therefore needs to be corrected by its author.

· EIP 7609, Reduce Transient Storage Pricing: This proposal suggests reducing the price of the transient storage opcode in common use cases of smart contracts, such as maintaining recursive logs. Van der Wijden and Ryan support collecting usage data on the transient storage opcode after the Dencun upgrade takes effect, and then re-discussing its pricing.

· EIP 7639, Cease Serving History Before PoS: This proposal establishes a schedule for EL clients to stop serving historical data prior to the merge upgrade. The motivation for this code change is to reduce the amount of data that Ethereum nodes need to store permanently. The proposal also promises a standardized way for nodes to structure and retrieve historical data prior to the merge from external sources. Teku developer Mikhail Kalinin pointed out that this EIP depends on another EIP, namely EIP 6110, which was approved in a previous ACD conference call and will be included in the Pectra upgrade. Developers agreed to review EIP 7639 in more detail in the coming weeks.

Engine API and JSON RPC Changes

Kalinin raised several issues related to the implementation of confirmation rules. This is a CL mechanism that confirms a block within a slot period of approximately 12 seconds, used to determine whether a block will be retained in the canonical chain and ultimately confirmed under certain assumptions. This is a powerful feature because many applications built on Ethereum can operate using information from early block confirmations. However, in order to publicly disclose data on early block confirmations, changes need to be made to the Ethereum engine API and JSON RPC, as outlined here. Due to time constraints during the conference call, Ryan suggested discussing these changes in more detail during next week's ACD conference call or the following week.

Light Client Group Discussion Room

Ryan reminded developers that a dedicated meeting will be held next Wednesday, March 6th, to discuss the light client roadmap for the Pectra upgrade. For background on the light client discussion, please refer to the previous call record.

Finally, van der Wijden proposed a new version of the Ethereum client to save 550GB of bandwidth during the initial synchronization process. Van der Wijden stated that he is preparing a formal EIP for the new version, but his specification draft can be found here. Ryan encourages developers to review the draft and raise any questions on Discord.