Partnered With:

Summary of the latest Ethereum core developer meeting: Blob Sidecar network update and resolution of EL client diversity issues.

Read this article in 11 Minutes

On November 16th, all core developers of Ethereum participated in the 122nd All Core Developers Consensus (ACDC) conference call.

Original Title: "Ethereum All Core Developers Consensus Call #122 Writeup"

Author: Christine Kim

Translated by: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Consensus Call (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum consensus layer (CL). This is the 122nd ACDC conference call, during which it was pointed out that most CL client teams plan to complete the update implementation of the Deneb specification in the near future, and discussed the launch plan for the new development network. In addition, developers focused on improving the conditions for blob propagation to simplify complexity and discussed the conditions for retrieving missing blocks and blobs in RPC requests.

On the other hand, the meeting mentioned a proposal by Geth developer Szilágyi to address the issue of client diversity on the execution layer (EL). The proposal aims to solve client errors through cross-validation and has led to in-depth discussions on building stateless Ethereum clients and block generation processes. The discussion involved different positions of the EL client team and the potential impact of the proposal on network health and user motivation. The complexity of the issue requires further research and prototyping, and this proposal will be further studied by Geth and other EL client teams.

Christine Kim, Vice President of Research at Galaxy Digital, made a detailed record of the key points of this meeting, which BlockBeasts has translated as follows:

On November 16th, 2023, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #122 meeting. The ACDC conference call is a bi-weekly series of meetings hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum consensus layer (CL). This week, developers focused on discussing the progress of CL improvements for the Cancun/Deneb upgrade.

Most CL client teams have stated that their goal is to complete the implementation of updates to the Deneb specification this week or next week. Developers agreed to begin discussing the launch of Devnet #12 at the All Core Developers' Call (ACDE) next Thursday. The developers then discussed in detail a proposal by Geth developer Péter Szilágyi regarding client diversity issues on the execution layer (EL).

Blob Sidecar Network Update

As discussed in ACDC＃121, the CL client team is improving the conditions for blob propagation to significantly reduce the complexity and issues related to blob propagation observed in the past 11 development networks. The following are progress updates from each CL client team since the last ACDC:

Lighthouse: Development is almost complete. We need to review and test new code by next weekend.Teku: Implemented new propagation validation. Currently developing construction workflow.

Lodestar: plan to complete implementation this weekend.

Prysm: The implementation is planned to be completed next weekend. Another week will be needed to organize and build the workflow.

Based on the update of the CL client, Ryan suggested planning to launch Devnet #12 during the next ACD conference call. Barnabas Busa, the DevOps engineer of the Ethereum Foundation (EF), said that the "reasonable" target launch date for the next Cancun/Deneb development network could be November 29th or 30th. Parithosh Jayanthi, another DevOps engineer at EF, inquired about the latest situation regarding hive testing. Mario Vega of the EF testing team confirmed that the basic hive test for the upgrade is ready. His team will add new test cases for building and "blobber" workflows to the hive test suite in the coming weeks.

Next, Teku developer Enrico Del Fante raised a question about the appropriate conditions for using the "byRoot" RPC request to retrieve missing blocks and blobs in the CL client after Cancun/Deneb. Del Fante provided a detailed explanation of these issues. Other developers on the call supported the clarification of when a client should receive blocks and blobs through RPC requests when they have not received them through the gossip protocol. Developers also discussed other conditions that clients need to meet to respond to RPC requests for blocks and blobs. Prysm developer Terence Tsao pointed out that there are "three levels" to address these conditions. The client may receive a blob or block through the Ethereum peer-to-peer network layer at the first level. The second level is the client receiving the blob or block through gossip and verifying the message through state transition functions. The third and final level is the client receiving all necessary information about the block and its related blobs. Developers debated which level of Del Fante's question needs to be met in the Cancun specification.

Ryan suggested that Del Fante create a pull request on GitHub to formalize the language of this issue and finalize it by next week.

解决 EL 客户端多样性问题

Translation:

Solving the EL Client Diversity Problem

The last topic discussed on ACDC#122 was the "Making EL Diversity Moot" proposal presented by Szilágyi. Geth developer Marius van der Wijden shared a summary of the proposal during the call, explaining that it aims to address the "worst-case scenario" where most clients have errors, leading to the majority of validators on Ethereum being slashed and forced to exit the network. Szilágyi's proposal suggests a solution that encourages users to cross-validate with other minority clients instead of encouraging them to switch to a minority client.

"Instead of requiring people to run a few clients (which may be inconvenient) or requiring them to run multiple clients (which may be expensive), we can allow them to use any client they like and simply require them to perform stateless cross-validation with other clients," Szilágyi suggested. In order for this proposal to work, the Geth and other EL client teams will have to work on building lightweight versions of their clients for cross-validation of Ethereum blocks. The client version used for cross-validation of blocks will not be able to synchronize with the network, propose blocks, or perform all the functions of the EL client in other ways. Van der Wijden mentioned that building a "stateless" Ethereum client will help with the Verkle Trie upgrade for future Ethereum.

Nethermind developer Łukasz Rozmej expressed a negative attitude towards the proposal because the EL client requires additional work to cross-validate with other clients, which will introduce delays to the block generation process. In addition, Rozmej stated that he would rather wait for the completion of the Verkle Trie upgrade before building a production-ready stateless Ethereum client. Rozmej also questioned how the client would handle block generation if cross-validation with other clients fails. To address this issue, Ryan suggested adopting an "n of m" approach. If cross-validation of the block is successful in at least 3 out of 6 clients, the validator will continue to validate the block, otherwise validation will stop.

Ryan also expressed a concern that this proposal may further reduce the motivation for users to switch from using most clients like Geth to a few clients, especially if the cross-validation proposal by Szilágyi reduces the risk of reduction due to errors in Geth. "I think this is the right thing for the health of the network," Van Der Wijden responded to Ryan's concerns. "The most important thing is that we will not ultimately determine any invalid state. This is more important than whether Geth occupies 50% or 60% of the network." Van Der Wijden also pointed out that the proposal does not need the support of all EL client teams to continue to advance. At least, Van Der Wijden said that the Geth team will investigate the prototype design for this proposal and provide benchmark data on block verification delays.