Ethereum All Core Developers Consensus Call #147 Writeup
On December 12, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #147. This week, the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. The ACDC calls are a biweekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also known as the Beacon Chain.
On ACDC #146, developers agreed to remove EIP 7742, uncouple blob count between CL and execution layer (EL), from Pectra and aim to launch Pectra Devnet 5 some time before the end of the year.
Mekong
Mekong, the public Pectra devnet based on Pectra Devnet 4 specifications, is stable and there were no new updates reported about the network’s health. Stokes mentioned that the testnet recently underwent a block gas limit increase from 30m to 36m gas and no network disruptions have been reported since.
Pectra Devnet 5
Developers are still finalizing specifications for the launch of a new Pectra devnet, Devnet 5. Stokes confirmed a minor renaming to the “PendingPartialWithdrawal.index” field in the consensus specifications so that the naming convention is aligned with other fields related to validator withdrawals. Then, Stokes raised a proposal by Erigon developer Giulio Rebuffo to increase the “GOSSIP_MAX_SIZE” value in consensus specifications from 10 to 15 mebibyte (MiB). This would allow validators to safely increase the block gas limit on the EL from 30m to 60m gas.
EF DevOps Engineer Barnabas Busa said that any change to the gossip limit should be done at a hard fork to ensure consistency across all clients. Otherwise, there could be issues with consensus failures if clients had different values. Besu developer Paul Harris noted that to some extent the variation among clients is “already happening” and what is needed now is consistency moving forward on a plan regarding the gossip limit. EF Researcher Dankrad Feist stressed the urgency of the situation, calling the discrepancy in the gossip limit across clients “a bug”. He said, “I think that we need to make sure that there's no consensus failures due to this limit. This should just be treated as a bug, and we should fix that right now and then independently we can raise that limit. There should be no case where raising the gas limit leads to a consensus failure.”
Stokes noted that changes to gas costs in Pectra like EIP 7623, which increases calldata costs and limits the maximum size of an EL block, will alleviate gossip limit issues. However, until Pectra is activated on mainnet, aggressive increases to the block gas limit, such as a doubling, could cause networking issues on Ethereum. As background, changes to the block gas limit are controlled by validator node operators and in recent weeks, prominent Ethereum community figureheads have called for a doubling to the block gas limit.
Busa proposed in the Zoom chat removing the ability for validators to change the block gas limit. Another solution raised on the call was to update the gossip limit such that it is a function of the gas limit to prevent cases where increases to the gas limit on the EL cannot be supported by the gossip limit on the CL.
There was a lack of consensus among developers about what to do and concerns that the implementation of any long-term solution would require deep changes in both EL and CL clients, which could further delay Pectra. So, Stokes recommended that CL clients stick with conforming to current specifications for the gossip limit at 10MiB. “First off, CLs should double check that they follow the spec as written today, correctly, if not definitely, they need to send out updates. That one's straightforward. Then, it sounds like what we want to do is take a little more time to think about what the nice solution here is with respect to the gossip limit and the gas limit,” said Stokes.
He added that CL team should stay vigilant about increases to the block gas limit between now and Pectra activation and if needed, increase the gossip limit as a “nuclear option” if validators do decide to double the block gas limit without regard to the current gossip limit of 10MiB.
EIP 7742
Developers agreed to remove EIP 7742, uncouple blob count between CL and EL, from Pectra and instead implement a doubling to the blob count in Pectra through a change to the genesis configuration in clients. EIP 7742 would have required that the blob target and max values be dynamically sent from the CL to the EL through the Engine API. Upon closer inspection of this EIP, developers have noticed a few complications in implementation. One includes the fact that the EIP currently only uses the target blob count of the current block when in fact the target blob count of the parent block is needed for the excess blob gas computation. Other changes to the EIP needed are listed in more detail on this GitHub page.
Rather than deal with the implementation complexity of EIP 7742 and delay Pectra further, most developers on the call were in favor of removing the EIP and instead changing the genesis configuration. This would mean that blob count values can be updated in Pectra but that future changes to blob count still require updates to both the CL and EL.
EF Researcher Dankrad Feist was the only person on the call who strongly argued against this decision. Regarding blob count values, he said, “I think it's crazy to have this in both clients and keep this as something that has to be kept in sync between the two. To me, that's tech debt, and we should eliminate it.”
Geth developer “Lightclient” pushed back on Feist’s comments, arguing that the dependencies between the EL and CL go much deeper than considerations about the blob count. “I just don't think these things are in pure isolation, like bumping this constant on the CL for the gossip max size. This is not something that you could just mindlessly do, just as you can't mindlessly increase the blob limit with respect to the transaction pool on the execution layer. So, I think the conversation is just always going to have to go both ways. There's always going to be discussion about the safety of doing these things. Has the other side implemented the necessary protections to deal with this higher load?” said Lightclient.
Representatives from client teams like Geth, Reth, Prysm, and Nimbus all affirmed that removing EIP 7742 would not require much work. Stokes asked the group again if there were strong opposition to removing EIP 7742 in Pectra and reconsidering it for future upgrades. No further opposition was voiced on the call.
EIP 7251
There were a few updates to the design of EIP 7251, increasing maximum effective balance, shared on the call. The first addresses an edge case where a validator node operator could trigger consolidations for validators it does not control. Stokes reiterated that the changes to prevent this edge case from happening will be finalized over the next few days and feedback on it should be shared post haste asynchronously from the call.
The second update to EIP 7251 fixes an oversight in the validator selection process for signing block headers and proposing blocks. Stokes called in a “more invasive” change than the first one and recommended that CL client teams review it as the intention is to include it in Pectra Devnet 5 specifications.
EIP 7762
EF Researcher Ansgar Dietrichs highlighted a few takeaways from the latest RollCall meeting, a meeting series organized by the Ethereum Foundation to encourage coordination and communication between EVM-like Layer-2s. One of the takeaways was that EIP 7762, increasing the minimum blob base fee, should indeed be left out of the Pectra upgrade, as decided last week on ACDE #201. About EIP 7762, Dietrichs said, “On RollCall, we talked about it, and it seems like basically, rollups have been able to work around this for now. So actually, it is lower urgency than I had [thought]. So, with that feedback in mind, and given that, we said last week to only include it if really there was a strong case for it, it seems to me like that the best thing to do here is to just go ahead without it for Pectra.”
EIP 2537
The repricing model for EIP 2537, BLS precompiles, is nearing competition. Nethermind developer Marek Moraczyński presented 3 GitHub pull requests with the latest numbers. He noted there is still some discussion on the gas pricing for MSM operations but that final benchmarking for these operations would be completed by next week’s ACD call.
Given all the remaining updates to Pectra Devnet 5 specifications, Stokes asked client teams what a realistic timeline would be for the next devnet launch. EF DevOps Engineer Parithosh Jayanthi urged client teams to get their local configurations up and ready to run through Hive tests. Based on the number of clients that pass Hive tests, Jayanthi said, “If there are enough clients ready, I think I'm happy to launch the devnet between Christmas and New Year's.” Stokes agreed to aim to get Devnet 5 running as soon as client teams are ready.
PeerDAS
Stokes highlighted a pull request (PR) from EF Researcher Justin Traglia to rename EIP 7549, PeerDAS, specifications as “Fulu” specifications. Fulu is the name of the next CL upgrade after Electra. The renaming of EIP 7549 to Fulu further solidifies developers’ intention to ship PeerDAS in the next upgrade after Pectra. Stokes said that the PR from Traglia would be merged if there were no objections from client teams.
EIP 7723
EF Protocol Support Lead Tim Beiko shared a proposal to update EIP 7723. This EIP is not a change to the core protocol of Ethereum. It is a document that provides an overview of the various stages that an EIP impacting the Ethereum protocol must go through before their activation in a network-wide upgrade. Beiko recommended that EIPs labelled as “Considered for Inclusion” or CFI should be considered as EIPs that developers plan on including in a devnet, any future devnet, for an upgrade. Secondly, EIPs labelled as “Scheduled for Inclusion” or SFI should be considered as EIPs that developers plan on including in the next immediate devnet for an upgrade. “The rationale here is that this could help us sort of throttle how many things we bring in at once [on a devnet],” said Beiko, adding, “So, if we say we're putting 10 things to SFI, we should be saying in the next devnet we want to implement those 10 things, and if we think that's too much, then we have to pick which subset do we actually want to put in the next devnet?”
Beiko said that he will move forward with finalizing this change in EIP 7723 by next week unless there is comment or pushback about it.
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.