Ethereum All Core Developers Consensus Call #142 Writeup
On September 19, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #142. 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 debated the decision to split the Pectra upgrade across two hard forks. They also discussed outstanding issues related to the Ethereum Improvement Proposals (EIPs) on Pectra Devnet 3. Finally, a protocol developer for the Base rollup by the screen name “Francis” presented an analysis to support an increase in the blob gas target for the first part of the Pectra upgrade.
Pectra Devnet-3
Developers have started fuzzing Pectra Devnet 3. They are using a “bad block” generator created by Geth developer Marius van der Wijden. This activity has highlighted bugs in the Besu client, which the Besu team is currently working to fix.
Debating the Pectra Split
Before the call, Stokes and a few client teams shared their thoughts on the idea of splitting Pectra into two upgrades.
Stokes, who suggested the idea during last week’s ACDE call, wrote a post suggesting the idea to ship the first part of Pectra with only the eight EIPs live on Pectra Devnet 3. The second part of Pectra would contain the other 12 EIPs already approved for Pectra and potentially, a few additional EIPs.
Teku developer Lucas Saldanha was in favor of splitting Pectra with the addition of two SSZ-related code changes in either part of the upgrade.
An Erigon developer by the screen name “somnergy” expressed his team’s disapproval of splitting Pectra in the way suggested by Stokes. They instead proposed removing PeerDAS from the upgrade and making it a separate CL-only hard fork.
Erigon developer Andrew Ashikhmin reiterated that it was his team’s view Pectra should remain largely the same, except without the inclusion of PeerDAS. Ashikhmin stressed that developers’ priority after Pectra should remain focused on shipping the Verkle upgrade as soon as possible. In response, EF Researcher Ansgar Dietrichs wrote in the Zoom chat, “To me, there is no real urgency on Verkle – especially given the uncertainty on whether it even is the right way to go.”
Etan Kissling from Nimbus stated that he was in favor of splitting Pectra with the caveat that EIP 7688, forward compatible consensus data structures, should be added to the first part of the upgrade for the benefit of decentralized application developers, particularly staking pool teams like Rocketpool. Other call participants, primarily Stokes, expressed concerns about adding any new EIPs into Pectra 1 due to concerns that it would delay the first part of the upgrade. Mario Vega from the EF Testing team wrote in the Zoom chat, “We [are] also in favor of the split but we need to set a hard-limit on the scope at the time of the split.”
Prysm developer “Potuz” countered the idea of limiting the scope of Pectra 2. He said, “I don't agree with being strict on the scope and even if I did agree, I don't even trust that we would be strict on the scope. We set [out] to scope Pectra very early, a few months before we went to Kenya, and we were very clear that we wanted to have a very small fork, because it didn't need to delay Verkle. That was a commitment … and now we're trying to split it. If we were about to have this large fork, then we [the Prysm team] would have pushed for a very different set of the EIPs. So, I find it not only unfair, I find it just simply wrong to already be committed for the next two forks.”
Geth developer Marius van der Wijden supported splitting the upgrade, though he did not elaborate on how. Stokes reiterated in response to Kissling’s suggestion to include EIP 7688 in Pectra 1 that any additions to Pectra 1 would complicate the plan to split out the upgrade. Lighthouse developer Sean Anderson agreed with Stokes and said that adding EIP 7688 would delay Pectra 1. In the Zoom chat, developers continued to argue about the readiness of Verkle in comparison to the PeerDAS and EOF upgrades currently in Pectra.
Ashikhmin reiterated that in his view Pectra should remain largely the same with the PeerDAS related code changes split out into a CL-only hard fork. Stokes said EOF is less ready for mainnet implementation than the current 8 EIPs on Pectra Devnet 3. Thus, shipping Pectra without EOF would mean the 8 EIPs could make it to mainnet faster. He did not address the concern that this might mean Pectra 2 becomes a larger upgrade and the timeline for the Verkle transition becomes subsequently delayed.
Teku developer Enrico del Fante suggested adding EIP 7688 to Pectra 2. Dietrichs emphasized that in his opinion splitting Pectra only makes sense if Pectra 1 is scoped such that it has “the absolutely fastest time to mainnet.” During this discussion, Stokes reiterated what he thought should be the decision and tried to progress the conversation to discussing the scope of Pectra 2. He said, “What I'm hearing is that we're generally on board with Devnet 3 essentially moving on to be the next hard fork. Obviously, there are other things to consider, but I think that's the direction we should move in. I don't know if we want to then turn to talking about scoping the second fork.”
Despite Stokes’ efforts to force a decision and move on, developers continued to discuss the scope of Pectra 1. Nimbus developer “Arnetheduck” said that it was unreasonable for developers to push back the implementation of EIP 7688. Geth developer Guillaume Ballet said he did not understand the need for EIP 7688, let alone its urgency. Kissling jumped into re-explain the utility of the code change. Stokes then also stepped in again to reaffirm the decision to move forward with a limited scope for Pectra 1. He said, “The whole idea with the split is to ship the next hard fork as quickly as we can and what that means is we really should stick to a very strict scope. I think it's already going to be tricky to get to a spec freeze of the first Pectra in the next couple, say, month or two, like, next couple weeks, like, ASAP. … So yeah, I hear all that, [but] I would lean towards deferring [EIP 7688] to a later fork.” Lodestar developer Gajinder Singh wrote in the Zoom chat that he was in favor of including EIP 7688 in Pectra 1.
Another developer on the call with the screen name “Oliver” wrote, “I don’t see the point in splitting if we’re not going to freeze both ends,” emphasizing the need for a decision in his view on what will go into both Pectra 1 and 2. EF Protocol Support Lead Tim Beiko said that any new addition to Pectra 1 beyond the scope of the EIPs on Devnet 3 “invalidates” the reason for splitting Pectra in the first place, which is presumably speed of upgrade implementation.
Other participants on the call such as EF Researcher Toni Wahrstätter were in favor of Stokes’ proposal. Nethermind developer Ahmad Bitar said that if developers could not be strict with what is included in Pectra 1 and 2, developers should simply stick with shipping Pectra as one fork. Independent Ethereum protocol developer Danno Ferrin said for the split to be “worth it” the second half of Pectra needs to target a mainnet launch in Q3 2025. Lighthouse developer “EthDreamer” asked if developers on the call could commit to not including new EIPs in Pectra 1 and 2. Potuz responded no.
Concluding the Pectra Split Debate
There continued to be a lot of back and forth about the idea of splitting Pectra across two upgrades. The conversation also digressed to whether EOF should be considered for Pectra 2 ahead of Verkle implementation. Overall, the conversation highlighted concerns from developers working on various initiatives, namely PeerDAS, EOF, and Verkle, and their anxiety about not seeing these initiatives prioritized for the next Ethereum hard fork after Pectra 1. It was clear some developers view these initiatives in competition with each other for implementation in Pectra 2.
Additionally, it was clear that despite potential bandwidth to increase the scope of Pectra 1, assuming it would not include any of the three major initiatives, developers could not agree on what to add to Pectra 1 for fear of potentially creating yet another large fork. EF Developer Operations Engineer Parithosh Jayanthi said that he would like to make a proposal about how to change the way developers scope out Ethereum upgrades at the upcoming Ethereum developer conference, Devcon, in November.
EthDreamer asked if developers could commit to a timeline for figuring out the scope of Pectra 2. Stokes said this would be “tricky” given all the uncertainty about what initiatives should be prioritized for implementation on mainnet. Stokes also reiterated again that developers should split Pectra and stick with the scope of Pectra 1 as the EIPs on Devnet 3. He said, “I think there's very strong support to have the Devnet 3 plus polish idea be the Pectra fork, and then downstream we can figure out what comes next. Can we all agree to this?”
Pectra Spec Issues
Stokes moved on to raising a few issues related to Pectra code specifications as defined by the EIPs on Pectra Devnet 3. They included:
EIP 7251, Switch to compounding when consolidating with source==target: This pull request (PR) implements Stokes’ idea of changing how validator consolidation requests are processed by the CL validator to compounding credentials via consolidation request rather than depositing with the updated withdrawal credentials.
EIP 6110, Queue deposit requests and apply them during epoch processing: This PR created by Teku developer Mikhail Kalinin presents additional specification on how to queue validator deposit requests on the CL.
EIP 7549, Separate type for unaggregated network attestations and Separate type for onchain attestation aggregates: These PRs, the former proposed by Arnetheduck and the latter by Kalinin, offers modifications and additional specification to the new on-chain attestation format introduced by EIP 7549.
Engine API, Create a unified list of opaque requests: Updates the encoding of requests in EIP 7685 (General purpose execution layer requests), EIP 7002 (EL triggerable withdrawals), EIP 6110 (Supply validator deposits on chain), and EIP 7251 (Increase maximum effective balance) for easier processing by the EL client.
Other outstanding issues related to the Engine API, remote-signing-API, beacon-API, and MEV builder pipeline were briefly mentioned by Stokes during the call. He asked developers to carefully review these issues and chime in with feedback on them as soon as possible so that they can be merged and finalized into Pectra specifications.
Pectra Blob Increase
Base protocol developer Francis presented a proposal to include a blob increase to Pectra 1. Francis said, “Our main point here is about the blob capacity for the L2s in general. If we are putting PeerDAS into the next half [of the upgrade], which is nine to 12 months later, then we think that the current capacity, three target blobs [per block], will not be enough for L2s to scale in the coming months.” Francis recommended including either an increase to the target and max blob per block or an increase to the target blob per block only in Pectra 1. He then shared analysis on the impact of an increase to the target/max from 3/6 to 6/12 on node bandwidth requirements. The analysis can be found here.
Dietrichs noted that developers were more open to the idea of including a target only increase to blob capacity from 3/6 to 4/6, than a target and max increase, in Pectra 1. Stokes and Potuz agreed with this sentiment. EF Researcher Dankrad Feist asked about improvements client teams are making to the P2P networking layer that could improve node bandwidth requirements and further justify an increase to the blob capacity in Pectra 1. Client developers chimed in with their progress on implementing IDONTWANT messages, which help reduce the passing of duplicate messages across the network. Dietrichs asked if developers could decide on a blob capacity increase in Pectra 1 by the next ACDC call in two weeks. Stokes said in his view there needs to be more data about the impact of blob capacity increases to inform the discussion before a decision can be made.
Stokes closed the conversation by saying that it is an open question what a “safe” modification to blob parameters could look like in Pectra 1 in lieu of PeerDAS. He reiterated that he is in favor of minimally increasing the scope of Pectra 1 beyond what is already included in Devnet 3, so in his view, a modification to the blob gas target might be more appropriate. “We’ll definitely revisit [this topic] before Pectra hits mainnet,” said Stokes.
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.