Ethereum Developers Convene for ACDC Call #134
On May 30, 2024, Ethereum developers gathered over Zoom for the All Core Developers Consensus (ACDC) call #134. These bi-weekly meetings serve as a collaborative platform where developers discuss and coordinate changes to Ethereum’s consensus layer (CL), also known as the Beacon Chain, according to Galaxy Digital. This session was chaired by Ethereum Foundation (EF) Researcher Alex Stokes, who steered discussions on various upgrades, including the Pectra Devnet 0 and potential changes to the Pectra upgrade scope.
Devnet 0 Recap
Developers revisited the launch of Pectra on Devnet 0, agreeing to maintain attestation behavior impacted by EIP 7549 unchanged during hard fork activation. This decision follows previous discussions where developers considered multiple options to prevent invalid attestations during the fork. Ultimately, they decided against complicating the upgrade, opting instead to activate EIP 7549 concurrently with other Pectra EIPs.
Uncertainty remains regarding EIP 7251 and whether staked ETH consolidations should be initiated from the execution layer (EL). This feature could benefit staking pools by allowing stake consolidations via smart contracts rather than relying on node operators. Stokes suggested revisiting this issue after further implementation progress.
Additionally, developers addressed open questions about validator deposit finalization under EIP 6110. Teku developer Mikhail Kalinin outlined a path forward in a GitHub comment prior to the call. Discussions also included version control for the “GetPayloadBodies” request in the Engine API, which was raised by Lighthouse developer “sean.” Stokes encouraged feedback on this issue via a GitHub pull request.
EIP 7549 Changes
Nimbus developer Etan Kissling proposed a minor adjustment to EIP 7549 to enhance stability for generalized indexes. The suggestion to relocate a new field to the end of a container to avoid index reassignment received no opposition. Stokes advised developers to review Kissling’s pull request on GitHub.
Another proposed change to EIP 7549 involved designing requests and other EL-triggered actions as a sidecar to EL blocks. Mikhail Kalinin praised this design for simplifying the EL. Stokes recommended revisiting this topic in the next CL call after further review of the proposal on GitHub.
Pectra Scope Discussion
Developers debated whether to include several CL-focused EIPs, such as EIP 7688 and PeerDAS, in the Pectra upgrade. EIP 7688 aims to ensure forward compatibility by adopting part of the “StableContainer” SSZ data structure. PeerDAS, a significant enhancement for the network’s data availability, could increase the number of blob transactions per block from three to 64 or more.
EF Developer Operations Engineer Barnabas Busa reported that an early iteration of PeerDAS had been launched on a devnet, revealing various issues. Stokes questioned the feasibility of adding PeerDAS to Pectra if it risks delaying the upgrade. Discussions also considered splitting Pectra into two hard forks to accommodate PeerDAS.
Developers like “Nishant” and “atd” expressed differing views on decoupling PeerDAS from other Pectra EIPs. Atd emphasized the logistical challenges of coordinating multiple upgrades within a short period. Ultimately, developers agreed to further test Pectra EIPs and PeerDAS together, with PeerDAS activation on a later epoch on devnets and testnets.
As discussions on EIP 7688 inclusion were postponed to the next ACDC call, the call concluded with developers agreeing to move forward with this testing strategy.
Image source: Shutterstock
. . .
Tags
