Ethereum All Core Developers Execution Call #202 Writeup
On December 19, 2024, Ethereum protocol developers met over Zoom for All Core Developers Execution (ACDE) Call #202. This week, the call was chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko and EF Researcher Alex Stokes. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum.
On ACDE #202, developers discussed updates to Pectra specifications impacting EIP 7742, EIP 7702, EIP 2537, and EIP 2935. They also discussed the rollout plan for removing pre-merge history data from clients and non-Pectra EIPs requiring feedback from developers.
As a reminder, ACDE #202 is the last ACD call for the next two weeks. The ACDC call scheduled for Thursday, December 26 is cancelled and the ACDE call scheduled for Thursday, January 2 will be replaced by a Pectra testing call.
Pectra Testnet and Devnets
EF Developer Operations Engineer Parithosh Jayanthi said Mekong is still up and running. Mekong is the public Pectra testnet based on Pectra Devnet 4 specifications that was launched last month in November. Client teams are making headway in their implementations for Pectra Devnet 5. Jayanthi said that Besu and Teku are the farthest along in terms of testing, with Lodestar not far behind. Once Pectra Devnet 5 specifications are finalized and more client implementations pass local testing, Jayanthi said developers can then launch Pectra Devnet 5. There is no specific date for the devnet launch yet, though developers are aiming for some time late December or early January.
Pectra Devnet 5 Specifications
Developers discussed several updates to Pectra Devnet 5 specifications impacting the design of EIP 7742, EIP 7702, EIP 2537, and EIP 2935.
EIP 7742
EIP 7742, uncouple blob count between CL and EL, will be replaced by EIP 7840, blob counts configured at genesis. This was a decision made on the previous ACD call, ACDC #147, that was reaffirmed on this week’s call. EIP 7840 is a simpler way to implement a change to the blob capacity. EIP 7742 was removed from Pectra due to implementation complexity and concerns that the code change would delay the Pectra upgrade. Beiko affirmed later in the meeting that EIP 7840 should be included in Pectra Devnet 5 specifications.
EIP 7702
The following are two updates to the chain_id field in EIP 7702, set EOA account code:
The latter one ensures that the chain_id size is not unnecessarily limited to the “uint64” value type. Using a larger “uint256” type ensures more forward compatibility and interoperability with other chain configurations. Developers agreed to move forward with making the chain_id uint256 in Pectra Devnet 5.
As for the former change, removing chain_id in authorization tuple, the author of the proposer Geth developer Felix Lange said that he would close this pull request for now and come back to the group once he has thought through other changes he would like to propose for EIP 7702.
EIP 2537
Nethermind developer Marek Moraczyński shared the final pricing model for EIP 2537, precompile for BLS12-381 curve operations. The updates to EIP 2537 are detailed in the following four pull requests (PRs):
The first three PRs reduce the cost of BLS operations overall, said Moraczyński. The last PR recommends removing multiplication in EIP 2537 as it is a redundant operation. Though removing MUL is additional effort for clients and the testing team, there was no strong objections to including it or the other 3 PRs presented by Moraczyński in Pectra Devnet 5.
EIP 2935
Geth developer “Lightclient” shared updates from an independent audit conducted on all system contracts required for Pectra. One of these contracts is for EIP 2935, serve historical block hashes from state. Lightclient said the audit suggests small changes to the EIP to bring it in line with the structure of other system contracts in Pectra. Developers agreed to also include these changes for testing in Pectra Devnet 5.
Jayanthi asked if there were any updates to the builder API. Stokes said that updates were in progress and close to finalization. He added that that efforts to update the builder API for Pectra can happen in parallel to devnet progress and should not be a blocker to Devnet 5 launch.
EIP 4444
Developers are preparing for a partial rollout of EIP 4444, history expiry. As discussed on ACDE 201, client teams are preparing to prune and stop serving history data from before September 2022 when the Merge upgrade was activated. Client teams are preparing alternative pathways for their users to retrieve this pre-merge history data such as through the use of the Portal Network. Beiko said that developers should hammer out a testing strategy for clients as they work on supporting the new networking protocol version, eth/70, and dropping older versions. Lightclient recommended incorporating testing for EIP 4444 with Pectra testing. Developers debated how exactly to go about doing this. Beiko recommended discussing the matter asynchronously from the call on Discord. He said that if developers cannot reach consensus on Discord, they can schedule a breakout meeting after the holidays to finalize the path forward for testing EIP 4444.
Decoupling Gas Price from Payload Size
Nimbus developer “Arnetheduck” presented a few solutions to issues with the gas and gossip limits. As discussed on ACDC #147, the gas limit on the execution layer may create blocks larger than what the consensus layer can propagate. The maximum size of blocks is restricted by a gossip limit on the consensus layer that is subject to change only by client teams. However, the gas limit on the execution layer is subject to change by validator node operators. Arnetheduck shared a few solutions to ensure that only blocks valid according to both fork choice rules and network rules can be propagated. One of these solutions recommended deriving the gossip limit from the gas limit. Lightclient resurfaced an EIP to set a maximum gas limit that validators cannot change. Developers debated the merits of different approaches to addressing the gas and gossip limit interdependencies.
Due to limited time on the call, Beiko recommended continuing the conversation asynchronously on GitHub or EthResearch.
Reverting Removal of NewBlock(Hashes) in eth/69
Beiko said that he had to leave the meeting early and handed over moderation for the rest of the call to Stokes. The next topic of discussion was about a change to eth/69. Erigon developer Andrew Ashikhmin recommended keeping fields related to new block hashes that were deprecated in Ethereum clients after the Merge upgrade in eth/69. Ashikhmin said removing these fields are unnecessary since the fields are not used and keeping them would support compatibility of eth/69 with other blockchains that have not activated the Merge upgrade such as the Polygon blockchain. Lange said that he is not opposed to keeping the fields. Later in the call, Besu developer Justin Florentine wrote in the Zoom chat that he is opposed to keeping the fields “forever” and would follow up on this discussion asynchronously.
EIP 7503
A Github user by the screen name “0xwormhole” requested feedback on his additions to EIP 7503, zero knowledge wormholes. Stokes asked developers on the call to take a look.
EIP 7808
EF Researcher Carl Beekhuizen proposed reserving a range of transaction types from 0x40 to 0x7f for use by rollup teams. The motivation for this is like the motivation for reserving a range of precompile addresses for rollups. For rollups to use new transaction types, it is necessary to ensure that there are no conflicts between transaction types used on rollups and Ethereum Layer 1. There was no opposition to Beekhuizen’s proposal.
EIP 4803
The next meeting agenda item was about EIP 4803, limit transaction gas to a maximum of 2^63-1. Lange said that the EIP has already been retroactively applied in all clients and the executable specifications should be updated to reflect this change. It was unclear what action item if any was needed from developers about this agenda item. Lange recommended that any developers wishing to change the behavior of EIP 4803 or further restrict transaction gas should create a new EIP instead of commenting on or trying to make a change to EIP 4803.
Announcements
The changes to the EIP approval process discussed on ACDC #147 have been finalized. EIPs labeled as “Considered for Inclusion” or CFI will be considered EIPs that developers plan on including in a devnet, any future devnet, for an upgrade. EIPs labeled as “Scheduled for Inclusion” or SFI will be considered EIPs that developers plan on including in the next immediate devnet for an upgrade.
EF Researchers Davide Crapis and Ansgar Dietrichs proposed the creation of an “EVM Resource Pricing Working Group” to coordinate efforts across different Ethereum research groups on benchmarking and repricing EVM opcodes. Developers on the call were largely in favor of this proposal.
Ethereum Cat Herder Pooja Ranjan requested input from developers on the following two items related to the EIP process:
The first redefines the categorization of meta EIPs, EIPs that detail information about Ethereum’s governance process. It has also been used for EIPs that offers a comprehensive list of all code changes included in a network-wide upgrade. The first item recommends restricting the “meta” EIP category to only process-related EIPs and excluding EIPs summarizing hard forks.
The second item recommends removing the list of retroactively applied EIPs from EIP 7675 and instead listing these EIPs in their own section in a hard fork summary EIP. Stokes asked developers to review both changes and offer feedback if any on them.
As a reminder, ACDE #202 is the last ACD call for the next two weeks. The ACDC call scheduled for Thursday, December 26 is cancelled and the ACDE call scheduled for Thursday, January 2 will be replaced by a Pectra testing call.
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.