Bitget App
Trade smarter
Buy cryptoMarketsTradeFuturesCopyBotsEarn

Summary of the latest Ethereum core developer meeting: Pectra upgrade may be divided into two hard forks

BlockBeats2024/05/31 04:22
By:BlockBeats
Original title: 《 Ethereum All Core Developers Consensus Call #134 Writeup》
Original author: Christine Kim
Original translation: Lucy, BlockBeats

Editor's note:
The Ethereum All Core Developers Consensus Call (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum Consensus Layer (CL). This is the 134th ACDC call. At this meeting, developers discussed the implementation details and technical challenges of multiple key EIPs, including EIP 7549, EIP 7251, EIP 6110, EIP 7688, etc.

In addition, developers also discussed in depth the implementation of PeerDAS, a data availability sampling technology that is expected to significantly improve the Ethereum network's ability to support Rollups and its data availability requirements. The meeting proposed a proposal to split Pectra into two hard forks for upgrading, and discussed the activation time and interdependencies of different EIPs.

Christine Kim, vice president of research at Galaxy Digital, took a detailed note of the key points of the meeting, and BlockBeasts compiled the original text as follows:


On May 30, 2024, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #134. The ACDC call is a biweekly series of meetings hosted by Ethereum Foundation researcher Alex Stokes, where developers discuss and coordinate changes to the Ethereum consensus layer (CL, also known as the beacon chain). This week, developers discussed experiences and unresolved issues after the launch of Pectra Devnet 0. They also debated the feasibility of expanding the scope of the Pectra upgrade to include peerDAS and SSZ container code changes.


Devnet 0 Recap


Based on the launch of Pectra on Devnet 0, the client team has agreed to keep the validation behavior affected by EIP 7549 unchanged during the hard fork activation. In a previous ACDC meeting, developers considered various options to ensure that the impact of EIP 7549 does not lead to a large number of invalid validations during the fork. To avoid making the upgrade more complicated, the client team decided to activate EIP 7549 in the same epoch as other Pectra EIPs, and not change the validation behavior before and after the fork.


Regarding EIP 7251, developers are still unsure whether merging of staked ETH should be allowed to be triggered from the Execution Layer (EL). This would be a desirable feature for staking pools like Lido, so that merging of stakes would not have to rely on node operators, but could be implemented from smart contracts. Stokes suggested checking in on the progress of clients implementing validator stake merges in a few weeks before deciding whether they should be EL or CL operations.


Then, developers discussed some unanswered questions about finalization of validator deposits under EIP 6110. Teku developer Mikhail Kalinin summarized the directions for resolving these issues in a GitHub comment before the meeting. Lighthouse developer "sean" raised an issue regarding versioning of the "GetPayloadBodies" request in the Engine API. Stokes suggested that developers voice their opinions in the pull request created on GitHub for this issue.


EIP 7549 changes


Nimbus developer Etan Kissling suggested a small change to the implementation of EIP 7549. “This is a stability issue with generalized indexing. When we add a new field in the middle of a container, subsequent fields are assigned a new index, which breaks the proofs based on EIP 4788 in the execution layer (EL) and is somewhat misleading. … Therefore, I propose to move the new field to the end to avoid both problems,” Kissling explained. No one objected to this change. Stokes suggested developers check out Kissling’s proposed pull request on GitHub.


Another change to EIP 7549 proposed at the meeting would make requests and other requests triggered by EL as an add-on to EL blocks. Regarding this change, Kalinin said: “In my opinion, this is a very good design, it simplifies EL… and it’s basically an alternative to generalized requests in the execution layer block.” Stokes suggested revisiting this topic at the next CL meeting to give developers more time to review this proposal on GitHub .


Pectra Scope Discussion


There are a number of EIPs focused on the consensus layer (CL) that have not been formally included or excluded from the Pectra upgrade. At this week’s meeting, developers discussed whether to include EIP 7688 and PeerDAS in Pectra. EIP 7688 adopts a portion of the “StableContainer” SSZ data structure to ensure forward compatibility with EIP 7549’s changes to proofs. For background, SSZ is a data structure used in CL that developers want to use in the execution layer (EL). For more information on the SSZ transition, see previous meeting notes . PeerDAS is an implementation of data availability sampling on Ethereum that is expected to greatly enhance the network's ability to support rollups and their data availability requirements. In practice, PeerDAS is expected to increase the number of blob transactions that validators can attach to blocks from three per block to 64 or more.


Developers have already launched an early iteration of PeerDAS on a development network, according to Barnabas Busa, a developer operations engineer at the Ethereum Foundation. "I think a lot of clients have found a lot of problems, and when we have substantial progress, we can always restart a new development network," Busa said. Stokes asked developers if they would be willing to add PeerDAS to Pectra if it might cause upgrade delays.


A developer nicknamed "Nishant" revived the suggestion of separating the activation of PeerDAS from the activation of other EIPs in Pectra. While this is feasible, another developer nicknamed "atd" stressed that users would still need to upgrade their software at the same time if developers plan to activate these upgrades in sequence in a short period of time. “I think it’s a little crazy to fork two months after another upgrade,” said atd. “If we’re going to coordinate everyone to upgrade their clients, we don’t want to have everyone upgrade their clients two months later. That wouldn’t even be enough for one release cycle.”


atd added that in his opinion, PeerDAS is the most “interesting” code change among the EIPs included and discussed in Pectra. Stokes said he would like to see PeerDAS included in Pectra even if it causes a delay in the upgrade. Grandine client developer Saulius Grigaitis proposed removing EIP 7549 and EIP 7688 from Pectra in favor of PeerDAS. This sparked a discussion on the implementation details of EIP 7688. The developers were unable to agree on the code change and will revisit the proposal at the next ACDC meeting.


On the topic of PeerDAS, developers continue to weigh the idea of splitting Pectra into two hard forks. Parithosh Jayanthi, developer options engineer at the Ethereum Foundation, warned that if developers split Pectra into two upgrades, they must be careful not to add more EIPs to a future second part of Pectra. Jayanthi said, “One thing I would like to mention is that if we consider splitting into two forks, we have to be very careful not to include more new EIPs in the next fork. I don’t know if we will be able to do that. If we can commit to something a year or a year and a half ago, because we are always coming up with new ideas, priorities are changing, and so on.”


Continuing to discuss the idea of two upgrades, Lighthouse developer “sean” said that he does not foresee a lot of interdependencies between PeerDAS and the current list of Pectra EIPs. Therefore, the two can be developed separately and then easily merged later when developers are more confident in their implementation. Atd agreed with this view, believing that there would not be much risk in merging Pectra EIPs, PeerDAS, and EIP 7688 after these are developed and tested separately.


Busa suggested continuing to test Pectra EIPs and PeerDAS, but designing the code changes so that PeerDAS is activated one epoch later than Pectra EIPs on development and test networks. He noted that this was already the way Pectra EIPs and PeerDAS testing was done on Devnet 0. “Nothing really needed to change,” Busa said, adding that if PeerDAS wasn’t ready by the time the other Pectra EIPs were, developers could just drop that code change from the upgrade. This raised several questions about how the different activation epochs for PeerDAS would affect the work of client teams. Ultimately, the developers agreed to continue development of PeerDAS and the Pectra EIPs, but on the understanding that PeerDAS would be activated on different epochs on the development network and the test network.


As mentioned above, developers agreed to leave the discussion of whether EIP 7688 should be included in Pectra to the next ACDC call.


「 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.

PoolX: Stake to earn
APR up to 10%. Always on, always earning.
Stake now!