Ethereum All Core Developers Execution Call #203 Writeup
On January 16, 2025, Ethereum protocol developers met over Zoom for All Core Developers Execution (ACDE) Call #203. This week, the call was chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum.
On ACDE #203, developers talked about the launch of Pectra Devnet 5 and outstanding Pectra specifications updates. They also discussed next steps for testing gas limit increases on the Holesky testnet before Ethereum mainnet, RPC standardization efforts, and specifications for minimum node hardware and bandwidth requirements.
Pectra Devnet 5 Launch
Developers launched Pectra Devnet 5 a half hour before the start of the call. EF Developer Operations Engineer Parithosh Jayanthi said he is seeing issues with gas estimation on the devnet and will collect logs on the issue to share on the Ethereum Research & Development Discord channel.
Pectra Specifications Updates
Developers discussed five outstandings updates to Pectra code specifications. The first one updates EIP 7623, increase calldata cost, to clarify gas refund handling. The update has already been merged on GitHub and included in Pectra Devnet 5 tests.
The second update is related to the base fee fraction in EIP 7840, add blob schedule to execution client configuration files. There was no opposition to the update voiced on the call and developers agreed to merge the changes on GitHub before next Monday’s Pectra testing call on January 20.
The third update also related to blob base fees was regarding how to calculate excess gas during Pectra activation. As explained by EF Research Lead Alex Stokes, the calculation relies on information from the previous block header so if changes to blob capacity are activated at the fork boundary, meaning on the Pectra activation block, then the excess gas calculation will rely on information from the prior block constructed using old fork rules. Stokes said developers should clarify whether the blob capacity increase is activated at the fork boundary or one block after the fork boundary. “I don't think it really matters which thing we do, but we should all do the same thing,” said Stokes. Developers agreed to clarify EIP 7691, increase the number of blobs to reach a new target and max of 6 and 9 blobs per block respectively, so that the new excess gas calculations occur one block after the fork boundary and therefore uses new fork rules only. This is the logic that is already being tested for in clients, said EF Testing Developer Mario Vega. Geth developer “Lightclient” said that he would update EIP 7691 by next Monday’s testing call with the clarification.
The fourth update is related to multiplication cost calculations in EIP 2537, precompile for BLS12-381 curve operations. Developers agreed to include clarifications that specify division in the EIP as integer division. Client teams passing Pectra Devnet 5 tests should already have this logic in their code, so the change is only required on the specifications side. EF EVM Developer Paweł Bylica said that he would makes changes to the EIP on GitHub by Monday’s testing call.
Lastly, the fifth update is related to EIP 7702, add a new transaction type that permanently sets the code for an Externally Owned Account (EOA). COO of Otim Labs Julian Rachman proposed a behavior change to the EIP that would enable code introspection. As detailed in a document written by the Otim Labs team, code introspection “refers to a legacy contract’s ability to inspect its own bytecode or the bytecode of an external contract and change behavior based on that information.”
Code introspection is a behavior that developers working on EVM Object Format (EOF) are working to disable in a future Ethereum upgrade. However, as detailed in the document and on the call, enabling introspection for checking an EOA’s “delegate_address” would not hamper progress on EOF. The benefits to allowing introspection for checking delegation in an EIP 7702 type transaction is to support the safe use of relayers and other external accounts when enabling EIP 7702 type functionality such as gas sponsorship.
Lightclient was in favor of including this update in Pectra specifications. “It feels like a very easy thing for us to update. We’re already determining if the thing is a 7702 delegating account and adding in the address to the designate we return is extremely simple,” said Lightclient. Beiko recommended giving call participants a few more days to review the changes before making a final decision on its inclusion. He recommended revisiting the topic on Monday’s testing call.
Beiko requested that Rachman’s team create a formal pull request on GitHub with all the proposed changes to EIP 7702 for developers to discuss on Monday. Regarding discussions about whether this update would require developers to launch a new Pectra devnet for testing purposes, Jayanthi said the change could be included in a public testnet shadow fork instead. All other specifications updates discussed on the call, Beiko added, also does not require a new Pectra devnet so developers can likely move forward with updating public testnets after further testing on Pectra Devnet 5.
Pectra System Contract Audit Updates
EF Protocol Security Researcher Fredrik Svantes said that all third party audits of the system contracts in Pectra have been completed. There were no major findings and the audit reports will be uploaded on GitHub for client teams to review. Svantes also recommended dedicated time on the next ACDE call for the auditors to present their findings and answer any questions from client teams.
Pectra Testnet Scheduling
Beiko proposed a rough schedule for testnet upgrades moving forward. He proposed setting a block number for upgrading the Sepolia and Holesky testnets on the next two ACD calls and preparing client releases for them by February 3, 2025. He recommended aiming for a Sepolia fork sometime during the week of February 12 and a Holesky fork sometime during the week thereafter on February 19. Assuming no major bugs or issues, this would mean that the Pectra upgrade could go live on Ethereum mainnet three to five weeks after the Holesky fork in early to mid-March. There were no objections voiced on the call to Beiko’s proposal. Stokes voiced his support for coupling client releases for the Sepolia and Holesky tesnet upgrades.
Holesky Gas Limit
EF General Engineer Sophia Gold proposed setting the default gas limit in clients for the Holesky upgrade release to 36m and continuing to increase the default gas limit going forward on Holesky so that it is always higher than the gas limit on Ethereum. This would ensure that gas limit increases on mainnet can always be tested prior on Holesky. There were no objections to the proposal on the call. Representatives from the Teku, Besu, Prysm and Nethermind team said their client releases for Holesky are already set to a default gas limit of 36m.
RPC Standardization Efforts
Geth developer Felix Lange expressed frustration at the lack of feedback from client teams on efforts to standardize Ethereum JSON-RPC specifications. Among several issues, one that Lange voiced on the call was a lack of clarity about the scope of RPC standardization efforts and what types of ecosystem stakeholders should be included in the discussion. Lange wrote a detailed explanation of his efforts to standardize the RPC and proposed next steps in a blog post. Beiko recommended further discussion about this on Discord and a dedicated breakout meeting on the topic. Besu developer Justin Florentine said that he would spearhead coordination for scheduling the breakout meeting.
Specifying Node Hardware & Bandwidth Requirements
EF Applied Researcher Kevaundray Wedderburn requested feedback on his document detailing the minimum node hardware and bandwidth requirements for Ethereum. Beiko asked whether these requirements should be drafted as an informational EIP for easier reference by developers and the broader Ethereum community. Prysm developer “Potuz” said that the node requirements for validating nodes and full nodes are different and so, the document should make this distinction clear. Beiko agreed with Potuz and recommended further discussion on the topic of node hardware and bandwidth requirements and next steps for formalizing Wedderburn’s document on Discord.
EIP Editors Workshop
There will be an EIP Editors Workshop organized by the Ethereum Cat Herders group on January 17, 2025 at 16:00 UTC. The meeting will provide an overview of the EIP editing process. All Ethereum community members interested in learning more about the EIP workflow and editing process are encouraged to join the meeting. A recording of the meeting will also be made available on YouTube afterwards.
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 endorsement of any of the stablecoins 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, hedged and sold or may own, hedge and sell 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 2025. All rights reserved.