Summary of the latest meeting of Ethereum core developers: Pectra fixes and preparations, PeerDAS progress

Original Title: 《Ethereum All Core Developers Consensus Call #139 Writeup

Author: Christine Kim

Compiled by: Ladyfinger, BlockBeats

Editor's Note:

The Ethereum All Core Developers Consensus Call (ACDC) is a bi-weekly series of meetings focused on discussing and coordinating changes to the Ethereum consensus layer (CL), also known as the Beacon Chain. The 139th ACDC call was hosted by Ethereum Foundation (EF) researcher Alex Stokes, covering topics such as fixes for Pectra Devnet 2, preparations for Devnet 3, progress on PeerDAS implementation, and new data on Ethereum node distribution.

During the meeting, developers reviewed the stability and issues of Pectra Devnet 2, discussed preparations for the upcoming Devnet 3, and engaged in an in-depth discussion on the progress of PeerDAS implementation. Additionally, the proposal for EIP 7688 sparked widespread discussion among attendees, aiming to introduce a forward-compatible data structure to support potential changes in Ethereum's data serialization methods. Galaxy Digital's Vice President of Research, Christine Kim, provided a detailed account of the meeting, and BlockBeats compiled the original text as follows:

On August 8, 2024, Ethereum developers held the 139th Core Developers Consensus Call (ACDC) via Zoom. The ACDC calls are bi-weekly meetings where developers discuss and coordinate changes to the Ethereum consensus layer (CL), also known as the Beacon Chain. This week's call was hosted by Ethereum Foundation (EF) researcher Alex Stokes. Developers discussed fixes for Pectra Devnet 2, preparations for Devnet 3, progress on PeerDAS implementation, and new data on Ethereum node distribution.

Pectra Update

Stokes announced that EF researcher Hsiao Wei Wang is set to release the official updated version alpha.4 of the Pectra consensus layer (CL) specification, which includes multiple improvements over the previous version and is planned for release soon.

Regarding Pectra Devnet 2, EF Developer Operations Engineer Barnabas Busa stated that the network is stable and has reached 85% participation. There are still some minor issues to resolve in the execution layer (EL) clients, primarily with EthereumJS and Erigon. Most CL clients are stable on Devnet 2. However, Busa mentioned that the Prysm client requires further investigation for minor issues. EF DevOps Engineer Parithosh Jayanthi added that the client teams need to investigate issues between Lighthouse, Teku, and Besu nodes.

The developers then discussed how to improve the communication process for devnet launches. Prysm developer Kasey Kirkham pointed out his lack of awareness regarding the launch timing of Devnet 2 in the Zoom chat. To ensure that the launch information for Devnet 3 is accurately communicated to all client teams, the developers decided to establish a regular weekly meeting to update on Pectra's testing progress. Although the specific time has not yet been determined, these meetings are expected to occur every Monday, similar to the testing calls before the Dencun upgrade. Jayanthi suggested that these meetings should be brief and efficient, lasting between 15 to 30 minutes, focusing on discussing Pectra-related devnet testing updates, covering topics such as PeerDAS and EOF devnets.

When discussing Pectra Devnet 3, the developers reiterated that it will maintain the same EIP configuration as Devnet 2. Additionally, Devnet 3 will integrate the newly designed EIP 7702 for the first time, and the team will conduct thorough testing to ensure compatibility with Pectra core EIPs. Gajinder Singh from the Lodestar team mentioned that issues found in EIP 7251, part of the MaxEB proposal, during Devnet 2, although debugged, still require deeper testing in the upcoming Pectra devnet to validate the solutions.

As discussed in ACDE #193, there is a new Engine API specification that allows CL clients to retrieve blobs from the EL blob transaction memory pool. This method is called "getBlobsV1." To prevent misuse, Teku developer Enrico del Fante proposed some clarifications to the CL specification. Stokes suggested that developers review these clarifications and plan to test the use of this method on Pectra Devnet 3.

The developers discussed the deprecation of the mplex protocol. Mplex was previously used by CL clients for multiplexing multiple data streams over a single communication link but has now been deprecated by its maintainers. Client teams are planning to transition to new data stream multiplexing technologies like yamux. Phil Ngo from Lodestar announced that they have completed the integration and testing of yamux and prefer to transition directly to the new protocol rather than maintaining two protocols long-term, as this would increase operational costs for clients. Nimbus's Etan Kissling also revealed that their team is testing yamux. The developers reached a consensus to continue monitoring the progress of other CL client teams regarding the protocol transition and plan to reassess the migration strategy from mplex to the new multiplexer in the coming months.

Etan Kissling raised a discussion on EIP 7688 regarding Pectra, which aims to introduce a forward-compatible data structure so that smart contract developers can continue using Ethereum's execution layer (EL) data serialization methods as they transition from RLP to SSZ. Although the Pectra upgrade itself will not fully implement SSZ, the proposal for EIP 7688 is intended to ensure the forward compatibility of Pectra EIPs concerning data changes.

Alex Stokes expressed caution about including EIP 7688 in the Pectra upgrade, noting that the scale of the upgrade is already quite large. Parithosh Jayanthi mentioned during the meeting that EIP 7688 might be tested as early as Devnet 5. Representatives from teams such as Lodestar, Prysm, Teku, and Lighthouse expressed support for the proposal. Stokes and Beiko suggested that new EIPs should be avoided in Pectra until all existing Pectra EIPs reach a stable state. Kissling accepted this suggestion and inquired about the best timing to revisit this topic. Although no specific answer was provided, the team generally agreed that EIP 7688 should be reassessed before the launch of Pectra Devnet 5.

PeerDAS Update

Representatives from the Prysm client team reported on their latest progress regarding PeerDAS implementation during the meeting, which sparked a discussion on the necessity of the "blob sidecar" Engine API request. Alex Stokes suggested a deeper discussion on the adjustments needed for PeerDAS concerning the Engine API in the next PeerDAS working group meeting. He also noted that an EF researcher has drafted a formal specification proposing the removal of the sampling mechanism from PeerDAS to reduce the complexity of the upgrade process. However, during the recent PeerDAS working group meeting, attendees expressed concerns that this move might complicate the reintroduction of sampling through a hard fork in the future. Additionally, the impact of removing the sampling mechanism on the safety increase of the blob gas limit in Pectra remains unclear. A proposal to decouple the blob gas limit in the execution layer (EL) and consensus layer (CL), EIP 7742, was brought up again in this week's call. Stokes stated he would update the EIP and plans to discuss its inclusion and related topics concerning the adjustment of the blob gas limit in Pectra in the next CL call.

Research Update

In this week's call, developers focused on three research topics. First, they explored edge cases that validators might encounter when merging staked ETH balances under EIP 7251. Etan Kissling raised the concern that validator balances might not update for an extended period during the merge, potentially leading to the protocol incorrectly assigning responsibilities for the sync committee. In response, Alex Stokes noted that this issue is similar to how the protocol handles validator exits and suggested documenting this edge case in the consensus layer (CL) specification without altering the existing merge design.

Next, the developers discussed changes to the Ethereum network layer, particularly the introduction of the "quic ENR entry." Quic stands for Quick UDP Internet Connections, which helps nodes send and receive data. Stokes suggested creating a pull request (PR) on GitHub to further detail the specific changes regarding the quic ENR entry.

Finally, ProbeLab shared their ongoing analysis of node operations within the Ethereum network. The report indicated that there are currently 8,335 nodes running on the Ethereum network, with 42% using the Lighthouse client. Nodes operating in the United States account for 36% of the total, with approximately half of the nodes deployed in data centers. Prysm developer "Potuz" expressed curiosity about the phenomenon of more Lighthouse nodes being hosted in data centers than self-hosted nodes. Stokes speculated that this might be due to the primary user base of the Lighthouse client, which includes institutional and professional node operators.

At the end of the meeting, Potuz urged the team to review the PR he submitted regarding adjustments to the execution payload structure. This proposal was first introduced in the previous ACDC call. Potuz emphasized the importance of swift decision-making, pointing out that while these changes are conceptually simple, integrating them into the consensus layer (CL) specification poses significant challenges. He suggested that developers should start this work as soon as possible.