Ethereum All Core Developers Execution Call #196 Writeup
On September 12, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #196. 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 #196, developers shared updates on the launch of Pectra Devnet 3 and discussed various Pectra code changes for implementation on future devnets. They seriously debated splitting the upgrade into two so that they can ship the code changes on Devnet 3 on a faster timeline, potentially by February next year. Developers agreed to reach a final decision about this on the next ACD call. Finally, an EF developer operations engineer by the screen name “pk910” shared updates on his work to clean up the Ethereum public testnet GitHub repositories and align their structures for easier usability.
Pectra Devnet 3
EF developer operations engineer Parithosh Jayanthi gave an update on the launch of Pectra Devnet 3. The devnet was launched on Wednesday, September 11. It includes fixes to validator consolidations in EIP 7251 and the updated specifications for EIP 7702. Based on testing so far on Devnet 3, both EIP 7251 and EIP 7702 appear to be working as expected. Jayanthi noted that there were issues discovered in the Nethermind and EthereumJS clients, which these respective client teams are working to resolve. Jayanthi added that since EIP 7702 is live on Devnet 3, it would be ideal to have wallet developers test out the implementation and provide their feedback on its use. All the information about Pectra Devnet 3, including the faucet to request testnet ETH, can be found on this website.
Pectra Specification Updates
Geth developer Felix Lange has proposed changes to the encoding of EL-triggered requests in Pectra. As background, Pectra will enable smart contracts on the EL to initiate validator withdrawals and consolidations on the CL. During the last ACD call, Lange shared a proposal to reduce the amount of work needed by EL clients to parse through these requests. Since last week’s call, Lange has formalized his proposal and the work that will be needed from EL client teams to update the encoding of the following four EIPs:
EIP 7685, General purpose execution layer requests
EIP 7002, EL triggerable withdrawals
EIP 6110, Supply validator deposits on chain
EIP 7251, Increase maximum effective balance
Developers were largely in agreement with Lange’s proposal. However, a Nimbus developer with the screen name “Dustin” argued that the proposal was “pointlessly flexible” and not forward compatible with future changes to the serialization format of the EL. He also stressed that additional specifications are needed that clearly formalize the ordering of requests by the EL clients and the behavior of CL clients if an invalid request is submitted by the EL to the CL. Lange agreed to add more text to the Engine API to specify the ordering of requests. He also agreed with Dustin that deeper thought should be given to the behavior of CL clients in the event an invalid request from the EL client is detected by the CL client.
Ethereum Foundation Researcher Peter Miller pointed out that according to the logical behavior of CL clients under current specifications, CL clients should reject blocks from the EL that are not ordered in the correct way. Further, if there is an invalid request in the list that is shared by the EL to the CL, the CL should simply process all valid requests in the list and ignore the ones that are invalid. Dustin agreed with Miller and recommended that developers specify this behavior in appropriate documentation. Beiko said that developers should aim to resolve issues with Lange’s proposal and finalize it by next ACD call.
Then, Erigon developer Andrew Ashikhmin proposed an update to EIP 7702, set EOA account code. He noted that the validity checks specified in the EIP are not consistent with the validity checks specified in older EIPs. Geth developer Matt Garnett, also known as “Lightclient”, said that he has an alternative proposal to address the consistency issue and simplify the validity checks on EIP 7702. Developers were largely in favor of finalizing Lightclient’s proposal and adding it into Pectra Devnet 4.
The next Pectra-related discussion was about the pricing for BLS precompiles under EIP 2537. Geth developer Jared Wasinger said that based on his benchmarking analysis, BLS precompiles should be twice as expensive as what is currently specified. Currently, the costs are based on multithreaded execution, which is not the standard for execution when pricing other precompiles. So, based on his analysis using single threaded execution, Wasinger has proposed changes to the discount table for the operations in EIP 2537. The Nethermind team reported that they are working on a tool so that other client teams can also easily perform their own benchmarking analysis on the EIP. Beiko recommended that teams perform their own benchmarking on BLS precompiles and chime in with their thoughts about repricing these operations over the next two weeks.
Pectra EIP Additions
Developers then moved on to the topic of adding new EIPs to the Pectra upgrade. When kicking off the discussion, Beiko warned, “We already have a ton of EIPs in Pectra. It is by far already the biggest fork by number of EIPs [included].” Based on sentiments shared by developers before the call, Beiko said it was clear that EIP 7742, the uncoupling of blob count between the EL and CL, was the least contentious on the list of EIPs still considered for inclusion in the upgrade.
EF Researcher Alex Stokes raised again the idea to split Pectra into two smaller hard forks. “I think everyone agrees that it's a really big fork. So, a natural thing to do is just to break it into two. Generally, smaller forks are less risky. In particular, with Pectra right now, there are a bunch of cross layer EIPs, which really raises the testing, security, and review load,” said Stokes. Jayanthi, who had also raised this idea on prior calls, said that he is still in favor of this idea. “I think the main reasoning is that currently, we have a lot of EIPs, and we're tending to touch many, many layers of the stack, and the more we add slash, even with the current load, it's hard for any one person to have a global view of all the changes,” said Jayanthi.
About the way current Pectra EIPs could be split across two forks, Stokes recommended shipping the first part of Pectra with all the EIPs currently live on devnets and then shipping the second part of Pectra with PeerDAS, EOF, and a few other additional EIPs. Developers felt confident that in doing so they would be able to ship the first part of Pectra by February next year. “I think a split where we still only ship the first half in say June would be a failure,” said EF Researcher Ansgar Dietrichs in the Zoom chat.
Beiko was in favor of the idea to split the fork but cautioned against removing any EIPs from devnets, as this could create more work for client teams and extend, rather than shorten, the timeline for preparing these code changes for mainnet activation. Independent Ethereum protocol developer Danno Ferrin recommended polishing the EIPs live on Devnet 3 for mainnet activation as soon as possible and then beginning work in parallel to rebase PeerDAS and EOF on Pectra EIPs starting from Devnet 4 or 5. In effect, Devnet 4 or 5 would become Devnet 0 for the upgrade after Pectra, which developers were not confident about how to name.
On a prior call, developers had agreed to name the upgrade after Pectra Fusaka but they had also agreed to reserve this upgrade for the Verkle transition. About this, Ferrin recommended that developers refrain from reserving upgrades in advance before they are confident about code change readiness for mainnet activation. This drew ire from Geth developer Guillaume Ballet who has been leading efforts on the Verkle transition and who maintained that the Verkle transition was ready “a long time ago.” To diffuse tensions, Beiko said that the point of splitting Pectra in two was ultimately to try and ship Pectra code changes on a faster timeline, which is beneficial for clearing the way for the Verkle transition thereafter.
However, there is the risk that the second part of the Pectra upgrade could become larger with the addition of more EIPs and thereby take more time to ship than if the current list of Pectra EIPs were all shipped in tandem. Nethermind developer Ben Adams questioned how the testing process for Pectra would proceed if the upgrade was split in two. Given that this is a decision that would drastically change the scope of the next immediate upgrade on Ethereum, Beiko recommended that developers take a week to think over the idea. He asked that developers be ready to make a final decision about this on next Thursday’s All Core Developers Consensus call.
Network Configuration Structure Alignment
Last but not least, EF developer operations engineer “pk910” shared updates on his work to clean up the Ethereum public testnet GitHub repositories and align their structures for easier usability. He asked client teams to review their node configurations for Ethereum mainnet and testnets and add any missing information to the respective repos.
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.