Ethereum Developers Convene for ACDC Call #134
On May 30, 2024, Ethereum developers convened over Zoom for the All Core Developers Consensus (ACDC) call #134. These bi-weekly meetings, as noted by Galaxy Digital, provide a collaborative platform where developers discuss and coordinate modifications to Ethereum’s consensus layer (CL), commonly referred to as the Beacon Chain. The session was chaired by Ethereum Foundation (EF) researcher Alex Stokes, who guided discussions on various upgrades, including Pectra Devnet 0 and potential changes to the scope of the Pectra upgrade.
Devnet 0 Recap
The call commenced with a review of the Pectra launch on Devnet 0. Developers concurred on maintaining the attestation behavior affected by EIP 7549 unchanged during the hard fork activation. This decision stems from prior deliberations where multiple strategies were considered to avert invalid attestations during the fork. Eventually, the consensus was to avoid complicating the upgrade, opting to activate EIP 7549 in conjunction with other Pectra EIPs.
However, there remains uncertainty regarding EIP 7251 and the initiation of staked ETH consolidations from the execution layer (EL). This feature could significantly benefit staking pools by enabling stake consolidations through smart contracts, thereby reducing reliance on node operators. Alex Stokes suggested revisiting this issue after further progress in implementation.
Moreover, developers tackled unresolved questions about validator deposit finalization under EIP 6110. Teku developer Mikhail Kalinin had previously outlined a solution path in a GitHub comment before the call. The discussions also covered version control for the “GetPayloadBodies” request in the Engine API, a matter brought up 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 improve stability for generalized indexes. He recommended moving a new field to the end of a container to prevent index reassignment. This proposal faced no opposition. Stokes urged developers to review Kissling’s pull request on GitHub.
Another proposed modification to EIP 7549 involved structuring requests and other EL-triggered actions as a sidecar to EL blocks. Mikhail Kalinin praised this design, emphasizing its potential to simplify the EL. Stokes suggested revisiting this topic in the next Beacon Chain call after further reviewing the proposal on GitHub.
Pectra Scope Discussion
A significant portion of the call centered around the debate on whether to incorporate several Beacon Chain-focused EIPs, including EIP 7688 and PeerDAS, into the Pectra upgrade. EIP 7688 aims to ensure forward compatibility by integrating part of the “StableContainer” SSZ data structure. PeerDAS, an important improvement for the network’s data availability, could boost the number of blob transactions per block from three to 64 or more.
EF Developer Operations Engineer Barnabas Busa reported that an early version of PeerDAS had been launched on a devnet, which exposed various issues. Stokes questioned the feasibility of integrating PeerDAS into Pectra if it could delay the upgrade. The discussions also considered the possibility of splitting Pectra into two hard forks to include PeerDAS.
Differing views on separating PeerDAS from other Pectra EIPs were expressed by developers like “Nishant” and “atd”. Atd highlighted the logistical challenges of managing multiple upgrades within a short timeframe. In the end, developers decided to keep testing Pectra EIPs and PeerDAS together, with plans to activate PeerDAS in a later epoch on devnets and testnets.
As discussions on the inclusion of EIP 7688 were postponed to the next ACDC call, the meeting concluded with developers agreeing to proceed with the testing strategy for Pectra EIPs and PeerDAS.
For more such news, visit tech-news.in.
