Ethereum All Core Developers Consensus Call #135 Writeup
On June 13, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #135. 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 preparations for Pectra Devnet 1, PeerDAS Devnet 1, and a third dedicated test network for Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).
Announcements
Developers kicked off the call with two announcements. EF Developer Operations (DevOps) Engineer Parithosh Jayanthi said that the ethPandaOps team, a group of engineers working within the EF DevOps team, would take over the maintenance and development of the ethereum-package Kurtosis module. This is a software package that developers have used in the past to spin-up Ethereum testnets and associated tooling for the testnets such as Grafana data dashboards for monitoring and testing various client implementations. The migration of the package from the oversight of the Kurtosis tech team to the ethPandaOps team may impact users of the software as certain links will now redirect to GitHub repositories owned by the ethPandaOps team, instead of the Kurtosis team. Jayanthi recommended that users update their links to the software and be on the lookout for new versions of the package from the ethPandaOps team moving forward.
The second announcement on the call was shared by EF Protocol Support Lead Tim Beiko. Beiko noted that he is making efforts to introduce new processes for staging the inclusion of EIPs in an Ethereum upgrade. He has created a draft EIP defining the labels “Proposed for Inclusion”, “Considered for Inclusion”, and “Scheduled for Inclusion”. He requested that developers review the document and provide feedback. He said he would like to finalize the document by the next ACD call.
Electra
Code specifications for the next major release of Electra, v1.5.0-alpha.3, are close to being finished. Developers agreed to merge pull request (PR) #3768 in the Consensus Specs GitHub repository to the next release. This pull request was created by Nimbus developer Etan Kissling who noted that the “committee_bits” field should be appended to the end of “Attestation” as opposed to somewhere in the middle of the data to avoid issues with data serialization. Other than PR #3768, Stokes asked if there were any other outstanding issues needing resolution before the next major release of Electra specifications. Jayanthi mentioned in the Zoom chat that there were outstanding questions about validator consolidations triggered through the execution layer (EL). Stokes made a note to get an update on the status of EL-triggered validator consolidations after the call.
On the topic of implementation progress for the latest Electra specifications, most CL client teams on the call said that they would be able to have a new release ready for testing one to two weeks after v1.5.0-alpha.3 is finalized. Developers agreed to revisit the topic of timing for the next Pectra devnet, Pectra Devnet 1, in a few weeks.
PeerDAS
Then, developers discussed implementation progress on PeerDAS, a networking change to Ethereum that will enhance the ability for nodes to process and validate large quantities of arbitrary data submitted by users through blob transactions. Stokes recapped the decision made from the last ACDC call which was that developers would work on PeerDAS in parallel to other Pectra EIPs by activating PeerDAS on a separate activation epoch on devnets.
Lodestar developer Gajinder Singh said that based on discussions from a more recent breakout meeting on PeerDAS developers will activate PeerDAS on top of the Deneb upgrade on separate devnets from the other Pectra EIPs. Teku developer Enrico Del Fante said that it is easier for developers to build PeerDAS on stable code specifications like the ones already finalized in the prior Ethereum upgrade Deneb than on code specifications for Pectra, which continues to be in flux. Jayanthi agreed that merging PeerDAS implementation with the other Pectra EIP implementations now may cause complications during testing, especially when trying to identify the source of bug. He recommended keeping the two workflows separate and then merging the two once implementations for both are more stable. Stokes agreed and said developers can revisit the topic of merging the two implementations, PeerDAS and other Pectra EIPs, in roughly a month’s time.
On the topic of launching PeerDAS Devnet 1, there was no clear estimation from client teams about when they would be ready for the testnet launch. Individuals on the call shared rough estimations between 2 weeks and 1 month. Stokes recommended revisiting the topic of devnet timelines in a few weeks once client teams have had more time to work on their PeerDAS implementations.
Then, Beiko noted that though PeerDAS is a networking change, not a change to the core protocol of Ethereum, he would still like to include the code changes in the meta EIP for the Pectra upgrade. Meta EIP documents are public documents listing out all the core protocol changes included in an Ethereum upgrade. Beiko noted that PeerDAS is the “biggest feature” in Pectra and despite not needing a hard fork for activation should still be included in the document to signal that developers are serious about preparing it in time for Pectra mainnet activation. There were no objections to this.
Raising the blob gas limit
PeerDAS changes how nodes process and propagate data through Ethereum’s peer-to-peer networking layer. For users, primarily Layer-2 rollups, to benefit from these changes, developers must raise the current limit of six blobs per block to a higher threshold which would enable higher blob, that is arbitrary data, throughput. Changes to the blob limit would require changes to the core protocol of Ethereum and as developers discussed on this week’s call, may involve more intrusive engineering work than simply adjusting a constant value in the protocol tech stack.
Stokes mentioned his proposal to uncouple the dependencies between the EL and CL when making changes to the blob gas limit. Currently, any changes to the blob gas limit requires changes in both the EL and CL protocols. Stokes offered ways to break these dependencies such that developers can safely remove the hard coded blob gas limit from the EL and dictated exclusively by the CL. EF Researcher Dankrad Feist noted that in addition to questions about dependencies between the EL and CL, the ripple effects of changes to the blob gas limit on gas computation for a block are important to consider. “The optimal way would be to change the computation. It's probably a mistake that gas price computation happens in the EL. That should have been in the CL, but that's more difficult to change now. … This is not easy,” said Feist.
Developers agreed to continue investigating the best paths forward for making changes to the blob gas limit and gas computation in a block. Developers also agreed to continue discussing whether an activation of PeerDAS in Pectra will be coupled with an increase to the blob gas limit. Developers were divided on whether these changes should be combined or staged across multiple forks.
Jayanthi said that combining the changes was a “risky” move given that developers will not be sure how PeerDAS will function until it is activated on mainnet. EF DevOps Engineer Barnabas Busa added that the scope of the Pectra fork is already large enough without additional code changes. “The point is we have so many EIPs and I feel like we just keep shoveling more and more things, and it's just never going to end. So, we have to draw some line somewhere where this is where we need to end it and I think shipping PeerDAS and [increasing the blob count] is just not something that we can do in like the next year and half testing wise,” said Busa.
A developer with the screen name “Francesco” chimed in with a suggestion to “de-risk Pectra” by removing PeerDAS if the networking change would not be coupled with a blob count increase. “What benefit are we actually getting from doing PeerDAS with Pectra if [there’s no blob count increase]?” asked Francesco.
To further reinforce the difficulties of testing PeerDAS, Jayanthi noted that testing for EIP 4844, which introduced blobs to Ethereum in Deneb, did not perfectly simulate how blobs actually ended up behaving on and impacting Ethereum mainnet. “The issue is that testing networking is extremely hard. We did do a lot of great [4844] related testing, but the way blobs played out on mainnet is not a one-to-one analog to how it played out in testing. We do see weaker nodes having issues. We do see timing games being played and stuff like that, and that's the main reason why, even if we can simulate a perfect world in which PeerDAS, along with the blob increase does work in all of our devnets, it doesn't actually mean anything to mainnet, and that's my main argument for why we should probably do things step by step, rather than all at once,” said Jayanthi.
EF Research Ansgar Dietrichs commented that the framing of a blob count increase with PeerDAS is mistaken given that PeerDAS alone already requires developers to choose a value for the blob count. While developers could decide to go with the same numbers on Ethereum mainnet, the decision about what numbers to use with PeerDAS will have to be made and the only rationale for using the same numbers as mainnet is if developers increase the complexity of PeerDAS such that PeerDAS has a fallback mechanism to the current Deneb specifications for blob propagation in the event of a bug in PeerDAS. Dietrichs added that the concerns about testing complexity further motivate his views that Pectra should be activated in two hard forks, as opposed to one, but it does not motivate his views that PeerDAS should be decoupled from a change to the blob count.
SSZ Update
Kissling shared an update on progress for three SSZ related EIPs. He noted that implementation work for these EIPs has progressed across multiple clients including Teku, Grandine, and Lighthouse. He said that developers can start to discuss devnet timelines for these SSZ EIPs and potentially including them in the scope of the Pectra upgrade on the next ACDC call.
F-Star Naming
There is an Ethereum Magicians post about what the next Ethereum CL upgrade name should be after Electra. The EL upgrade name that has already been decided by developers for the EL upgrade after Prague is Osaka. The primary contenders for the accompanying CL upgrade are: Fulu, Felis, Formosa, and Funi. These are names in accordance with the naming convention of major star names that start with the letter “F” for the Beacon Chain’s sixth network-wide upgrade. Stokes asked developers on the call to chime in with thoughts on this topic on the Magicians post.
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.