skip to content

Ethereum All Core Developers Consensus Call #122 Writeup

Ethereum All Core Developers Consensus Call #122 Writeup, Galaxy Research, Christine Kim

On November 16, 2023, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #122. Chaired by Ethereum Foundation Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, developers discussed progress on the CL rework for the Cancun/Deneb upgrade. Most CL client teams said they were aiming to finish their updated implementations of Deneb specifications this week or next. Developers agreed to begin discussing the launch of Devnet #12 during next Thursday’s All Core Developers Execution (ACDE) call. Then, developers discussed a proposal by Geth developer Péter Szilágyi to address concerns about client diversity on the execution layer (EL).

Blob Sidecar Networking Updates

As discussed on ACDC #121, CL client teams are working on a revamp to blob gossip conditions that will significantly reduce complexities and issues related to blob propagation that has been observed on the past 11 devnets. The following are updates from various CL client teams on their progress since the last ACDC:

  • Lighthouse: Pretty much done development. Will need until the end of next week to review and test the new code.

  • Teku: New gossip validation implemented. Working on builder workflow.

  • Lodestar: On track to finish implementation by end of this week.

  • Prysm: On track to finish implementation by the end of next week. Will need another week thereafter to put together the builder workflow.

Based on CL client updates, Ryan suggested planning the launch of Devnet #12 during the next ACD call. Barnabas Busa, a DevOps Engineer at the Ethereum Foundation (EF), said a “reasonable” target launch date for the next Cancun/Deneb devnet would be November 29th or 30th. Parithosh Jayanthi, also a DevOps Engineer at the EF, asked for an update on hive tests. Mario Vega, on the testing team at the EF, confirmed that the basic hive tests for the upgrade are ready to go. His team will be adding new test cases for the builder and “blobber” workflows to the hive test suite over the next few weeks.

Then, Teku developer Enrico Del Fante raised a question about the proper conditions that should provoke CL clients to use the “byRoot” RPC request to retrieve missing blocks and blobs post-Cancun/Deneb. Del Fante’s questions about these conditions are explained in detail here. Other developers on the call were supportive about adding clarity to CL specifications as to when blobs and blocks should be received by a client through an import via an RPC request if the client has not received them through gossip. Developers also discussed the conditions that need to be met for other clients to answer RPC requests for blocks and blobs. Prysm developer Terence Tsao highlighted that there are essentially “three levels” to these conditions. A client may have received a blob or block through the peer-to-peer networking layer of Ethereum. The second layer is the client receiving this blob or block through gossip and verifying the message through the state transition function. The third and final layer is the client receiving all necessary information about a block and its associated blobs. Developers debated which level is necessary to meet in Cancun specifications regarding Del Fante’s question.

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

Addressing EL Client Diversity Concerns

The last topic of discussion on ACDC #122 was Szilágyi’s “Making EL Diversity Moot” proposal. Geth developer Marius van der Wijden shared a summary of the proposal on the call, explaining that the “worst case scenario” that this proposal seeks to address is if a majority client has a bug that causes most validators on Ethereum to get slashed and forcefully exited from the network. Instead of encouraging users running a majority client to switch to a minority client, Szilágyi’s proposal suggests encouraging users to cross-validate their existing client with other minority clients.

“Instead of asking people to run a minority client (may be inconvenient), or asking them to run multiple clients (may be expensive); we can let them use whatever client they fancy, and rather only ask them to cross-validate with other clients, statelessly,” Szilágyi suggests. For this proposal to work, Geth and other EL client teams will have to work on building a light version of their client that can be used to cross-validate Ethereum blocks. The version of clients used to cross-validate blocks would not be able to sync to the network, propose blocks, or otherwise perform the full functions of an EL client. Van der Wijden mentioned that the work to build “stateless” Ethereum clients will be useful in the future for Ethereum’s Verkle Trie upgrade.

Nethermind developer Łukasz Rozmej said that he was not favorable to the proposal because the additional work for EL clients to cross-validate their blocks with other clients would introduce latency to the block production process. In addition, Rozmej said that he would prefer the work to build production ready stateless Ethereum clients come after the Verkle Trie upgrade. Rozmej also asked how clients would handle block production if cross-validation with other clients fails. To solve for this, Ryan suggests an “n of m” approach. If cross-validation of a block is successful with at least 3 out of 6 clients, the validators will continue to attest to blocks, otherwise, attestations will be halted.

Ryan also raised the concern that this proposal may further reduce incentives for users to switch from using a majority client like Geth, to a minority client, especially if risks of slashing due to a bug in Geth are reduced with Szilágyi’s cross-validation proposal. “I think this is the right thing to do for the health of the network,” said Van Der Wijden in response to Ryan. “The most important thing is that we’re not finalizing any invalid state. This is way more important [to avoid] than if Geth has 50% or 60% of the network.” Van Der Wijden also noted that the proposal does not need buy in from all EL client teams to move forward. At the very least, Van Der Wijden said that the Geth team will investigate prototyping this proposal and offering up benchmarks on block validation latencies.

At the end of the call, Ryan gave a reminder to developers that next Thursday’s ACD call is scheduled to happen as usual at 14:00 UTC. Next week’s call will occur during the American Thanksgiving holiday. As a special note for readers, there will be no write-up for next Thursday’s ACD call. These writeups will resume the following week on Friday, December 1.