Original title: Ethereum All Core Developers Consensus Call#139Writeup
By 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 and covered fixes for Pectra Devnet 2, preparations for Devnet 3, progress on the 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 had an in-depth discussion on the implementation progress 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 aroused extensive discussion among participants. Christine Kim, vice president of research at Galaxy Digital, took a detailed note of this 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 bi-weekly series of 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 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 the official updated version alpha .4 of the Pectra consensus layer (CL) specification, which includes many improvements over the previous version and is planned to be released in the near future.
On the topic of Pectra Devnet 2, EF Developer Operations Engineer Barnabas Busa said that 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 minor issues with the Prysm client that need 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.
Afterwards, the developers discussed how to improve the communication process for devnet startup. Kasey Kirkham, a developer at Prysm, pointed out in a Zoom chat that she was unaware of the launch 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 the testing progress of Pectra. Although the specific time has not yet been determined, these meetings are expected to be held every Monday, similar to the testing calls before the Dencun upgrade. 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 latest design of EIP 7702 for the first time, and the team will test it carefully to ensure its compatibility with Pectra core EIPs. Gajinder Singh of the Lodestar team mentioned that the problems found in EIP 7251, the MaxEB proposal, 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 spec that allows CL clients to get blobs from the EL blob transaction memory pool. The method is called "getBlobsV1". To avoid 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 method on Pectra Devnet 3.
Developers discussed the deprecation of the mplex protocol. Mplex was once a protocol used by CL clients to transmit multiple data streams on a single communication link, but it has now 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 reached a consensus that they will continue to pay attention to the progress of other CL client teams in protocol transition, and plan to re-evaluate the migration strategy from mplex to the new multiplexer in the coming months.
Etan Kissling brought up 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 was 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 new EIPs should be avoided from being added to Pectra until all existing Pectra EIPs have reached a stable state. Kissling accepted this suggestion and asked when would be the best time to revisit this topic. Although no specific response 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 at the meeting, which led to a discussion on the necessity of "blob sidecar" Engine API requests. Alex Stokes suggested that the changes required for PeerDAS to the Engine API be discussed in depth at the next PeerDAS group meeting. He also pointed out that an EF researcher has drafted a formal specification proposing to remove the sampling mechanism from PeerDAS with the goal of reducing 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 through a hard fork in the future. In addition, the impact of the removal of the sampling mechanism on the safe increase of the blob gas limit in Pectra is unclear. A proposal to decouple the blob gas limit in the execution layer (EL) and the 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 the blob gas limit adjustment in Pectra, at the next CL call.
Research Updates
In this week's call, developers focused on three research topics. First, they explored edge cases that validators may encounter when merging staked ETH balances under EIP 7251. Etan Kissling suggested that validator balances may not be updated for a long time during a merge, which may cause the protocol to incorrectly assign synchronization committee responsibilities. In response, Alex Stokes said that this problem 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.
The developers then 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 operation 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" expressed curiosity 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 his PR for adjusting the execution payload structure. The proposal was first raised in the last ACDC call. Potuz stressed the importance of making decisions quickly, noting that while these changes are conceptually simple, integrating them into the consensus layer (CL) specification is challenging. He recommended that developers start working on this as soon as possible.
