Summary of the latest Ethereum core developer meeting: Pectra repair and preparation, PeerDAS progress

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

Original author: Christine Kim

Original translation: 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), the beacon chain. The 139th ACDC call was hosted by Alex Stokes, a researcher at the Ethereum Foundation (EF), and covered fixes to Pectra Devnet 2, preparations for Devnet 3, progress on the implementation of PeerDAS, 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 discussed the progress of the implementation of PeerDAS. In addition, the proposal of EIP 7688, which aims to introduce a forward-compatible data structure to support potential changes in Ethereum's data serialization method, also attracted extensive discussion among participants. Christine Kim, vice president of research at Galaxy Digital, took a detailed note of the meeting, and BlockBeats compiled the original text as follows:

On August 8, 2024, Ethereum developers held the 139th Core Developer Consensus Call (ACDC) via Zoom. The ACDC call is a series of meetings held every two weeks 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 Alex Stokes, a researcher at the Ethereum Foundation (EF). Developers discussed fixes for Pectra Devnet 2, preparations for Devnet 3, progress on the PeerDAS implementation, and new data on Ethereum node distribution.

Pectra Update

Stokes announced that EF researcher Hsiao Wei Wang is about to launch an official update to the Pectra Consensus Layer (CL) specification, alpha.4, which includes many improvements over the previous version and is scheduled for release in the near future.

On the topic of Pectra Devnet 2, EF Developer Operations Engineer Barnabas Busa said the network is stable and has reached 85% network participation. There are still some minor issues that need to be resolved in the Execution Layer (EL) clients, mainly EthereumJS and Erigon. Most CL clients are stable on Devnet 2. However, Busa mentioned a minor issue with the Prysm client that needs further investigation. EF DevOps Engineer Parithosh Jayanthi added that there are also issues between Lighthouse, Teku, and Besu nodes that need to be investigated by client teams.

The developers then discussed how to improve the communication flow for devnet startup. Kasey Kirkham, a Prysm developer, pointed out in a Zoom chat that she was not aware of the startup time of Devnet 2. To ensure that the launch information of Devnet 3 is accurately communicated to all client teams, the developers decided to set up a regular weekly meeting to update Pectra on the testing progress. While the exact date has not yet been determined, these meetings are expected to take place every Monday, similar to the pre-Dencun testing calls. Jayanthi suggested that these meetings will be short and efficient, lasting between 15 and 30 minutes, and focus on discussing Pectra-related devnet testing updates, covering topics such as PeerDAS and EOF devnets.

When discussing the topic of Pectra Devnet 3, the developers reiterated that it will continue to use the same EIP configuration as Devnet 2. In addition, Devnet 3 will integrate the newly designed EIP 7702 for the first time, and the team will test it carefully to ensure its compatibility with Pectra's core EIPs. Gajinder Singh of the Lodestar team mentioned that the issues in EIP 7251, the MaxEB proposal, found in Devnet 2, although debugged, still need to be tested more deeply on the next Pectra devnet to verify the solution.

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

Developers discussed the deprecation of the mplex protocol. Mplex was a protocol used by CL clients to transmit multiple data streams on a single communication link, but it has been abandoned by its maintainers. Client teams are planning to move to new data stream multiplexing technologies such as yamux. Phil Ngo of Lodestar announced that they have completed the integration and testing of yamux and prefer to transition directly to the new protocol rather than maintain two protocols in the long term, as this will increase the operating costs of the client. Etan Kissling of Nimbus also revealed that their team is testing yamux. The developers agreed to continue to monitor the progress of other CL client teams on the protocol transition and plan to re-evaluate the migration strategy from mplex to the new multiplexer in the coming months.

Etan Kissling raised the topic of EIP 7688 on the Pectra topic, which aims to introduce a forward-compatible data structure that smart contract developers can continue to use when the Ethereum Execution Layer (EL) data serialization method transitions from RLP to SSZ. Although the Pectra upgrade itself will not fully implement SSZ, EIP 7688 was proposed to ensure forward compatibility of Pectra EIPs in terms of data changes.

Alex Stokes was cautious about including EIP 7688 in the Pectra upgrade, believing that the scale of the upgrade is already quite large. Parithosh Jayanthi mentioned in the meeting that EIP 7688 could 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 adding new EIPs to Pectra should be avoided until all existing Pectra EIPs reach a stable state. Kissling accepted this suggestion and asked when would be the best time to revisit this topic. Although no specific answer was received, the team generally agreed that EIP 7688 should be re-evaluated before the launch of Pectra Devnet 5.

PeerDAS Updates

Representatives from the Prysm client team reported on their latest progress on the PeerDAS implementation, and sparked a discussion on the need for "blobsidecar" Engine API requests. Alex Stokes suggested that the next PeerDAS group meeting be used to discuss in depth the changes needed for the Engine API for PeerDAS. He also noted that an EF researcher has drafted a formal specification proposing to remove sampling from PeerDAS in order to reduce the complexity of the upgrade process. However, at the most recent PeerDAS group meeting, participants expressed concerns that this move might make it more difficult to reintroduce sampling via a future hard fork. In addition, the impact of removing sampling on the safe increase of the blob gas limit in Pectra is unclear. A proposal to decouple blob gas limits in the Execution Layer (EL) and Consensus Layer (CL), EIP 7742, was brought up again during this week's call. Stokes said he would update the EIP and planned to discuss its possible inclusion, as well as issues related to blob gas limit adjustments in Pectra, at the next CL call.

Research Update

During this week's call, the 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 suggested that validator balances might not be updated for a long time during a merge, which could cause the protocol to incorrectly assign sync committee responsibilities. In response, Alex Stokes said 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 changing the existing merge design.

Then, the developers discussed changes to the Ethereum network layer, specifically the introduction of "quic ENR entry". Quic stands for fast UDP internet connection, which helps nodes send and receive data. Stokes suggested creating a pull request (PR) on GitHub to further detail the specific changes to quic ENR entry.

Finally, ProbeLab shared their ongoing analysis of the node operations of the Ethereum network. The report shows that there are currently 8,335 nodes running on the Ethereum network, of which 42% use the Lighthouse client. Nodes operating in the United States account for 36% of the total, and about half of the nodes are deployed in data centers. Prysm developer "Potuz" was curious about the phenomenon that the number of Lighthouse nodes hosted in data centers exceeds that of self-hosted nodes. Stokes speculated that this may be because the main user groups of the Lighthouse client include institutions and professional node operators.

At the end of the meeting, Potuz urged the team to review the PR he submitted on adjusting the execution payload structure. The proposal was first proposed in the last ACDC call. Potuz stressed the importance of a quick decision, noting that while the changes are conceptually simple, integrating them into the consensus layer (CL) specification is challenging. He suggested that developers get started on this work as soon as possible.

「 Original link」