Summary of the latest meeting of Ethereum core developers: The consensus layer upgrade will be named "Fulu"

Original title: 《Ethereum All Core Developers Consensus Call #140 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 140th ACDC call was hosted by Alex Stokes, a researcher at the Ethereum Foundation (EF), and covered topics such as the Pectra Ethereum Improvement Proposal (EIP) and the development progress of PeerDAS.

During the meeting, developers reviewed updates to EIP 7251 to address miscalculated relevance penalties, updates to the new block body, the launch of PeerDAS Devnet 2, and more. Christine Kim, vice president of research at Galaxy Digital, took a detailed note of the meeting, which BlockBeats translated as follows:

On August 22, 2024, Ethereum developers held the 140th All-Core Developer Consensus (ACDC) meeting via Zoom. The ACDC meeting is a bi-weekly meeting series where developers discuss and coordinate changes to the Ethereum consensus layer. This week's meeting was hosted by Alex Stokes, a researcher at the Ethereum Foundation. Developers discussed the development progress of the Pectra EIP and PeerDAS, and discussed the naming of the next Ethereum consensus layer upgrade, ultimately deciding to name it "Fulu" (the name of a star). At the same time, they agreed to use the portmanteau "Fusaka" to refer to the Fulu-Osaka upgrade in future discussions.

Pectra Progress

Stokes mentioned that a new consensus layer specification version for the Pectra upgrade has been released, tagged v1.5.0-alpha.5. He encouraged client teams to review this version. Later, EF DevOps Engineer Parithosh Jayanthi discussed the progress of the Pectra devnets. He mentioned that the Geth client produced some invalid blocks on Pectra Devnet 2, which the developers are investigating. Meanwhile, the Erigon client is facing issues maintaining connection to the spec chain, which the developers are actively debugging. In addition, Jayanthi also stated that there are issues with JSON RPC standardization in the Execution Layer (EL) client, leading to other issues on the development network that need to be fixed.

Pectra Devnet 3 Plans

Stokes reconfirmed plans to launch Pectra Devnet 3 within a week. The Devnet 3 spec can be found here. The updates from EIP 2935 are also being incorporated into Devnet 3, which is to save historical block hashes as state. This is a semantic change and should not affect client implementations. More information can be found here.

EIP 7251 Updates

Developers are considering updates to EIP 7251 with an increase in the maximum effective balance to address edge cases of incorrectly calculated relevance penalties for non-validators with large stakes. Stokes encourages client teams to review these updates carefully and provide comments. The proposed changes can be found here.

Beacon Block Body Updates

As discussed in the previous ACDC meeting, CL clients will need access to the execution payload section in order to properly handle state transitions after the Pectra upgrade. Currently, CL clients do not store execution payloads for reference. Developers are weighing moving these requests to a new field in the beacon block called "ExecutionClientRequests", rather than organizing this information in a separate "envelope" for CL clients to use, as originally suggested by Prysm developer "Potuz".

Overall, developers at the meeting were supportive of the idea, arguing that the proposal would be easier to implement than the original suggestion. Potuz stressed that creating new fields will break existing CL tests, so developers will need to write new spec test vectors to integrate this change in future development networks. Stokes asked client teams to review this proposal in detail, which can be found in this GitHub link.

API Engine Updates

The developers then discussed a proposal from Geth developer "Lightclient" to simplify block transitions for EL clients. As summarized in the previous call, EIP 7685 in Pectra makes it difficult for EL clients to easily distinguish block versions without referring to the fork plan. Lightclient's proposal to unify requests into a single type, enabling EL clients to pass their interpretations to CL, was supported by the majority of developers. However, Nimbus developer "Dustin" expressed concern that this change could make it harder to use clients without SSZ libraries. However, Lightclient and Potuz refuted these concerns, saying that the proposal would not make it harder for clients without SSZ libraries to use, as they could continue to use the old method. Stokes also leaned in favor of the proposal, saying it should be merged into the API Engine spec after a week of review. For more information on the "unified request object" change in the API Engine, see this GitHub link. PeerDAS Progress EF DevOps Engineer Barnabas Busa said his team will launch PeerDAS Devnet 2 on Friday, August 23. Representatives from the Lodestar and Teku client teams are ready to test PeerDAS on Devnet 2. Stokes shared progress on EIP 7742, a most efficient way to update Blob Gas targets so that these values can be set dynamically by CLs. While the EIP still has some design issues to be resolved, there is general support for its inclusion in the Pectra upgrade. Representatives from the Lodestar and Lightclient teams shared their desire to include EIP 7742 in Pectra. Stokes, the proposal’s author, said he will continue to work on the code changes and will discuss possible improvements in future meetings, and may even test it in the Pectra development network.

The developers then spent some time discussing configurability of the number of blobs in the client. No concrete decision was made on this issue. Stokes suggested that client teams continue to think about how to best configure the number of blobs to avoid difficulties when changing or updating these values in the future.

Stokes highlighted several comments left by Nimbus developer Etan Kissling on the agenda for this week's meeting. Work continues on the implementation and testing of EIP 7688's forward-compatible consensus data structures. The developers have not yet decided whether to include it in Pectra. Kissling also requested feedback on a consensus spec change related to how CL clients handle blocks containing one or more zero-length transactions. More details on this change can be found in this GitHub link.

Research Progress

Developers have unanimously agreed to name the next consensus layer upgrade Electra "Fulu". Fulu is a star located in the Cassiopeia constellation. Consensus layer upgrades are often named after major stars, while execution layer upgrades are named after major cities.

A representative from blockchain analytics firm ProbeLabs shared insights into message propagation through the Ethereum network layer (also known as the gossipsub protocol) since the activation of the Dencun upgrade. Their analysis has been published on their blog and can be read in detail here.

「 Original link」