Ethereum All Core Developers Execution Call #182 Writeup
On February 28, 2024, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #182. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, the call was chaired by Ethereum Foundation (EF) researcher Danny Ryan. Developers discussed testing updates for the Dencun upgrade and several candidate EIPs for the Pectra. The most controversial EIPs discussed for inclusion in Pectra were the code changes related to account abstraction. Account abstraction (AA) is an effort to introduce greater levels of programmability to externally owned accounts (EOAs), which are accounts on Ethereum controlled by users, as opposed to smart contract code.
Dencun Updates
EF Developer Operations (DevOps) engineer Barnabas Busa shared an update on final testing for the Dencun upgrade. The EF announced on Tuesday, February 27 that the upgrade is now officially scheduled to activate on Ethereum mainnet on March 13, 2024. As discussed on last week’s ACD call, developers are testing the final versions of client software on a mainnet shadow fork, which is a type of testnet that mirrors the blockchain state and activity of Ethereum mainnet. Busa said developers have conducted different types of “spam tests” on the mainnet shadow fork. Nodes have remained extremely resilient through these tests and network participation rates have held steady at close to 100% participation. Though there were no issues, Busa noted that the spam tests did strain nodes heavily in terms of computer resources, specifically RAM and CPU overhead.
Busa then reminded everyone on the call that the Goerli test network (testnet) will soon be deprecated. Anyone using the test network should move over their operations to a different Ethereum testnet by April 17. Busa said that he had already noticed that a few large validator node operators on Goerli have already retired their machines. This caused delays to network finality on Goerli on February 28 but the Goerli network appears to have since recovered. Ryan noted that the network participation rate on Goerli is already quite low, hovering at roughly 70%. “I don’t expect [the participation rate] to last till the 17 of April to be honest,” said Busa. “It’s something interesting to watch nonetheless.”
Busa asked when his team should expect to retire Devnet 12, a dedicated test network launched last November for client teams to test their Dencun upgrade implementations. In case there are any last-minute client releases that need to be tested for Dencun, developers agreed to shut down Devnet 12 shortly after the Dencun upgrade goes live on Ethereum mainnet.
Retroactive EIPs for Pectra
Then, developers discussed two retroactive Ethereum Improvement Proposals (EIPs) for the Pectra upgrade. Retroactive EIPs are code changes that retroactively add constraints to the Ethereum protocol that largely already exist but require clarification to account for specific edge cases. The first retroactive EIP, EIP 7610, extends a rule restricting smart contract creation to addresses with pre-existing storage. For more background on this code change, refer to prior call notes here.
One of the concerns regarding EIP 7610 was on whether the code change would impact Verkle, which is a code change that developers are preparing for an upgrade after Pectra. Geth developer Gary Rong explained how EIP 7610 would not pose any issue to the Verkle upgrade in the future. Hedera Hashgraph engineer and Besu client maintainer Danno Ferrin expressed a few outstanding concerns about how EIP 7610 may impact Verkle that he said he would share in writing on the EIP 7610 Ethereum Magicians thread.
The second retroactive EIP that developers discussed was EIP 7523, which would formalize the rule banning empty accounts from the state of Ethereum and Ethereum testnets. Ryan said that he would double check who was doing the analysis to ensure that no accounts on any Ethereum network, mainnet or testnet, would be impacted from this rule if implemented and resurface this discussion again on the next ACDE call.
Account Abstraction EIPs for Pectra
Next, developers discussed potential account abstraction EIPs for inclusion in Pectra. On February 28, a subset of developers gathered for a dedicated meeting on AA where they discussed the broad objectives for the initiative and the various EIPs that could be implemented in the short vs. long-term to achieve these goals. Speaking to the goals of AA, cofounder of Ethereum Vitalik Buterin said, “So the longer term [goal is] this fundamental desire that eventually we have to have some kind of account system that is one, allows key rotations and [two], key deprecations, to allow us quantum resistance. Three, allows batching … [and] allows sponsor transactions and a couple of other smaller things and out of those of course, the first two goals are very clearly not satisfiable with EOAS and so presents a pretty clear case for moving the ecosystem to a place where it's beyond EOA centric, but then this brought the discussion to what are actually the means to get there and what are some of the specific details that are less resolved and what actually is a shorter term roadmap that gets us goals that people want in the short term, but is at the same time compatible with those longer term [goals].”
In the short-term, developers are evaluating three main EIPs for AA, EIP 3074, 5806, and 7377. Developers on the call were divided on the advantages and disadvantages between EIP 3074 and 5806. The main sources of confusion were on the extent to which EIP 3074 would require users to double sign transactions and rely on the out-of-protocol AA standard ERC 4337 for sponsoring transactions in a decentralized way, among other debates on the relative complexity and security of EIP 3074 compared to 5806. EIP 7377 was largely agreed on by developers to be the least controversial AA EIP as it is orthogonal in terms of use case to the other two AA EIPs. EIP 7377 is designed to help users easily migrate their assets in an EOA to a new smart contract wallet while the other two EIPs focus primarily on creating new AA functionalities that would support batched transaction authorization and gas sponsorship.
Developers did not come to a consensus about these three EIPs and agreed to continue the discussion on them over the next few weeks.
Other EIPs for Pectra
Developers briefly discussed a few other candidate EIPs for Pectra including:
EIP 7623, increase calldata cost: The proposal recommends increasing the cost for regular transactions on Ethereum that primarily use the blockchain for data availability. By adjusting the gas cost for calldata on Ethereum, the EIP reduces the number of call data transactions that can feasibly fit into one block and thereby reduces the maximum size of blocks. A reduction in block size could allow for a higher number of blob transactions instead. Danny Ryan recommended that developers on the call review the EIP over the coming weeks.
EIP 2537, precompile for BLS12-381 curve operations: This proposal which introduces new cryptographic signature schemes to Ethereum has already 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 recommended that the question be put down in writing and circulated to developers for further discussion outside of the call.
EIP 5920, PAY opcode: This proposal creates a new operation that would allow users to send ETH to an address without triggering any of the address’ functions. Geth developer Marius van der Wijden said that from further discussion about this EIP with other teams, the testing for the proposal is more complicated than expected. Van der Wijden also noted that the proposal is underspecified. Ferrin added that the PAY opcode is currently specified to use the same code number as a different opcode, the AUTH opcode, so that will need to be rectified by its authors.
EIP 7609, reduce transient storage pricing: This proposal recommends reducing the price of the transient storage opcodes for common use cases by smart contracts such as maintaining a reentrancy log. Van der Wijden and Ryan were in favor of first collecting data on how transient storage opcodes are used after the Dencun upgrade goes live and then resurfacing the discussion on its pricing.
EIP 7639, cease serving history before proof-of-stake: This proposal creates a timeline for EL clients to stop serving historical data from before the Merge upgrade. The motivation for this code change is to reduce the amount of data Ethereum nodes need to store in perpetuity. The proposal also commits to a standardized way for nodes to structure historical pre-Merge data and retrieve it from an external source. Teku developer Mikhail Kalinin noted that this EIP has a dependency on another EIP, EIP 6110, which was approved for inclusion in the Pectra upgrade on a prior ACD call. Developers agreed to review EIP 7639 over the next few weeks in more detail.
Engine API & JSON RPC Changes
Kalinin raised a few questions related to the implementation of the confirmation rule, which is a CL mechanism that confirms over the period of one slot, roughly 12 seconds, whether a block under certain assumptions will remain in the canonical chain and be finalized. This is a powerful feature as many applications built on Ethereum could utilize the information of early block confirmations in their operations. However, to expose the data about early block confirmations, there needs to be a few changes made to the Ethereum Engine API and JSON RPC. Due to a lack of time on the call, Ryan recommended going over these changes in more detail either on next week’s ACD call or the one the week thereafter.
Light Clients Breakout Room
Ryan reminded developers that next Wednesday, March 6, there will be a dedicated meeting to discuss the light client roadmap for the Pectra upgrade. For background on the discussion about light clients, refer to prior call notes here.
Last but not least, van der Wijden raised a proposal to build a new Ethereum client version to save nodes 550GB of bandwidth during an initial sync. Van der Wijden said that he is preparing a formal EIP for the new version, but a draft of his specifications can be found here. Ryan encouraged developers to review the draft and follow-up with any questions on Discord.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2024. All rights reserved.