Summary of the latest meeting of Ethereum core developers: The Pectra upgrade may be split into two hard forks

Author: Christine Kim

Compiled by: Luccy, BlockBeats

Editor’s Note: The All Core Developers Consensus (ACDC) call for Ethereum's core developers is held biweekly, primarily to discuss and coordinate changes to the Ethereum consensus layer (CL). This is the 134th ACDC call, during which developers explored the implementation details and technical challenges of several key EIPs, including EIP 7549, EIP 7251, EIP 6110, EIP 7688, and others.

Additionally, developers delved into the implementation of PeerDAS, a data availability sampling technique expected to significantly enhance the Ethereum network's ability to support Rollups and their data availability needs. The meeting proposed splitting Pectra into two hard forks for upgrades and discussed the activation timing and interdependencies of different EIPs.

Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of this meeting in detail, and BlockBeats 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 series of meetings held every two weeks, 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 following 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 Review

Based on the launch of Pectra on Devnet 0, the client teams agreed to maintain the verification 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 during the fork would not lead to a significant number of invalid verifications. To avoid complicating the upgrade further, the client teams decided to activate EIP 7549 in the same epoch as other Pectra EIPs, without changing the verification behavior before and after the fork.

Regarding EIP 7251, developers remained uncertain whether to allow triggering the staking of ETH from the execution layer (EL). This would be an ideal feature for staking pools like Lido, allowing staking merges to be executed via smart contracts rather than relying on node operators. Stokes suggested checking the progress of client implementations for validator staking merges in a few weeks before determining whether they should be EL operations or CL operations.

The developers then discussed some unresolved issues regarding the final confirmation of validator deposits under EIP 6110. Teku developer Mikhail Kalinin summarized the direction for resolving these issues in a GitHub comment prior to the meeting. Lighthouse developer "sean" raised a version control issue regarding the "GetPayloadBodies" request in the Engine API. Stokes suggested that developers express their opinions on the pull request created for this issue on GitHub.

EIP 7549 Changes

Nimbus developer Etan Kissling proposed a minor modification to the implementation of EIP 7549. "This is about the stability issue of generalized indices. When we add a new field in the middle of a container, subsequent fields are assigned a new index, which breaks the proof based on EIP 4788 in the execution layer (EL) and can be somewhat misleading. … Therefore, I suggest moving the new field to the end to avoid these two issues," Kissling explained. No objections were raised to this change. Stokes suggested that developers check the pull request proposed by Kissling on GitHub.

Another change to EIP 7549 was proposed during the meeting, designing requests and other EL-triggered requests as additional programs of EL blocks. Regarding this change, Kalinin stated, "In my opinion, this is a very nice design that simplifies the EL… and it is basically an alternative to generalized requests in execution layer blocks." Stokes suggested revisiting this topic in the next CL meeting to give developers more time to review this proposal on GitHub.

Pectra Scope Discussion

There are several EIPs focused on the consensus layer (CL) that have not yet been formally included or excluded from the Pectra upgrade. In this week's meeting, developers discussed whether to include EIP 7688 and PeerDAS in Pectra. EIP 7688 adopts part of the "StableContainer" SSZ data structure to ensure that changes to proofs under EIP 7549 are forward-compatible. As background, SSZ is a data structure used in the CL that developers hope to use in the execution layer (EL) as well. For more information on the SSZ transition, please refer to previous meeting notes. PeerDAS is the implementation of data availability sampling on Ethereum, expected to greatly enhance the network's ability to support rollups and their data availability needs. In practice, PeerDAS is expected to increase the number of blob transactions that validators can attach to blocks from 3 per block to 64 or more.

Ethereum Foundation developer operations engineer Barnabas Busa stated that developers have launched an early iteration of PeerDAS on a development network. "I think many clients have found a lot of issues, and we can always restart a new development network when we have substantial progress," Busa said. Stokes asked developers if they would be willing to add PeerDAS to Pectra, even if it might lead to upgrade delays.

A developer nicknamed "Nishant" reiterated the suggestion to separate the activation of PeerDAS from the activation of other EIPs in Pectra. While this is feasible, another developer nicknamed "atd" emphasized that if developers plan to activate these upgrades sequentially in a short time, users would still need to upgrade their software simultaneously. Atd said, "I think it’s a bit crazy to fork two months after another upgrade. If we are going to coordinate everyone to upgrade their clients, we don’t want to make everyone upgrade their clients again two months later. In that case, even one release cycle wouldn’t be enough."

Atd added that, in his view, PeerDAS is the most "interesting" code change among the EIPs included and discussed in Pectra. Stokes expressed his desire to include PeerDAS in Pectra, even if it leads to upgrade delays. Grandine client developer Saulius Grigaitis proposed removing EIP 7549 and EIP 7688 from Pectra to support PeerDAS. This sparked a discussion about the implementation details of EIP 7688. Developers failed to reach a consensus on the code changes and will revisit this proposal in the next ACDC meeting.

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

Continuing the discussion about the two upgrades, Lighthouse developer "sean" mentioned that he did not foresee many interdependencies between PeerDAS and the current list of Pectra EIPs. Therefore, they could proceed separately and later merge them smoothly when developers are more confident in their implementations. Atd agreed, believing that merging Pectra EIPs, PeerDAS, and EIP 7688 after developing and testing them separately would not pose significant risks.

Busa suggested continuing to test Pectra EIPs and PeerDAS but designing the code changes so that PeerDAS activates one epoch later than Pectra EIPs on the development and testing networks. He noted that this was already the approach taken for testing Pectra EIPs and PeerDAS on Devnet 0. Busa said, "There’s really nothing that needs to change," adding that if PeerDAS is not ready when other Pectra EIPs are, developers can remove that code change from the upgrade. This raised several questions about how different activation epochs for PeerDAS would affect the work of client teams. Ultimately, developers agreed to continue developing PeerDAS and Pectra EIPs, provided that PeerDAS would activate in different epochs on the development and testing networks.

As mentioned earlier, developers agreed to postpone the discussion on whether to include EIP 7688 in Pectra until the next ACDC call.