skip to content

Ethereum All Core Developers Consensus Call #134 Writeup

Staking: Risks & Rewards - Galaxy Research

On May 30, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #134. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also called the Beacon Chain. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Developers discussed learnings and outstanding issues from the launch of Pectra Devnet 0. They also debated 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, client teams have agreed to keep attestation behavior impacted by EIP 7549 unchanged during hard fork activation. On a prior ACD call, developers had weighed multiple options to ensure that the impact of EIP 7549 during the fork does not lead to a large number of invalid attestations. Rather than pursue any of these options and complicate the upgrade further, client teams have decided on activating EIP 7549 on the same epoch as the other Pectra EIPs without changing attestation behavior before or after the fork.

On the topic of EIP 7251, developers remain uncertain about whether staked ETH consolidations should be triggerable from the execution layer (EL). This would be an ideal feature for staking pools like Lido so that consolidations of stake do not have to depend on node operators but rather can be triggered through smart contracts. Stokes recommended checking in on the progress of client implementations for validator stake consolidation in a few weeks and then determining whether they should be EL or CL operations.

Then, developers discussed open questions about validator deposit finalization under EIP 6110. Teku developer Mikhail Kalinin summarized the path forward for these issues in a GitHub comment prior to the call. Lighthouse developer “sean” raised a question about version control for the “GetPayloadBodies” request in the Engine API. Stokes recommended that developers chime in with their thoughts in the pull request created for this issue on GitHub.

EIP 7549 Changes

Nimbus developer Etan Kissling recommended a slight change to the implementation of EIP 7549. “It's about stability for generalized indexes. So, when we add a new field in the middle of a container, it means that the subsequent fields get assigned a new index, which breaks proofs based on EIP 4788 in the EL and it's also a bit misleading. … That's why I suggested to move the new field to the end to avoid both of these problems,” explained Kissling. There was no opposition to the change. Stokes recommended developers review Kissling’s proposed pull request on GitHub.

Another change to EIP 7549 that was raised on the call was to design the request and other EL triggered requests as a sidecar to EL blocks. About the change, Kalinin said, “In my opinion, it's a really quite nice design solution, which simplifies the EL … and this is basically an alternative to generalizing requests in the execution layer block.” Stokes recommended revisiting this topic on the next CL call once developers have had more time to review the proposal on GitHub.

Pectra Scope Discussion

There are a few CL-focused EIPs that have not been formally included or excluded from the Pectra upgrade. Developers weighed the addition of EIP 7688 and PeerDAS in Pectra on this week’s call. EIP 7688 adopts part of the “StableContainer” SSZ data structure to ensure that there is forward compatibility for the changes introduced by EIP 7549 to attestations. As background, SSZ is a data structure used in the CL that developers want to utilize in the EL. For more information about the SSZ transformation, read prior call notes. PeerDAS is the implementation of data availability sampling on Ethereum that is expected to greatly enhance the network’s ability to support rollups and their data availability needs. Practically speaking, PeerDAS is expected to increase the number of blob transactions validators can attach to a block from 3 blobs per block to 64 or more.

EF Developer Operations Engineer Barnabas Busa said that developers have already launched an early iteration of PeerDAS on a devnet. “I think lots of clients have discovered lots of issues and we could potentially re-launch [a new devnet] anytime when we have something substantial,” said Busa. Stokes asked whether developers were comfortable adding PeerDAS to Pectra even if this would mean the upgrade becomes delayed.

A developer with the screen name “Nishant” resurfaced the proposal of potentially decoupling PeerDAS activation from the activation of the other EIPs already included in Pectra. While this is possible, another developer with the screen name “atd” emphasized that users would have to upgrade their software for both upgrades at the same time anyways if developers plan on activating one upgrade after another within a short period of time. “I would say that having one fork two months after the other is kind of insane. If we're going to coordinate everybody upgrading their clients, we don't want to coordinate everybody upgrading the clients, again, two months down the line. That's like, not enough time to even you know, go through a release cycle,” said atd.

Atd added that in his view PeerDAS is the most “interesting” code change among the EIPs included and being discussed for inclusion in Pectra. Stokes said that in his view, he would want PeerDAS included in Pectra, even if it delays 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. Developers did not reach an agreement about the code change and will re-discuss the proposal on the next ACDC call.

On the topic of PeerDAS, developers continued to weigh the idea of splitting Pectra into two hard forks. EF Developer Options Engineer Parithosh Jayanthi warned that if developers split Pectra into two upgrades, they have to be careful about not overloading the second part of Pectra with more EIPs down the road. “One thing I do want to mention is that if we are thinking about splitting into two forks, we have to be really careful that we don't then just overload the next fork with new EIPs. I have no idea if we're ever going to be able to do that. If we can actually commit to something a year, year and a half in advance, because we're always coming up with new ideas, priorities change, and so on,” said Jayanthi.

Continuing to run with the idea of two upgrades, Lighthouse developer “sean” said that he did not foresee many interdependencies between PeerDAS and the current list of Pectra EIPs. Thus, the two could be worked on separately and easily merged later once developers are more confident about their implementations for both. Atd agreed with this sentiment saying that he did not foresee much risk in combining Pectra EIPs, PeerDAS, and EIP 7688 after more time for developing and testing each of these separately first.

Busa recommended then moving forward with testing Pectra EIPs and PeerDAS together but designing the code changes such that PeerDAS is activated on a later epoch on devnets and testnets than Pectra EIPs. He noted that this is already how testing for Pectra EIPs and PeerDAS is being conducted on Devnet 0. “Nothing really has to change,” said Busa, adding that if PeerDAS is not ready along with other Pectra EIPs, developers can then drop the code change from the upgrade. This prompted several questions about how a different activation epoch for PeerDAS would impact client teams’ work. Ultimately, developers agreed to try moving forward with building out PeerDAS, along with Pectra EIPs, with the caveat that PeerDAS will activate on devnets and testnets on a different epoch than other EIPs.

As mentioned earlier in this writeup, developers agreed to table the discussion on EIP 7688 inclusion in Pectra for the next ACDC call.