Ethereum Developers Discuss Pectra Devnet 1 and Engine API Updates in Call #138

On July 25, 2024, Ethereum developers gathered via Zoom for the biweekly All Core Developers Consensus (ACDC) Call #138. Chaired by Ethereum Foundation (EF) Research Fellow Alex Stokes, the meeting focused on several important updates, including the launch of Pectra Devnet 1, proposed changes to the Beacon block body structure, and updates to the Engine API.

Pectra DevNet 1

Pectra Devnet 1 was released on July 23, but the network has faced stability issues. EF Developer Operations Engineer Parithosh Jayanthi reported that the Erigon client experienced issues shortly after the release, and the network split into three states due to the EIP 7702 transaction. The developers are currently debugging the client and resolving the chain split.

Introduction to “ExecutionPayloadEnvelope”

Prysm developer “Potuz” proposed a new structure for the execution payload within the Beacon block body, which he named “binded_execution_payload_envelope”. This change aims to simplify the storage of data required for state transitions by Consensus Layer (CL) clients. The proposal also requires corresponding changes to the Engine API, so that Execution Layer (EL) clients can efficiently access the information they need.

Lighthouse developer Mark Mackey supported the change to prevent performance degradation, while Teku developer Mikhail Kalinin expressed concern about the need for a protocol change. Stokes encouraged further discussion of the proposal on GitHub.

Engine API update for Devnet 2

Geth developer “Lightclient” proposed another Engine API change to simplify block conversions for EL clients. This proposal would consolidate all requests into a single type, allowing EL clients to interpret block versions without having to refer to the fork schedule. However, Nimbus developer “Dustin” argued that this would simply move complexity from EL to CL.

Pectra’s EIPs 7688 and 7495

Nimbus developer Etan Kissling has advocated for the introduction of EIPs 7688 and 7495 to ensure compatibility with future SSZ-related changes. Despite the liquid staking pool and support from other client teams, Stokes cautioned against overloading the Pectra upgrade with too many changes.

EF Developer Operations Engineer Jayanthi emphasized the difficulty of testing multiple EIPs together, suggesting a clear decision on whether to include them in an upgrade. Lighthouse developer Sean Anderson recommended advising app developers to evaluate the importance of these EIPs.

PeerDAS Update

The developers also discussed the PeerDAS update, focusing on fixing existing bugs before launching another devnet. Stokes suggested removing the sampling feature from the initial mainnet launch of PeerDAS to reduce complexity. This proposal was supported by some developers, but others suggested keeping the PeerDAS and Pectra workflows separate until both specifications are stable.

Added BeaconBlocksByRange V3

Lighthouse developer “Dapplion” proposed a change to the BeaconBlocksByRange RPC to help clients sync with the standard chain during extended chain splits. While not urgent, these changes could potentially be included in a Pectra upgrade.

Developers are encouraged to review and discuss proposals on GitHub.

For the full transcript of the call, visit the official summary on galaxy.com.

Image source: Shutterstock