Ethereum All Core Developers Consensus Call #136 Writeup
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.
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 2024. All rights reserved.