Ethereum All Core Developers Consensus Call #122 Writeup
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.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2023. All rights reserved.