Ethereum All Core Developers Execution Call #189 Writeup
On June 6, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #189. 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. This week, developers agreed to include EOF and EIP 7702 in the Pectra upgrade. To prevent delays in multi-client testing for the upgrade with the addition of these code changes, developers agreed to activate EOF on later-stage devnets and possibly on a different activation epoch from other EIPs, like how developers plan on testing PeerDAS. They also discussed ways to deactivate EIP 158 in preparation for Verkle in the Osaka upgrade, and next steps for implementing EIP 4444 through integration with the Portal Network. Finally, Beiko and the EF Developers Operations (DevOps) team shared updates to governance processes and communication channels for planning Ethereum upgrades.
Pectra Scope
Prior to this week’s ACD call, various EL client teams and the EF DevOps team shared their views on what the scope of Pectra should be.
Based on the views shared prior to the call, it was clear that most client teams were in favor of including EOF in Pectra. The only client team that expressed strong views against EOF was Geth. Geth developer Guillaume Ballet said, “My fear is that the more we wait, the longer the Verkle translation will take. Is EOF really that urgent? I don't think so. I've read several the arguments for shipping it in Prague. The more I read those arguments, the more I realize, no, there’s nothing that really justifies EOF.” Several developers pushed back on this.
A developer with the screen name “Kamil Sliwak” said that from the perspective of users interacting with the compiler for Ethereum’s smart contract programming language Solidity, EOF would be “a huge improvement.” Reth developer Dragan Rakita added that it is disingenuous to suggest that EOF will significantly delay the Verkle transition. “We are talking about 10% to 20% longer transition time. EOF is not going to increase the state and the three additional months that we will need to ship additional [parts of the] fork is not going to delay Verkle … a lot,” said Rakita. For more information about what EOF is and how it will improve the Ethereum Virtual Machine (EVM), listen to this episode of the Infinite Jungle podcast.
Beiko asked if developers would prefer bundling EOF with other Pectra EIPs or splitting out Pectra EIPs across two hard forks. Erigon developer Andrew Ashikhmin said that in his view developers should either try and ship all Pectra EIPs together or delay EOF until after the Verkle transition. “My least preferable [option is] to have a fork between Pectra and Verkle to ship EOF. Because I agree with Guillaume that the state is growing, and I think Verkle is more important than EOF. So, in my mind, I think that's the worst outcome,” said Ashikhmin. Beiko recommended aiming to ship all Pectra EIPs including EOF in one client release. However, for the purposes of testing, he said that developers should consider using the devnets to stage the implementation of these code changes. “Use devnets as a way to sequence what we prioritize in terms of testing on the multiclient front and then if we see that that EOF is going to delay stuff for a very long time, we can then make the call to split it out,” said Beiko.
Alongside these conversations about how to scope EOF into Pectra, Geth developers continued to share sentiments in the Zoom chat and throughout the call questioning if EOF should be included in the upgrade at all. To address persisting disagreement about EOF by the Geth team, Reth developer George Konstantinopoulos said, “Let's just do it. It is a bit confusing where the conversation [is going] … We don’t mind extending the Verkle transition by a couple days. The data says the state is going down so that is a confusing argument in the first place and you have a bunch of applications that's telling you this is a good feature. It’s just confusing why we're considering not doing it given that most people have voiced support.”
Beiko agreed with this sentiment and reiterated that EOF should be included in Pectra but tested on devnets in a staged manner, meaning client teams should test existing EIPs implemented on Devnet 0 in Devnet 1. Then, on a future devnet, add EOF to the mix. This strategy will ensure that client teams remain focused on shipping a subset of Pectra EIPs on the same timeline and can continue to make progress on multi-client devnets. EF DevOps Engineer Mario Vega said that in two months he expects to be ready with the EL specifications tests for EOF. EF DevOps Engineer Parithosh Jayanthi said that EOF can be tested in isolation from other EL EIPs in Pectra. However, he is concerned about the interdependencies between CL EIPs in Pectra and the complexities related to testing these code changes.
Vyper compiler developer Charles Cooper said that in his view EOF is not as urgent as his proposed code changes for making protections against reentrancy attacks cheap and commonplace on Ethereum. Beiko reminded Cooper that while there is broad consensus for EOF, it is unclear if client teams will have the bandwidth for adding even more code changes like his related to reentrancy attacks to the fork. “I think what's also pretty clear is if we do move forward with EOF there's very little bandwidth to do anything else. It would already be the largest fork by far,” said Beiko.
In addition to the inclusion of EOF, developers also agreed to include EIP 7702 as a replacement to EIP 3074. There are issues with the specifications for EIP 7702 that developers are still working out in separate breakout room meetings. Beiko recommended taking a similar approach to implementing EIP 7702 as with EOF. “I would include it in the fork but not have it part of Devnet 1 or 2 if we're not quite happy with where the spec is and then spend the next month … actually ironing out the specs so that we have like a revocation mechanism that's essentially better than what's proposed now. It doesn't seem like a huge EIP to add a bit later in the process,” said Beiko. Geth developer “Lightclient” said that if client teams are ready, they should implement EIP 7702 as soon as possible. There were no objections to including EIP 7702 in the next immediate Pectra devnet, Devnet 1.
Pectra Specs
Then, Teku developer Mikhail Kalinin shared a few updates to existing Pectra EIP specifications. The first was a proposal to process EL triggered requests to the consensus layer (CL) through a sidecar mechanism rather than directly within the EL block. Prysm developer “Potuz” noted that this strategy would break logic needed for a future code change, enshrined proposer builder separation (ePBS). “The beacon block should not be contingent to the payload already being present. So, withdrawals, deposits, whatever, you do not want to have the beacon block depend on something that the payload needs to have, because this breaks the flow of ePBS,” said Potuz. Due to this issue, Kalinin agreed to withdraw his proposal and close the pull request on GitHub.
Kalinin shared a few other changes to EL and Engine API specifications for Pectra, one of which would enable EL triggered consolidations under EIP 7251, increase the MAX_EFFECTIVE_Balance. Beiko recommended developers review these changes before the next ACD call so that they can be finalized and ready for testing in Devnet 1.
Verkle Prep
Based on his work for the Verkle transition, Ballet said that EIP 158 will cause similar issues as the deprecated opcode SELFDESTRUCT. To avoid complications on the network after the transition, Ballet proposed that developers deactivate EIP 158 in the Pectra upgrade. However, he also noted that if the implementation of EIP 7702 in Pectra is tweaked, the deactivation of EIP 158 could potentially be pushed and happen at the same time as the Verkle transition. Beiko recommended that Guillaume start drafting his proposal for deactivating EIP 158.
History Expiry
Alongside Pectra and Verkle, Ethereum protocol developers are working towards EIP 4444, history expiry. As stated in the EIP 4444 plan and summary document, the reason for this code change is that “block history takes up a lot of space [on nodes] and once that block has been finalized, it is only needed for limited use cases that are not consensus critical.” With EIP 4444, the document goes on to state, “block history will no longer be stored permanently by full nodes. After some period of time, it will be removed from nodes, and entities that need it, will need to query for it from somewhere else.” The Portal Network is an alternative, decentralized network for nodes to query Ethereum history data.
Merriam reiterated his team is available to support EL client teams with their Portal Network integrations. Without any support, he said the integration takes roughly 6 months to build out. However, with guidance and close collaboration, he is optimistic that meaningful progress can be made on EIP 4444 over the next 2 months. Jayanthi asked if a security-focused audit of Portal Network specifications had been done. Merriam said no. EF Researcher Ansgar Dietrichs asked if client teams can decide for themselves how to interface with the network, either by bundling the integration with their existing client, building a new client, or simply not moving forward with any integration at all. Merriam affirmed that the decision was up to the client team.
Merriam asked EL client teams on the call about their progress and intentions to work on EIP 4444. Nethermind developer Łukasz Rozmej said, “Overall, it is a priority. We even had a meeting yesterday with the Portal team. The problem is that there are so many priorities. It's sometimes hard to juggle everything correctly. So, it's the less urgent priority compared to for example the hard fork but Nethermind will be working on it and we will prioritize it.” Besu developer Matt Nelson said that his views were the same. Geth developer Guillaume Ballet said that his team has not yet discussed Portal Network integrations.
ACD Process Improvements
Then, Beiko shared a few proposals for improving the network upgrade process on Ethereum. He first recommended reducing the frequency of discussing topics on ACD calls that client teams have not had the chance to review in detail. Instead of allowing time for presentations and discussions on code changes that developers do not have expertise on, Beiko recommended first flagging these topics on an ACD call for review and then afterwards bringing up the topic to discuss more thoroughly as needed on an ACD call thereafter.
The second proposal Beiko raised was about the Considered for Inclusion (CFI) status often attached to Ethereum Improvement Proposals (EIPs) that are considered for inclusion in a hard fork. The status has not historically been effective at indicating what EIPs are more likely to be included in a hard fork over others. Beiko suggested creating another label “Proposed for Inclusion” (PFI) to attach to EIPs so that developers can better organize between EIPs that have a higher likelihood of being included in a fork over others that do not.
EF Researcher Ansgar Dietrichs wrote in the Zoom chat that the creation of a new label for EIPs was “the wrong direction to take” and will only lead to the CFI label becoming “completely useless.” Beiko said that developers can continue to discuss this changes to the network upgrade process on GitHub and EthMagicians.
Also, EF DevOps Engineer Mario Vega said that he would like to create a new Discord sub-channel for sharing updates related to testing. At present, Vega said testing release information is scattered across several channels in the Ethereum R&D Discord. However, he hopes that this new forum will be effective at being the “one stop” shop for client team to reference for testing updates from the EF DevOps team. He asked that client teams chime in with their feedback on this proposal.
As a closing note, Beiko reminded developers that there are two breakout meetings scheduled over the next few days, one for ePBS on June 7 and the other for PeerDAS on June 11.
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.