Ethereum All Core Developers Consensus Call #144 Writeup
On October 17, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #144. 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. This week, the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes.
Developers agreed to include a new code change in Pectra, EIP 7742, which enables the Beacon Chain to dynamically set the network’s target and maximum blob gas limit. The inclusion of EIP 7742 suggests that developers will also likely include an increase to the target and max blob gas limit in Pectra. However, some developers on the call raised concerns about how the inclusion of additional EIPs, especially EIP 7742, would delay the activation of other Pectra code changes on mainnet.
Developers also discussed testing progress on Pectra and PeerDAS devnets.
Pectra Devnet 3 & 4 Updates
EF Developer Operations Engineer Barnabas Busa said that he plans on shutting off Pectra Devnet 3 imminently and asked if any client teams still needed the devnet for testing purposes. Busa noted that there is an issue with block proposals in the Grandine client that has not yet been resolved on Devnet 3. Busa said that he would troubleshoot this issue with Grandine developer Saulius Grigaitis off the call before shutting down the devnet.
Regarding the launch of Pectra Devnet 4, Busa said that he would like to see one more execution layer (EL) client passing local Kurtosis tests to kick-start the new test network. So far, Busa said the Geth and Ethereum JS clients are ready to go, as are the Lighthouse, Teku, and Nimbus clients on the CL side. Stokes recommended that client teams aim to launch Devnet 4 by tomorrow, October 18.
Then, developers moved on to discuss a few open issues related to Pectra code specifications.
Pectra Code Specifications
Consensus Specs, PR#3900: As discussed last week on ACDE #198, developers refrained from including additional changes to EIP 7549 in Pectra Devnet 4. They discussed whether these should be considered for inclusion in a future devnet. However, the consensus on the call was to exclude these changes from the upgrade due to implementation complexity. Stokes said that he would follow up directly with the author of the issue to ensure that they are okay with this decision.
Consensus Specs, PR#3767: Similarly, developers also leaned towards excluding other major changes to the networking layer of Ethereum, as defined by PR #3767. Teku developer Enrico del Fante noted that the changes are too large to include in Pectra this late in the upgrade planning process. Prysm developer Terence Tsao agreed. Stokes said that he would follow up directly with the author of the issue to ensure that they are okay with this decision.
Consensus Specs, PR#3979: Teku developer Mikhail Kalinin encouraged developers on the call to review a bug fix proposed for EIP 7251.
Builder Specs, PR #104: Developers agreed to work on adding SSZ support to the builder API when handling execution layer triggerable requests such as validator deposits, withdrawals, and consolidations. Stokes said that he would speak with the MEV-Boost team and other MEV stakeholders to ensure that SSZ support is implemented across the entire MEV tech stack.
Kalinin raised breaking changes in Pectra that could impact application developers. Further context on this issue is explained in this GitHub comment.
BLS precompile repricing: Developers conducted a breakout meeting on October 14 on the topic of pricing BLS precompiles in EIP 2537. There remain questions about the optimal way to structure the inputs for each precompile. Stokes asked that developers and other stakeholders on the call chime in with any thoughts or recommendations on this matter.
PeerDAS & Blob Scaling Discussion
CL client teams are implementing a new Engine API specification aimed at helping users that propose blocks locally, that is without the use of a third-party builder and MEV relay, include blob transactions in their blocks. The Engine API specification is called the “engine_getBlobsV1” method and Tsao shared takeaways from Prysm’s implementation of it on the call. His takeaways are also summarized in written form on HackMD. Both Tsao and del Fante noted that the method does reduce node download bandwidth, as nodes receive blobs faster, but node upload bandwidth increases, because the node is now servicing other nodes over the P2P network with more blob data. Developers discussed various methods to address this issue and agreed to continue working on optimizations to the implementation of engine_getBlobsV1 asynchronously.
Next, developers discussed rebasing PeerDAS specifications so far on top of Pectra specifications. Representatives of the Lighthouse, Nimbus, and Teku client teams said they were in favor of this change. Busa said the current PeerDAS specifications which are based on top of the latest Ethereum upgrade, Deneb, are not stable, and therefore, rebasing these specifications on top of Pectra will make debugging and testing the code changes more difficult. Even so, Stokes said that developers should lean towards moving forward with the rebase. Stokes said that he would reach out to other CL client teams not represented on today’s call to ensure they are okay with this decision.
Thirdly, Francis Li, a developer for the Layer-2 rollup Base, gave a presentation on the urgency and rationale behind including an increase to blob capacity in Pectra. Li’s full presentation is also publicly available in written form on Google Docs. Li recommended increasing the blob gas target to 5 and max to 8, along with additional work on the networking layer, such as the implementation of engine_getBlobsV1. Developers discussed whether they could commit to including a blob capacity increase in Pectra on this week’s call.
Busa noted that an increase in blob capacity should be coupled with the implementation of EIP 7742, which introduces a mechanism to dynamically set blob gas targets and max limits through the CL. Busa said that the current mechanisms for setting these parameters are difficult to change and introducing EIP 7742 would ensure that developers can easily adjust these settings in the future, for example, for an upgrade like PeerDAS. However, Busa also noted that EIP 7742 requires additional work from both EL and CL client teams to implement and could push back the timeline for Pectra by 1 to 2 months. He urged developers to consider starting the work for implementing EIP 7742 sooner rather than later to avoid unnecessary delay to the Pectra upgrade. Stokes recommended revisiting this discussion on the next ACD call. EF Researcher Ansgar Dietrich pushed back on this and encouraged developers to make a decision about EIP 7742 and a blob increase on the current call. Stokes said that developers should focus on plans to launch Pectra Devnet 4.
After further discussion, Stokes relented and asked if there were any developers on the call that would be opposed to implementing EIP 7742 for Pectra and including it in the next Pectra Devnet, Pectra Devnet 5. There were no objections. Stokes said that he would raise this decision again for the group to discuss on the next ACD call, which will have a greater focus on EL-related protocol changes.
EIP 7782 & 7783 Update
On the last ACD call, ACDE #198, there were two new EIPs proposed for inclusion in the Pectra upgrade, EIP 7782 and 7783. They were presented as alternative ways to scale Ethereum without any changes to blob capacity. Erigon developer Giulio Rebuffo reiterated that his proposal, EIP 7783, does not require a hard fork and would introduce a mechanism to increase the block gas limit gradually, instead of in a cliff-like manner. Nethermind developer Ben Adams said that EIP 7782 is a proposal to scale Ethereum both in terms of blob and block capacity by reducing slot times. Adams asked CL client teams how difficult changes to the slot time would be to implement.
Rebuffo pushed back on Adams’ proposal, saying that the EIP would increase node bandwidth requirements and complicate research toward single-slot finality. EF Researcher Francesco D’Amato agreed that developers should be wary about changes to the slot time due to their impact on active research initiatives such as enshrined propose builder separation (ePBS) and inclusion lists (ILs). D’Amato said, “One thing that might not be obvious is just how much it kind of has the potential to get in the way of future changes to the CL which there might be things that we haven't agreed on. There might be things that we haven't even talked about on ACD because they're just research at this point. There's just a whole bunch of things that we might potentially want to do in the future from ePBS to ILs to other stuff that do interact with the structure of the slot a lot.”
Stokes recommended continuing the discussion on changes to the slot time on the ETHMagicians forum.
Finally, developers agreed to cancel the ACDC call scheduled for Thursday, November 14, as most developers will be attending the annual Ethereum conference, Devcon, in Bangkok, Thailand, during this week.
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.