skip to content

Ethereum All Core Developers Consensus Call #140 Writeup

Ethereum All Core Developers Consensus Call #140 Writeup - Galaxy Research

On August 22, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #140. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also called the Beacon Chain. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Developers discussed development progress on Pectra Ethereum Improvement Proposals (EIPs) and PeerDAS. They also discussed naming for the next Ethereum CL upgrade and agreed to name it after the star name “Fulu”. They also agree to use the portmanteau “Fusaka” when referring to the Fulu-Osaka upgrade in future discussions.

Pectra

Stokes flagged that there is a new CL specifications release for the Pectra upgrade, tagged as v1.5.0-alpha.5. He encouraged client team to review the release. Then, EF Developer Operations Engineer Parithosh Jayanthi spoke about the status of Pectra devnets. He noted that the Geth client has produced a couple of invalid blocks on Pectra Devnet 2, which developers are investigating. Jayanthi said the Erigon client has is facing issues staying connected to the canonical chain. Developers are actively debugging the devnet. Also, Jayanthi said there is a JSON RPC standardization issue in execution layer (EL) clients causing additional issues on the devnet that requires fixing.

Pectra Devnet 3

Stokes reconfirmed the plan to launch Pectra Devnet 3 in one week time. The specifications for Devnet 3 can be found here. There is an update to EIP 2935, save historical block hashes in state, that developers will incorporate into Devnet 3. It is a semantics change that should not impact client implementations. More information about it can be found here.

EIP 7251 Update

Developers are considering an update to EIP 7251, maximum effective balance increase, to resolve an edge case scenario where the correlation penalty is incorrectly computed for a slashed validator with a large effective balance of staked ETH. Stokes encouraged client team to closely review the updates and chime in with thoughts. The proposed changes can be found here.

Beacon Block Body Update

As discussed on prior ACDC calls, there are parts of the execution payload that CL clients will need to access in order to process state transitions correctly after the Pectra upgrade. Currently, CL clients do not store the execution payload for reference. Instead of organizing the necessary information or requests from the execution payload in a separate “envelope” of sorts for CL clients to use, as was the initial suggestion by Prysm developer “Potuz”, developers are now weighing moving these requests to a new field in the Beacon block called “ExecutionClientRequests”.

Generally, developers on the call were supportive of the idea, commenting that this proposal is easier to implement than the initial suggestion. Potuz highlighted that existing tests for the CL will be broken by the creation of the new field. Thus, developers will need to work on creating new specification test vectors to incorporate this change on future devnets. Stokes asked client teams to review the proposal in detail. It can be found at this GitHub link.

Engine API Update

Then, developers discussed a proposal by Geth developer “Lightclient” to simplify block conversion for EL clients. EIP 7685 in Pectra will make it difficult for EL client to easily differentiate block versions without referencing a fork schedule, as summarized on a prior call. Lightclient’s proposal to unify requests into a single type so that EL clients can pass along the interpretation of them to the CL was generally well-taken by most developers on the call. However, Nimbus developer “Dustin” expressed concerns that the change could make it more challenging for clients to use without a functioning SSZ library. However, Lightclient and Potuz pushed back on these concerns saying that the proposal would not make it any more difficult for clients without a SSZ library to use as they can fall back to utilizing the old method for request representation. Stokes also leaned in favor of the proposal and said it should be merged into Engine API specifications after another week of review. For more information about the “unify request objects” change in the Engine API, refer to this GitHub link.

PeerDAS

EF Developers Operations Engineer Barnabas Busa said that his team will launch PeerDAS Devnet 2 on Friday, August 23. Representatives from the Lodestar and Teku client teams affirmed that they have PeerDAS implementations ready for testing on Devnet 2. Stokes shared progress made on EIP 7742, a way to update the blob gas target and maximum so that these values can be dynamically set by the CL. While there remains a few outstanding design questions about the EIP, the EIP appears to have strong support from developers for inclusion in the Pectra upgrade. Representatives from the Lodestar and Lightclient teams shared their preference for including EIP 7742 in Pectra. Stokes, the author of the proposal, said that he would continue to work on the code changes and raise it again for discussion, and perhaps inclusion in a Pectra devnet, on a future call.

Then, developers spent some time discussing blob count configurability in clients. There were no concrete decisions made about this. Stokes recommended that client teams continue to think through how best to configure blob counts in clients to avoid difficulty when changing or updating these values in the future.

Stokes highlighted a few comments left on this week’s call agenda by Nimbus developer Etan Kissling. Progress continues to be made on the implementation and testing for EIP 7688, forward compatible consensus data structures. Developers have not decided yet on whether to include it in Pectra. Kissling also requested feedback on a change to consensus specifications related to how CL clients handle blocks with transactions containing one or more zero-length transactions. Further details about the change can be found at this GitHub link.

Research

Developers agreed to name the next CL upgrade after Electra “Fulu”. Fulu is the name of a star in the Cassiopeia constellation. CL upgrades are generally named after major stars, while EL upgrades are named after major cities.

A representative from ProbeLabs, a blockchain analytics company, shared insights about message propagation through the Ethereum networking layer, also known as the gossipsub protocol, since the activation of the Dencun upgrade. Their analysis has been shared on their blog and can be read it more detail here.