Ethereum All Core Developers Consensus Call #141 Writeup
On September 5, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #141. The ACDC calls are a biweekly 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 a variety of updates to consensus layer specifications and the Engine API in the Pectra upgrade. They also discussed how to address the problem of proof computation for resource-constrained node operators, primarily home stakers, in PeerDAS. Stokes highlighted a proposal to remove SSZ unions from CL specifications since SSZ unions are not used in practice by CL clients.
Pectra Devnet 2
Debugging efforts on Pectra Devnet 2 are nearing completion. Prysm developer Terence Tsao said that his team has resolved a non-finality bug identified on the devnet and they have not seen any issues with their client since. EF Developer Operations Engineer Parithosh Jayanthi said that with the Prysm bug fixed, Pectra Devnet 2 can be deprecated.
Regarding Pectra Devnet 3, Jayanthi reiterated that not all client teams need to be ready with their implementations to launch the next devnet. The devnet can go live with a few implementations and the rest can be added later. Stokes noted that there are outstanding issues with EIP 7702 that may need to be addressed in execution layer (EL) clients before they can be added to the devnet. These issues will likely be unpacked in more detail on the next All Core Developers Execution (ACDE) call.
Pectra Specification Updates
There were a few outstanding issues regarding Pectra implementation on the CL side that developers largely agreed to move forward with fixing on this week’s call.
The first was an update to EIP 7251. As explained on the last ACDC call, the update resolves an edge case where the correlation penalty applied to validators with a high amount of staked ETH is incorrectly computed. Stokes said that the fix is in its final call for review by developers and will be merged into Pectra CL specifications shortly.
The second was an update to the Beacon block body to improve the efficiency by which CL clients can access and store certain components of the EL payload. The rationale for this update was also shared in more detail on the last ACDC call. Stokes confirmed that aside from a minor outstanding fix, this change to the Pectra CL specifications will be finalized and ready for implementation by CL clients.
Third, Geth developer Felix Lange proposed a new strategy for improving the communication of validator withdrawals and consolidation requests from the EL to the CL. The issues regarding unnecessary overhead to EL and CL clients for parsing these requests have been raised on multiple calls. The initial proposal by Geth developer “Lightclient” was to unify all requests into a single list and leave it up to the CL parse. The proposal by Lange suggests encoding the data as “opaque hex bytes” like how transactions are encoded by the EL already. According to Lange, this would remove significant amounts of code from the EL and reduce complexity in CL clients. Stokes said that he generally agreed with Lange’s approach. Lange said that his proposal is contingent on a few changes that would require the buy-in from EL client teams. So, Lange said that he will resurface his ideas on the next ACDE call to get feedback from EL developers as well.
Fourth, developers discussed the creation of a deposit requests queue as detailed by Teku developer Mikhail Kalinin. Currently, there is no rate limiting for validator deposits by the EL deposits smart contract. However, with the activation of EIP 6110, a queue may be necessary to avoid unnecessary load on CL clients in the event of a sudden spike in deposits activity. Kalinin added that the queue is important to prevent a frontrunning attack on withdrawals. With the addition of a queue, any new deposit requests must wait until all existing deposits have been processed. Nimbus developer Jacek Sieka wrote in the Zoom chat that the queue will also make deposit caching in CL clients “less error prone.” Based on the support for Kalinin’s design, Stokes said that the changes should be finalized “soon” and encouraged CL client team to chime in with any final thoughts posthaste.
Finally, developers discussed various refinements of Ethereum’s networking layer based on EIP 7549, “Move committee index outside Attestation”. The refinements are detailed on GitHub here and here. Sieka, who authored the proposals, highlighted that these changes would offer an improvement to CL clients hash computation and bandwidth. Prysm developer “Potuz” expressed his support for the refinements, as did Teku developer Enrico Del Fante. Stokes said that developers should be ready to finalize these changes by the next ACDC call.
PeerDAS Devnet 2
The latest implementation of PeerDAS is being tested locally by clients, according to Jayanthi. Both the Lodestar and Nimbus teams are running a new Kurtosis configuration that spins up a private testnet. It does not appear that developers have yet launched PeerDAS Devnet 2, a multi-client, developer-focused testnet for PeerDAS. PeerDAS Devnet 2 is expected to be rebased on top of the Pectra upgrade, as opposed to Deneb. On the topic of stress testing PeerDAS implementations, Stokes recommended reutilizing the stress tests used for the Deneb upgrade on PeerDAS testnets that are rebased on Deneb and for future testnets that are rebased on Pectra, attempt increases to the blob count based on the design set forth in EIP 7742.
PeerDAS Proof Computations
Then, developers discussed an open question about proof computation in PeerDAS for validators running on resource-constrained devices. Proof computation in the current PeerDAS design is done by CL clients and could take up to 1 second to complete on low-grade hardware like a Rock5 Model B. To preserve the ability of home stakers to participate in the network as validators, developers are weighing three different solutions. The first is to do nothing and expect that home stakers will either upgrade their hardware for more powerful computation or be unable to build blocks with the maximum number of blobs. The second is to prepare blobs on the EL such that proof computation on the CL requires less computational load. The third is to prepare blobs on the CL such that the information needed to start proof computations can happen ahead of and in parallel to block production.
EF Researcher Dankrad Feist said that the issues related to proof computation on resource-constrained devices should expedite research into distributed block building. Home stakers should be able to avoid proof computation and instead rely on receiving these proofs from other more powerful nodes in the network. He also added that developers should refrain from pursuing the second option because it would mean that further changes to data availability sampling after Pectra would require changes to both the EL and CL. “We want to make those upgrades without having to change the EL as well. I do think we should find a reasonable way of getting the blobs into the CL so that it can generate the proofs. But I think the actual even more promising avenue for home stakers will be getting other nodes to generate the proofs for them,” said Feist.
On the topic of what type of devices developers expect home stakers to feasibly operate with, it was clear from the discussion that it is no longer feasible for stakers to rely on a Raspberry Pi device. This used to be the oft cited low-grade machine that developers said could be used to operate an Ethereum validator and solo stake. Since the launch of the Beacon Chain, the computational requirements for operating a validator have increased and a Raspberry Pi is likely no longer a feasible choice for home stakers. “I don't feel like a Raspberry Pi is currently really a common choice for stakers. That was our target five years ago. We’ve probably moved on from that and we have slightly more powerful, bigger devices now. It feels hard to even get less than 4 cores nowadays,” said Feist.
Given that paths forward for decentralized block building are still in the research phase, Stokes recommended moving ahead with the third solution for implementation in Pectra. He asked Feist to create a group or Discord channel to start work on this asynchronously from the call.
Research Discussion
Nimbus developer “Dustin” has created a proposal to remove all mentions of SSZ unions from CL specifications. This does not impact any client implementations as SSZ unions have never been used in CL clients. Dustin said that his motivation for proposing the removal is to better align CL specifications with existing CL client implementations. Stokes noted that the mentions of SSZ unions in the specifications were initially in reference to early sharding designs for the Beacon Chain. Given that these early designs have since been abandoned by developers, Stokes agreed that references to SSZ unions can be removed. However, he recommended that a note should be made in their place that points to where details about the use of SSZ unions in CL specifications can be found in case they are ever needed or useful again.
The Portal team, which is the team building out a decentralized peer to peer network for servicing expired chain history data, reportedly left a comment on Dustin’s proposal that they are using the SSZ union referenced in the specifications in some way. Stokes said that he would follow up directly with the Portal team about this before finalizing the removal.
Dustin pushed back on the need for CL specifications to support the work of an out-of-protocol project like the Portal Network. However, other developers on the call reaffirmed the importance of Portal to the Ethereum protocol and the fact that it is a project heavily funded and supported already by the EF.
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.