Ethereum All Core Developers Execution Call #200 Writeup
On November 7, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #200. 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 #200, developers shared updates about the Pectra devnets and next steps for PeerDAS devnets. They also discussed a short-term solution to the problem of history growth on Ethereum and the removal of EIP 7610 from Pectra. EIP 7610 is one of two retroactive EIPs in Pectra that would not add any features to the protocol but rather formalize and constrain protocol rules.
Pectra Devnet 4 & Mekong Updates
EF Developers Operations Engineer Parithosh Jayanthi said the official blog post announcing the Mekong testnet has gone live on the Ethereum Foundation website. The blog post details the ways that application and tooling developers can join the testnet and start experimenting with the EIPs in Pectra.
Jayanthi also said that his team plans on deprecating Pectra Devnet 4 soon. Geth developer Marius van der Wijden said he had planned on doing some testing on Devnet 4 over Devcon, an Ethereum developer conference starting on November 12. So, Jayanthi said his team could keep Devnet 4 running during Devcon and reconnect with developers on an appropriate time after the conference to shut down the devnet.
About Mekong, Jayanthi said there was an incident on the testnet where the head vote percentage was “extremely low”. Jayanthi asked if any developers on the call investigated this issue. It did not appear that any developer had. Jayanthi said that his team would debug the issue over the next few days.
Pectra Devnet 5 Preparations
The proposed changes to EIP 7702 discussed on ACDE 199 have been implemented by a developer with the screen name “Frangio”. Beiko asked if there were any objections to these changes. Given no objections, Beiko confirmed these changes will be added to the specifications for Pectra Devnet 5.
Then, Geth developer Felix Lange proposed refinements to the fee logic of the withdrawals contract detailed in EIP 7002 (Execution layer triggerable withdrawals). Lange’s proposal raised some concerns from other developers on the call. Beiko recommended that developers continue the discussion about the refinements asynchronously and aim to come to a final decision about them on before the next ACDE meeting.
Individual EIP Activations
Ethereum Foundation Researcher Alex Stokes raised questions about how developers could test PeerDAS on a “Fusaka” devnet without activating other code changes that have been included in the Fusaka upgrade like EOF. For more background on this topic, refer to prior call notes or the podcast summary on ACDC #145.
Nethermind developer Łukasz Rozmej said that his client by default offers fine grained control over the EIPs activated at a specific epoch. “So, we don't generally have a concept of hard fork [in our client]. We generally set all the EIPs separately to the same number activation. We don't have the ‘Osaka’ parameter. We set those EIPs [individually] and that's it,” said Rozmej.
Lange said the reason Geth does not have this fine tuned control over EIPs is due to the concern that activating EIPs individually may introduce additional complications in code. “For example, when we load the chain configuration in Geth, we also check that the forks are not activated out of order. So basically, you cannot have a fork without a previous one or something. These features because they are meant to be activated on top of each other, if we had the ability to selectively disable certain EIPs or only enable some of them, it could create these weird situations that the client isn't designed to handle, and we do not test these configurations either, so the outcome is basically undefined,” explained Lange.
Rozmej said the reason the Nethermind team opted for such fine tuned control of EIP activation in their client is because their users wanted to repurpose their client for use on different blockchains where certain EIPs are activated, but not the whole suite of EIPs. Rozmej said to address Lange’s concerns, they can add labels to the EIPs such that EIPs with the same label can be activated at once by default.
About the topic of activating PeerDAS and EOF on separate epochs in Fusaka devnets, independent Ethereum protocol developer Danno Ferrin said that having multiple activation targets over the course of multiple devnets would be difficult and confusing for developers. Beiko recommended then testing the consensus layer and execution layer parts of the Fusaka upgrade separately such that the CL upgrade can be activated without the EL upgrade. Lange noted that each upgrade will eventually require changes to the Engine API which impacts both layers of Ethereum. However, for now, developers did agree that the Fusaka upgrade could be tested on devnets as a consensus layer only upgrade and an execution layer only upgrade until the two upgrades are rebased on top of each other down the road.
eth/70, Sharded Blocks Protocol
Erigon developer Giulio Rebuffo proposed a new EIP to extend the functionality of the Ethereum wire protocol and offer a short term solution to the problem of history growth. Rebuffo said that based on his research, validators will be required to operate hardware with at least 4TB of disc by mid-2025 due to the growth of history data. He said the alternative solution for pruning history data, EIP 4444 and the Portal Network, will not likely be ready in time to prevent validator node operators from having to update their machines in roughly 6 months.
Rozmej pushed back on Rebuffo’s proposal asking what aspects exactly about the Portal Network were not ready in his view for clients to start utilizing it to prune history data on Ethereum nodes. Beiko said that he could follow up directly with the Portal Network team to get more information. Jayanthi added that he would like to see updates about the security audits of the Portal Network first before considering it as ready for implementation and use by all clients. Lange posited that integrations with Portal have not started in earnest due to the fact EIP 4444 is not “on the critical path”, meaning it is not a required EIP for an immediate hard fork.
Rebuffo said that in his view management of history should be determined individually by client teams rather than standardized through a protocol like Portal. “We are not keen to support Portal Network over the long-term,” said Rebuffo. EF Researcher Ansgar Dietrichs agreed with Rebuffo’s sentiment saying that there was “no inherent reason to standardize” how clients prune history data, as history data is not required for nodes to reach consensus. Rebuffo and Beiko recommended continuing the discussion on paths forward for history expiry in-person at the upcoming Ethereum developer conference Devcon.
EIP 7610 Potential Removal
On ACDE #182, developers agreed to include two retroactive EIPs in Pectra that do not introduce any new features to Ethereum but rather constrain and formalize rules of the protocol to avoid specific edge cases. Paweł Bylica, an Ethereum Foundation developer working on the EVM, shared concerns about EIP 7610 related to unexpected difficulties in its implementation among clients like Erigon. Before removing the EIP from Pectra, as suggested by Beiko, van der Wijden recommended reaching out to the authors of the EIP to get their thoughts on Bylica’s concerns. Van der Wijden also asked if a counter proposal to EIP 7610 could be created to compare alternative solutions to addressing specific edge cases in the Ethereum protocol. Bylica agreed to write down what he had in mind as an alternative and discuss the matter asynchronously with EIP 7610 authors.
ACD Call Schedule
Next week’s ACDC call will be cancelled. There will be an in-person gathering of Ethereum developers at the Devcon conference. The last day of the conference will be dedicated to breakout discussions about important topics in Ethereum’s development roadmap. More information about the schedule for this day, November 15, can be found here. Finally, Beiko announced that the Monday testing call on November 18 will be cancelled and held on Thursday, November 21 instead. There will be no ACDE call on November 21.
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.