skip to content

Ethereum All Core Developers Consensus Call #136 Writeup

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

On June 27, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #136. 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 new research on client diversity data collection and multi-client block validation.

They also shared updates on progress for the Pectra upgrade. Pectra Devnet 1 is close to being ready for launch. The EF Developer Operations (DevOps) team is waiting for execution layer (EL) client readiness. Teku developer Mikhail Kalinin shared updates to EIP 6110 specifications. PeerDAS Devnet 1is live with three different CL client implementations. Work on SSZ code changes, EIP 7688 and EIP 6493, is ongoing, though developers are undecided about whether they will end up including these two additional EIPs in Pectra.

New Research

Jorge Arce-Garro, a researcher at Nethermind, shared a presentation on his team’s latest efforts to improve the way data about client diversity is reported by node operators. The research was funded through a grant from the EF. It offers three different approaches to facilitate the communication of client type by a validator node operator and assesses each approach based on complexity, security, and ability to protect the anonymity of node operators. Arce-Garro requested feedback on his team’s research, which is posted on Ethresearch.

Next, Geth developer Péter Szilágyi shared updates on his team’s work to support EL cross-validation. This was an idea first raised by Szilágyi in November 2023 to improve the resiliency of Ethereum in the event of a catastrophic bug in a majority client. EL cross-validation is aimed at enabling the verification of blocks with multiple clients. This way if the results of block verification with one client differs from another, node operators can refuse to accept or attest to the block and thereby prevent a potential chain split in the event of one client failure.

Since November, the Geth team has fleshed out the idea and implemented a version of it in their own software. While the implementation across all clients would not require a hard fork, Szilágyi did highlight major changes to the Engine API for EL cross-validation to work. He also shared benchmarks on added latency to block imports. “It's about the 20% performance hit to block import. So, if imports [take] about 100 milliseconds, then creating the witness [takes] maybe another 20 milliseconds extra. I think that's very, very cheap, and that's kind of the only component that we have optimized heavily,” said Szilágyi, adding that further testing and benchmarking on EL cross-validation is still needed.

Due to the complexity of the changes proposed, developers on the call like Guillaume Ballet, Lukasz Rozmej, and Ahmad Mazen Bitar raised questions about its priority in comparison to the Pectra upgrade and Verkle code changes coming up thereafter. Rather than committing to the whole project, developers discussed ways to get started by focusing on smaller pieces of it, for example, updating Engine API JSON and binary encoding, which Szilágyi stressed is an effort need in the long run anyways for this piece of software. There were no concrete decisions made about the project. Szilágyi reiterated that full details on it are shared on GitHub and feedback is appreciated.

Electra Updates

EF DevOps Engineer Parithosh Jayanthi said that his team is waiting on EL client teams to launch Pectra Devnet 1. Teku developer Mikhail Kalinin said that he has finalized specifications changes to EIP 6110, which adds a queuing mechanism for processing new validator deposit requests from the EL on the CL. Kalinin requested feedback from developers on his proposed changes.

EF DevOps Engineer Barnabas Busa shared an update on PeerDAS development. He noted that the second devnet for PeerDAS is live with three different CL client implementation. Busa added that his team has begun stress testing the devnet and already discovered a few issues in client implementations, which client teams are working on fixing.

Stokes noted that there are outstanding open-ended questions about PeerDAS implementation that include how the blob gas limit should be communicated between the EL and CL, as well as how the blob base fee calculation should be similarly handled. There are multiple proposals developers are weighing to address these issues. Stokes asked that developers review these proposals more closely over the next few weeks so that they can come to an agreement about them on a future call.

Then, Nimbus developer Etan Kissling shared updates on implementation work for EIP 7688 and EIP 6493. These are two code changes related to upgrading Ethereum’s data serialization methods that have not yet been formally accepted into the Pectra upgrade but that certain developers are keen on including posthaste. Kissling said that he would like to see EIP 7688 included in Pectra Devnet 2, which drew some concern from client team representatives and the EF DevOps team. Stokes suggested that developers reassess the readiness of EIP 7688 for inclusion in a Pectra devnet at a later date.

On EIP 6493 progress, Kissling shared that the EthereumJS EL client has a working implementation of the code change and he is working towards making a client demo for the proposal as well.