Summary of the latest meeting of Ethereum core developers: Adding EOF and EIP-7702 in the Pectra upgrade
During this meeting, the developers discussed several important topics regarding the Pectra upgrade, including changes involving EOF and EIP 7702, improvements to the scope of Pectra, and preparations for the Verkle transition.Original Title: 《Ethereum All Core Developers Execution Call #189 Writeup》
Author: Christine Kim
Compiled by: Luccy, BlockBeats
Editor’s Note:
The Ethereum All Core Developers Execution (ACDE) call is held every two weeks, primarily to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 189th ACDE call, during which developers discussed several important topics related to the Pectra upgrade, including changes involving EOF and EIP 7702, the scope of Pectra improvements, and preparations for the Verkle transition.
The meeting also covered how to bundle EOF and other Pectra EIPs, as well as how to test these code changes. Additionally, some proposals were introduced to improve the Ethereum network upgrade process, including adjustments to the frequency of discussions on ACD call topics and a new EIP tagging proposal. Progress on the integration of EIP 4444 and the Portal Network was also mentioned.
Christine Kim, Vice President of Research at Galaxy Digital, took detailed notes on the key points of the meeting, which BlockBeats has compiled as follows:
On June 6, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #189. The ACDE call is a bi-weekly series hosted by Tim Beiko, the Ethereum Foundation's Protocol Support Lead, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers agreed to include EOF and EIP 7702 in the Pectra upgrade. To avoid delays in multi-client testing upgrades due to these code changes, developers agreed to activate EOF on a later development network and possibly activate it on a different cycle than other EIPs, similar to the developers' plan to test PeerDAS. They also discussed how to disable EIP 158 in the Osaka upgrade to prepare for Verkle and implement the next steps for EIP 4444 through integration with the Portal Network. Finally, Beiko and the EF DevOps team shared updates on governance processes and communication channels for planning Ethereum upgrades.
Scope of Pectra
Before this week's ACD meeting, various EL client teams and the EF DevOps team shared their views on the scope of Pectra.
Based on the views shared before the meeting, it is clear that the majority of client teams support including EOF in Pectra. The only client team that strongly opposes EOF is Geth. Geth developer Guillaume Ballet said, "I worry that the longer we wait, the longer the Verkle transition will take. Is EOF really that urgent? I don't think so. I've read several arguments about releasing EOF in Prague. The more I read, the more I realize that nothing really proves EOF is necessary." Several developers disagreed with this.
A developer named "Kamil Sliwak" stated that from the user's perspective interacting with the Ethereum smart contract programming language Solidity, EOF would be "a huge improvement." Reth developer Dragan Rakita added that it is dishonest to think EOF would significantly delay the Verkle transition. "We're talking about a 10% to 20% increase in conversion time. EOF won't increase state; an additional three months to release extra parts of the fork won't significantly delay Verkle," Rakita said. For more information on what EOF is and how it will improve the Ethereum Virtual Machine (EVM), listen to this episode of the Infinite Jungle podcast.
Beiko asked developers whether they would prefer to bundle EOF with other Pectra EIPs or split the Pectra EIPs into two hard forks. Erigon developer Andrew Ashikhmin expressed that he believes developers should try to release all Pectra EIPs together or delay EOF until after the Verkle transition. "What I least want is to fork between Pectra and Verkle to release EOF. Because I agree with Guillaume that state is growing, and I think Verkle is more important than EOF. So from my perspective, that's the worst outcome," Ashikhmin said. Beiko suggested releasing all Pectra EIPs, including EOF, in one client version. However, for testing purposes, he stated that developers should consider using the development network to implement these code changes in stages. "Using the development network as our priority in multi-client testing, and then if we see EOF will significantly delay things, we can decide to separate it," Beiko said.
During these discussions on how to incorporate EOF into Pectra, Geth developers continued to express doubts in the Zoom chat and throughout the meeting about whether EOF should be included in the upgrade. To address the ongoing arguments from the Geth team regarding EOF, Reth developer George Konstantinopoulos said, "Let's just do it. The direction of the conversation is a bit confusing. We don't mind extending the Verkle transition by a few days. The data shows that state is declining, so this is a confusing argument, and you have a bunch of applications telling you this is a good feature. Since most people have expressed support, why are we still considering not doing it? It's quite confusing."
Beiko agreed with this viewpoint and reiterated that EOF should be included in Pectra but tested in stages on the development network, meaning client teams should test EIPs that have already been implemented on Devnet 0 on Devnet 1. Then, add EOF for testing on future development networks. This strategy will ensure that client teams focus on releasing part of the Pectra EIPs on the same timeline and can continue to make progress on the multi-client development network. Ethereum Foundation (EF) DevOps engineer Mario Vega stated that he expects to have the EOF Execution Layer (EL) specification testing ready within two months. EF DevOps engineer Parithosh Jayanthi mentioned that EOF could be tested separately from other Execution Layer (EL) EIPs in Pectra. However, he expressed concerns about the interdependencies between the Consensus Layer (CL) EIPs in Pectra and the complexity of testing these code changes.
Vyper compiler developer Charles Cooper stated that, in his view, EOF is not as urgent as the code changes he proposed, which aim to make protections against reentrancy attacks cheap and widespread. Beiko reminded Cooper that while there is broad consensus on EOF, it is unclear whether client teams have enough bandwidth to add more code changes, such as those related to reentrancy attacks. "I think it's clear that if we push forward with EOF, there will be almost no energy left to do anything else. This will already be the largest fork to date," Beiko said.
In addition to including EOF, developers also agreed to adopt EIP 7702 as an alternative to EIP 3074. Developers are still discussing the specifications of EIP 7702 in separate breakout meetings. Beiko suggested adopting a similar approach for EIP 7702 as for EOF. "I would include it in the fork, but if we're not satisfied with the specification, we won't include it as part of Devnet 1 or 2, and then spend the next month really clarifying the specification so that we have a better rollback mechanism than what is currently proposed. We can add a not-too-large EIP later in the process," Beiko said. Geth developer "Lightclient" stated that if the client teams are ready, they should implement EIP 7702 as soon as possible. No one opposed including EIP 7702 in the next urgent Pectra development network, Devnet 1.
Pectra Specifications
Subsequently, Teku developer Mikhail Kalinin shared some updates on the existing Pectra EIP specifications. The first is a proposal to handle consensus layer (CL) requests through a sidecar mechanism instead of directly handling them in Execution Layer (EL) blocks. Prysm developer "Potuz" pointed out that this strategy would undermine the logic required for future code changes, namely the explicit proposer-builder separation (ePBS). "Beacon blocks should not depend on the payload already existing. So whether it's withdrawals or deposits, you don't want beacon blocks to depend on the contents of the payload because that would undermine the ePBS process," Potuz said. Due to this issue, Kalinin agreed to withdraw his proposal and close the pull request on GitHub.
Kalinin shared several other changes regarding the EL and engine API specifications for Pectra, one of which is to enable EL-triggered merges under EIP 7251, increasing MAXEFFECTIVEBalance. Beiko suggested that developers review these changes before the next ACD call so that they can be completed and ready for testing on Devnet 1.
Verkle Preparation
Based on his work for the Verkle transition, Ballet stated that EIP 158 would lead to issues similar to the deprecated opcode SELFDESTRUCT. To avoid complications on the network after the transition, Ballet proposed disabling EIP 158 in the Pectra upgrade. However, he noted that if the implementation of EIP 7702 in Pectra is fine-tuned, the disabling of EIP 158 might be delayed and occur simultaneously with the Verkle transition. Beiko suggested that Guillaume begin drafting his proposal to disable EIP 158.
Historical Expiration
In addition to Pectra and Verkle, Ethereum protocol developers are also working on EIP 4444, historical expiration. As stated in the EIP 4444 plan and summary document, the reason for making this code change is that "block history occupies a significant amount of space on nodes, and once that block has been finalized, it is only needed for a limited number of non-consensus-critical use cases." The document continues to explain, "Block history will no longer be permanently stored by full nodes. After a period, it will be removed from the nodes, and entities that need it will have to query it from elsewhere." The Portal Network is an alternative, decentralized network for querying Ethereum historical data.
Merriam reiterated that his team is willing to provide integration support with the Portal Network for EL client teams. He said that without any support, integration would take about six months to complete. However, with guidance and close collaboration, he is optimistic that meaningful progress can be made on EIP 4444 within the next two months. Jayanthi asked whether a security audit had been conducted on the Portal Network specifications. Merriam stated that it had not. Ethereum Foundation researcher Ansgar Dietrichs asked client teams whether they could decide how to interface with the network, including bundling the integration with existing clients, building new clients, or simply not integrating at all. Merriam confirmed that this decision is up to the client teams.
Merriam inquired about the progress and intentions of the EL client teams regarding EIP 4444 during the call. Nethermind developer Ł ukasz Rozmej stated, "Overall, this is a priority. We even had a meeting with the Portal team yesterday. The issue is that there are too many priorities. Sometimes it's hard to balance everything correctly. So, compared to, for example, hard forks, it's a less urgent priority, but Nethermind will tackle it, and we will prioritize it." Besu developer Matt Nelson expressed that his view is the same. Geth developer Guillaume Ballet stated that his team has not yet discussed the integration of the Portal Network.
ACD Process Improvements
Following the ACD process improvements, Beiko shared several suggestions to improve the Ethereum network upgrade process. He first suggested reducing the frequency of discussing topics on the ACD call that client teams have not yet reviewed in detail. Beiko proposed that these topics be flagged for review on the ACD call before allowing developers to have professional discussions, and then discuss these topics in more detail in subsequent ACD calls as needed.
Beiko's second suggestion involved the "Consider for Inclusion" (CFI) status that is typically attached to Ethereum Improvement Proposals (EIPs) considered for inclusion in hard forks. This status has historically not effectively indicated which EIPs are more likely to be included in hard forks. Beiko suggested creating another label, "Proposed for Inclusion" (PFI), so that developers can better distinguish which EIPs are more likely to be included in hard forks and which are not.
Ethereum Foundation researcher Ansgar Dietrichs wrote in the Zoom chat that creating a new label for EIPs is "the wrong direction" and would only render the CFI label "completely useless." Beiko stated that developers can continue to discuss issues related to improving the network upgrade process on GitHub and EthMagicians.
Additionally, EF DevOps engineer Mario Vega expressed his desire to create a new Discord sub-channel for testing-related updates. Vega stated that currently, testing release information is scattered across multiple channels in the Ethereum R&D Discord. However, he hopes this new forum can serve as a "one-stop" reference for client teams to obtain testing updates from the Ethereum Foundation DevOps team. He requested feedback from client teams on this.
Finally, Beiko reminded developers that two breakout meetings are scheduled in the coming days, one on ePBS, to be held on June 7, and another on PeerDAS, to be held on June 11.
