Bitget App
Trade smarter
Buy cryptoMarketsTradeFuturesCopyBotsEarn

Summary of the latest Ethereum core developer meeting: Adding EOF and EIP-7702 to the Pectra upgrade

BlockBeats2024/06/07 05:37
By:BlockBeats
Original title: 《 Ethereum All Core Developers Execution Call #189 Writeup》
Original author: Christine Kim
Original translation: Lucy, BlockBeats

Editor's note:
The Ethereum All Core Developers Execution Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 189th ACDE call. At this meeting, developers discussed some important topics in the Pectra upgrade, including changes including EOF and EIP 7702, improving Pectra scope, and preparing for Verkle transition.

The meeting also discussed how to package EOF and other Pectra EIPs, and how to test these code changes. In addition, some proposals were introduced to improve the Ethereum network upgrade process, including adjustments to the frequency of ACD call discussion topics, and new EIP tag proposals. The integration progress of EIP 4444 and Portal Network was also mentioned.

Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points of the meeting, and BlockBeasts compiled the original text 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 biweekly series of meetings hosted by Tim Beiko, head of protocol support at the Ethereum Foundation, 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 on a different activation cycle than other EIPs, just as developers plan to test PeerDAS . They also discussed how to deactivate EIP 158 in the Osaka upgrade to prepare for Verkle, and the next steps for implementing EIP 4444 through integration with the Portal Network. Finally, Beiko and the EF Developer Operations (DevOps) team shared the latest updates on the governance process and communication channels for planning Ethereum upgrades.


The Scope of Pectra


Ahead of this week’s ACD meeting, various EL client teams and the EF DevOps team shared their thoughts on the scope of Pectra.


· Besu perspective

· EthJS perspective

· Nethermind perspective

· Reth perspective

· EthPandaOps Perspectives


Based on the opinions shared before the meeting, it is clear that most client teams support the inclusion of EOF in Pectra. The only client team that strongly opposed EOF was Geth. "I am worried that the longer we wait, the longer it will take for the Verkle conversion. Is EOF really that urgent? I don't think so. I read several arguments for releasing EOF in Prague. The more I read, the more I realized that there is nothing that really proves that EOF is necessary." Several developers raised objections to this.


A developer named "Kamil Sliwak" said that from the perspective of users interacting with the compiler of Ethereum's smart contract programming language Solidity, EOF will be "a huge improvement." Reth developer Dragan Rakita added that it would be disingenuous to think that EOF would significantly delay the Verkle transition. “We’re talking about a 10% to 20% increase in transition time. EOF doesn’t add state, an extra three months to release an additional partial fork, and it won’t significantly delay Verkle,” Rakita said. For more 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 the rest of Pectra’s EIPs, or split Pectra’s EIPs into two hard forks. Erigon developer Andrew Ashikhmin said he thinks developers should try to release all of Pectra’s EIPs together, or delay EOF until after the Verkle transition. “The last thing I want is to have a fork between Pectra and Verkle to release EOF. Because I agree with Guillaume that the state is growing, and I think Verkle is more important than EOF. So that’s the worst outcome in my opinion,” Ashikhmin said. Beiko suggested releasing all of Pectra’s EIPs, including EOF, in one client version. However, for testing purposes, he said developers should consider using the development network to phase in these code changes. “Use the development network as a way for us to prioritize in terms of multi-client testing, and then if we see that EOF is delaying things for a long time, we can decide to split it out,” Beiko said.


During these discussions on how to include EOF in Pectra, Geth developers in the Zoom chat and throughout the meeting continued to voice doubts about whether EOF should be included in the upgrade. In response to the Geth team's continued debate on EOF, Reth developer George Konstantinopoulos said: "Let's just do it. It's a little confusing where the conversation is going. We don't mind extending the Verkle transition by a few days. The data shows that the status is declining, so it's a confusing argument, and you have a bunch of applications telling you that this is a good feature. It's confusing why we would even consider not doing it when the majority of people are in favor of it."


Beiko agreed with this point and reiterated that EOF should be included in Pectra, but in a phased test on development networks, which means that client teams should test EIPs that have been implemented on Devnet 0 on Devnet 1. Then, on future development networks, EOF should be added for testing. This strategy will ensure that client teams focus on releasing a portion of Pectra's EIPs on the same timeline and can continue to make progress on a multi-client development network. Ethereum Foundation (EF) DevOps engineer Mario Vega said he expects to have EOF's execution layer (EL) specification tests ready within two months. EF DevOps engineer Parithosh Jayanthi said EOF can be tested separately from other execution layer (EL) EIPs in Pectra. However, he is concerned about the interdependencies between consensus layer (CL) EIPs in Pectra and the complexity of testing these code changes.


Vyper compiler developer Charles Cooper said that in his view, EOF is not as urgent as the code changes he proposed, which are intended to make protection against reentrancy attacks cheap and ubiquitous. Beiko reminded Cooper that while the broad consensus on EOF is clear, it is unclear whether client teams have enough energy to add more code changes, such as those related to reentrancy attacks. "I think it is clear that if we move 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 EIP 7702 as an alternative to EIP 3074. Developers are still discussing the specification of EIP 7702 in a separate group meeting . Beiko suggested taking a similar approach to EIP 7702 as EOF. "I would include it in the fork, but if we're not too happy with the spec, don't include it as part of Devnet 1 or 2, and then spend the next month to really sort out the spec so that we have a better revocation mechanism than what's being proposed now. Add a not-too-big EIP later in the process," Beiko said. Geth developer "Lightclient" said that if client teams are ready, they should implement EIP 7702 as soon as possible. There is no objection to including EIP 7702 in the next urgent Pectra development network Devnet 1.


Pectra Specification


Teku developer Mikhail Kalinin then shared some updates to the existing Pectra EIP specification. The first is a proposal to handle triggering consensus layer (CL) requests through a sidecar mechanism, rather than directly in the execution layer (EL) block. Prysm developer "Potuz" pointed out that this strategy would break the logic required for future code changes, namely the clear proposer builder separation (ePBS). "The beacon block should not rely on the payload already existing. So, whether it is a withdrawal or a deposit, you don't want the beacon block to depend on what is in the payload because this will break the ePBS process," Potuz said. Due to this issue, Kalinin agreed to withdraw his suggestion and close the pull request on GitHub.


Kalinin shared several other changes to Pectra’s EL and Engine API specs, one of which is enabling EL triggered merges under EIP 7251, increasing MAX_EFFECTIVE_Balance. Beiko suggested that developers review these changes before the next ACD call so that they can be completed and ready before testing in Devnet 1.


Verkle preparations


Based on his work on 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 suggested deactivating EIP 158 in the Pectra upgrade. However, he noted that if the implementation of EIP 7702 is fine-tuned in Pectra, then the decommissioning of EIP 158 could be delayed and occur in parallel with the Verkle transition. Beiko suggested that Guillaume start drafting his proposal to decommission EIP 158.


History Expiration


In addition to Pectra and Verkle, Ethereum protocol developers are also working on EIP 4444, History Expiration. As stated in the EIP 4444 plan and summary document, the reason for this code change is that “block history takes up a large amount of space on nodes, and once a block has been finalized it only needs to be used for limited non-consensus critical use cases.” The document continues, “Block history will no longer be stored permanently by full nodes. After a period of time it will be removed from nodes, and entities that need it will need to query it from elsewhere.” Portal Network is an alternative, decentralized network for nodes to query Ethereum historical data.


Merriam reiterated that his team is willing to provide integration support for EL client teams with Portal Network. He said that without any support, the integration would take about 6 months to develop. However, with guidance and close collaboration, he is optimistic that meaningful progress can be made on EIP 4444 in the next two months. Jayanthi asked if there had been a security audit of the Portal Network specification. Merriam said no. Ethereum Foundation researcher Ansgar Dietrichs asked if client teams could decide for themselves how to interface with the network, including bundling the integration with an existing client, building a new client, or simply not doing any integration. Merriam confirmed that this decision is at the discretion of the client team.


Merriam asked the EL client team on the call about their progress and intentions on EIP 4444. Nethermind developer Łukasz Rozmej said: "Overall it is a priority. We even had a meeting with the Portal team yesterday. The problem is that there are too many priorities. Sometimes it is difficult to balance everything correctly. So it is a less urgent priority compared to, for example, a hard fork, but Nethermind will work on it and we will prioritize it." Besu developer Matt Nelson said he felt the same way. Geth developer Guillaume Ballet said his team has not discussed Portal Network integration yet.


ACD Process Improvements


ACD Process Improvements Beiko then shared several suggestions for improving the Ethereum network upgrade process. He first suggested reducing the frequency of discussing topics on ACD calls that have not been reviewed in detail by client teams. Beiko suggested that these topics be tagged for review on the ACD call before developers are allowed to engage in professional discussion, and then discussed in more detail on subsequent ACD calls as needed.


The second suggestion Beiko made concerns the "Considering for Inclusion" (CFI) status that is typically attached to Ethereum Improvement Proposals (EIPs) that are being considered for inclusion in a hard fork. This status has historically not been an effective indicator of which EIPs are more likely to be included in a hard fork. Beiko suggested creating another label, "Proposed for Inclusion" (PFI), so that developers can better distinguish which EIPs are more likely to be included in a hard fork and which will not.


Ethereum Foundation researcher Ansgar Dietrichs wrote in a Zoom chat that creating a new label for EIPs is "the wrong direction" and will only cause the CFI label to become "completely useless." Beiko said developers can continue to discuss improving the network upgrade process on GitHub and EthMagicians.


In addition, Mario Vega, a DevOps engineer at the Ethereum Foundation, said he hopes to create a new Discord subchannel for testing-related updates. Vega said that currently in the Ethereum RD Discord, test release information is scattered across multiple channels. However, he hopes that this new forum can become a "one-stop" reference for client teams to get test updates from the Ethereum Foundation DevOps team. He asked for feedback from client teams on this.


Finally, Beiko reminded developers that two group meetings were scheduled in the next few days, one on ePBS, which will be held on June 7, and the other on PeerDAS, which will be held on June 11.


「 Original link 」


欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群: https://t.me/theblockbeats

Telegram 交流群: https://t.me/BlockBeats_App

Twitter 官方账号: https://twitter.com/BlockBeatsAsia

0

Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.

You may also like

Web3 social aggregator Yup completes new round of financing, with Nascent and others participating

Cointime2024/07/25 04:31

Mellow Protocol has joined the Zircuit ecosystem

Cointime2024/07/25 04:31

Web3 social aggregator Yup completes new round of financing, Farcaster co-founder Dan Romero and others participate in the investment

Odaily2024/07/25 04:26

The Information: OpenAI may lose $5 billion this year and run out of cash within 12 months

Odaily2024/07/25 04:26

‌Spot copy trading

More
AIOnline
AIOnline
insight1000/1000
10353.21%
ROI
Total profit $52801.35
HappyPlanets
HappyPlanets
insight500/500
15747.81%
ROI
Total profit $31495.6

Bot copy trading

More
GoldenEgg
GoldenEgg
insight148/150
$2886.58
Total profit
Total subscriber profits $-285.11
BGUSER-FFF8CNJ4
BGUSER-FFF8CNJ4
insight8/150
$1281.7
Total profit
Total subscriber profits $97.94