Ethereum Developers Discuss Pectra Devnet 1 and Engine API Updates in Call #138
Peter Zhang Jul 26, 2024 07:39
Ethereum developers gathered for the All Core Developers Consensus Call #138 to discuss Pectra Devnet 1, Engine API updates, and other important changes.
On July 25, 2024, Ethereum developers convened over Zoom for the bi-weekly All Core Developers Consensus (ACDC) call #138. Chaired by Ethereum Foundation (EF) Researcher Alex Stokes, the meeting focused on several significant 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 went live on July 23, but the network has faced stability issues. EF Developer Operations Engineer Parithosh Jayanthi reported that the Erigon client encountered problems shortly after the launch, and an EIP 7702 transaction caused the network to split into three states. Developers are currently debugging the clients and resolving the chain split.
Introducing an “ExecutionPayloadEnvelope”
Prysm developer “Potuz” proposed a new structure for the execution payload within the Beacon block body, termed the “binded_execution_payload_envelope.” This change aims to simplify the data storage needed for state transitions by consensus layer (CL) clients. The proposal also necessitates corresponding changes to the Engine API to allow execution layer (EL) clients to access the required information efficiently.
While Lighthouse developer Mark Mackey supported the change to prevent performance degradation, Teku developer Mikhail Kalinin expressed reservations about the necessity of protocol changes. Stokes encouraged further discussion on the proposal on GitHub.
Engine API Update for Devnet 2
Geth developer “Lightclient” suggested another Engine API change to streamline block conversion for EL clients. This proposal seeks to unify all requests into a single type, helping EL clients interpret block versions without referencing a fork schedule. However, Nimbus developer “Dustin” argued that this would merely shift complexity from the EL to the CL.
EIP 7688 & 7495 in Pectra
Nimbus developer Etan Kissling has been advocating for the introduction of EIPs 7688 and 7495 to ensure forward compatibility with future SSZ-related changes. Despite support from liquid staking pools and other client teams, Stokes cautioned against overloading the Pectra upgrade with too many changes.
EF Developer Operations Engineer Jayanthi highlighted the difficulty of testing multiple EIPs together, suggesting a clear decision on their inclusion in the upgrade. Lighthouse developer Sean Anderson recommended consulting app developers to assess the criticality of these EIPs.
PeerDAS Updates
Developers also discussed PeerDAS updates, with a focus on fixing existing bugs before launching another devnet. Stokes proposed removing the sampling function from PeerDAS's initial mainnet activation to reduce complexity. This proposal received support from some developers, but others suggested keeping PeerDAS and Pectra workflows separate until both specifications stabilize.
Add BeaconBlocksByRange V3
Lighthouse developer “Dapplion” proposed changes to the BeaconBlocksByRange RPC to assist clients in syncing to the canonical chain during extended chain splits. Though not urgent, these changes could potentially be included in the Pectra upgrade.
Developers are encouraged to review and discuss the proposal on GitHub.
For the complete details of the call, visit the official summary on galaxy.com.
Image source: Shutterstock