By Christine Kim
Compiled by: 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 conference call. At this meeting, developers discussed the implementation details and technical challenges of several 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 expected to significantly improve the Ethereum network’s ability to support rollups and their data availability requirements. The proposal to split Pectra into two hard forks for upgrades was made during the meeting, and issues of activation time and interdependencies of different EIPs were discussed.
Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points of the meeting. 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 bi-weekly 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 Review
Following 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 the merge of staked ETH should be allowed to be triggered from the Execution Layer (EL). This would be an ideal feature for staking pools like Lido, so that the merge of stakes does not have to rely on node operators, but can be implemented through smart contracts. Stokes suggested checking the progress of the client's implementation of validator stake merges in a few weeks, and then determine whether they should be EL operations or CL operations.
The developers then discussed some unanswered questions about finalization of validator deposits under EIP 6110. Teku developer Mikhail Kalinin summarized the direction of resolving these issues in a GitHub comment before the meeting. Lighthouse developer "sean" raised an issue about versioning of the "GetPayloadBodies" request in the Engine API. Stokes suggested that developers express 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 about the stability of generalized indexes. 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 at 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 that developers check out the pull request proposed by Kissling on GitHub.
Another change to EIP 7549 proposed at the meeting is to design requests and other requests triggered by EL as additional programs to EL blocks. Regarding this change, Kalinin said: "In my opinion, this is a very good design, it simplifies EL... and it is basically an alternative to generalized requests in the execution layer block." Stokes suggested that this topic be discussed again at the next CL meeting to give developers more time to review the proposal on GitHub.
Pectra scope discussion
There are a few EIPs focused on the consensus layer (CL) that have not been formally included or excluded from the Pectra upgrade. At the meeting this week, developers discussed whether to include EIP 7688 and PeerDAS in Pectra. EIP 7688 adopts part of the "StableContainer" SSZ data structure to ensure forward compatibility with EIP 7549's changes to proofs. As a background, SSZ is a data structure used in CL that developers hope to use in the execution layer (EL). For more information on the SSZ transition, see the 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 3 per block to 64 or more.
Barnabas Busa, developer operations engineer at the Ethereum Foundation, said developers have already launched an early iteration of PeerDAS on a development network. "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 proposal to separate the activation of PeerDAS from the activation of other EIPs in Pectra. While this is feasible, another developer nicknamed “atd” stressed that if developers plan to activate these upgrades in sequence in a short period of time, users will still need to upgrade their software at the same time. “I think it’s a little crazy to fork two months after another upgrade,” atd said. “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 way, it won’t even be enough for a 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 include PeerDAS in Pectra even if it causes upgrade delays. 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 changes 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 Pectra part two. "One thing I would like to mention is that if we consider splitting into two forks, we have to be very careful not to put more new EIPs in the next fork," Jayanthi said. "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 and 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 implementations. Atd agreed with this point of view, believing that there would not be much risk in merging Pectra EIPs, PeerDAS, and EIP 7688 after developing and testing these separately.
Busa suggested continuing to test the Pectra EIP and PeerDAS, but designing the code changes so that PeerDAS would be activated one epoch later than the Pectra EIP on the development and test networks. He pointed out that this was already how the Pectra EIP and PeerDAS testing was done on Devnet 0. "There's really nothing that needs to change," Busa said, adding that if PeerDAS isn't ready when the other Pectra EIPs are ready, developers can remove 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 developing PeerDAS and the Pectra EIP, but on the understanding that PeerDAS would be activated at different epochs on the development and test networks.
As mentioned above, the developers agreed to leave the discussion of whether EIP 7688 should be included in Pectra to the next ACDC call.