Ethereum All Core Developers Execution Call #197 Writeup
On September 26, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #197. This week, the call was chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum.
On ACDE #197, developers agreed to move forward with a limited scope for the Pectra upgrade and include only the 8 Ethereum Improvement Proposals (EIPs) live on Devnet 3 for now. They also agreed to potentially including a set of 4 EIPs related Ethereum’s blob fee market to Pectra later in the upgrade planning process.
As for the scope of the next Ethereum hard fork, Fusaka, Beiko confirmed that both PeerDAS and EOF EIPs would be included in this upgrade. He said that other EIPs may be included alongside PeerDAS and EOF in Fusaka but only after the implementations for these two are further along.
Finally, Beiko said that he would open a new EIP for the EL upgrade following Osaka, which is nicknamed Amsterdam, and carry over the EIPs, namely Verkle, that were originally considered for inclusion in Osaka to the new Amsterdam EIP.
Pectra Devnet 3 Updates
EF Developer Operations Engineer Parithosh Jayanthi reported that a fix to a Teku-Erigon bug has been deployed to Pectra Devnet 3. He also said that further investigation is needed on a Lighthouse state root mismatch issue and an issue with increased block propagation times during an influx of pending validator deposits.
On Monday, September 23, developers created 100,000 deposits on Devnet 3 to test the network’s capacity to handle influxes in deposit activity. A DevOps Engineer by the screen name “Philip” noted that the test led to “badly increased block propagation times” for unknown reasons. Teku developer Mikhail Kalinin is working on a change to consensus layer (CL) specifications to help address the issue. It remains unclear what the root cause of the issue is.
Jayanthi highlighted that his team is starting to plan the next Pectra devnet launch. He stated that the outstanding issues related to the MEV workflow should be addressed before the launch of Pectra Devnet 4 so that stakeholders in the MEV space, such as builders and relays, can start to test their operations on devnets. Jayanthi said aiming for the launch of Devnet 4 in two weeks would be a realistic goal for developers to target.
BLS MSM Benchmarks
Then, developers discussed repricing the BLS precompiles in EIP 2537. This was raised on the last ACDE call and further context for this discussion can be found here.
Beiko asked if client teams have had the opportunity to conduct their own benchmarking analysis on the BLS precompiles. Geth developer Jared Wasinger who had run the initial analysis reiterated that he is in favor of increasing the cost of these operations by 20%. Besu developer Gary Schulte said that his team had performed initial benchmarking tests on EIP 2537 and agreed that the precompiles are underpriced. Nethermind developer Marc Harvey also agreed with Wasinger’s proposal but added that his team has only completed a preliminary analysis, and further tests are still needed. Erigon developer Andrew Ashikhmin said that the benchmarking analysis completed by Wasinger should not differ greatly from any analysis done by Erigon given that the two software clients share the same code libraries and base implementation. A representative from the Reth team said that they have not yet had the time to investigate the matter of repricing EIP 2537.
Based on all the client feedback, Beiko recommended aiming to include the BLS repricing in Devnet 4. He asked Wasinger to create a formal PR for his suggestion and for other client teams to complete their benchmarking analysis by next week’s ACD call. Developers briefly discussed the standard hardware requirements that should be used to benchmark the costs for precompiles. However, it was clear there was no consensus on this matter.
Make Execution Requests a Sidecar
For the last several ACD calls, developers have weighed different proposals to simplify EL-triggerable requests such as validator withdrawals and consolidations to the CL. This week, Kalinin shared an updated proposal that would generalize these requests on the EL and pass them through for parsing on the CL. The proposal garnered widespread support among developers on the call. Geth developer Felix Lange said, “I think it's a great … proposal because it means that we [the EL] have to care even less about the request. In my previous proposal, we still had to know about the output size of the contract objects in order to be able to split it into lists. So, this is now also removed from the EL. Basically, it's just even less knowledge about the contracts.”
Other developers such as Prysm developer “Potuz”, Teku developer Enrico del Fante, Reth developer “Oliver”, Lodestar developer Gajinder Singh, Besu developer Daniel Lehrner, and Reth developer “Oliver” all supported the simplified approach proposed by Kalinin. Beiko and Jayanthi noted that this proposal would supersede prior proposals that had been made to simplify EL triggerable requests. Additionally, it would require updating aspects of EIP 6110, 7251, 7002, and 7685. Lange said that he would prioritize these updates over the next week and prepare them for implementation on Pectra Devnet 4.
Pectra Contract Audit RFP
Beiko noted that the EF is seeking third-party security audits of the smart contracts used by three EIPs in Pectra. As stated in the announcement post, “The audit should focus exclusively on the smart contract bytecode, referenced in the EIPs below. It should not encompass all of the EIPs, or client implementations of the EIPs, including their interactions with the contracts.”
Bids for these audits should be emailed to [email protected] with the subject line "Pectra System Contracts Bytecode Audit" by October 11, 2024. Additionally, the post states, “Proposals should include a summary of work to be performed, a timeline for completion of the audit, and a price for the engagement. … Accepted proposals will be confirmed by October 22, 2024 at the latest.”
Pectra Split
Then, developers discussed how to split the Pectra upgrade. This discussion was a continuation of the discussion that started last week on ACDC #142. Since last week’s call, several stakeholders have shared additional thoughts on the matter in writing. Below is a list of links to thoughts shared in writing by various client teams and individual developers.
Founder of Ethereum Vitalik Buterin spoke up in favor of including a blob capacity increase in Pectra. He said, “The reason why we need to think about this is because, realistically to me, it's just clear that scaling actual usage is just incredibly important. If Ethereum does not offer this, then people will find it elsewhere, and people are going to have insecure blockchain experiences that are just not on Ethereum. I would even argue that even a 33% blob [capacity] increase is probably more valuable than even three of the Pectra EIPs at this point. So, if you just look at the ratio of efforts to value, the amount of actual value here is quite high in terms of increasing the amount of activity that can happen.”
EF Researcher Dankrad Feist wrote in the chat that he is also strongly in favor of a blob capacity increase in Pectra. Others were not as supportive. However, many developers on the call agreed that if a change to the blob capacity is approved for Pectra, it should be coupled with other blob fee market related EIPs intended to ensure that blob pricing and block sizes remain stable. These additional blob-related EIPs include EIP 7762 (Increase MIN_BASE_FEE_PER_BLOB_GAS), EIP 7623 (Increase call data cost), and EIP 7742 (Uncouple blob count between CL and EL).
Alongside these conversations about what code changes to include in Pectra, Beiko confirmed that the next upgrade after Pectra would indeed be named Fusaka and will include both PeerDAS and EOF.
Pushing back on Buterin’s proposal, Potuz said it is too early to decide on whether to include a blob capacity increase in Pectra due to a lack of sufficient data about the impacts of such an increase on node performance. He said, “It’d be good to see a serious study that proves that this is safe, and then we'll support it. But without data, it seems that we're just changing numbers because we just came up with these numbers out of our heads.” Buterin responded saying that there is sufficient data on node performance since the Dencun upgrade and reiterated the urgency of increasing blob capacity for rollups in the case of rising blob gas fees.
Teku developer Enrico del Fante shared concerns about home stakers missing blocks post-Dencun due to insufficient bandwidth. Former Teku developer Ben Edgington added in the chat that his node at home also struggled to propose a block after the activation of EIP 4844. A developer for the rollup Base by the screen name Francis, who also proposed a blob capacity increase on last week’s ACDC call, chimed in to highlight the need for clearer definitions on what the minimum specifications should be for at home Ethereum stakers.
Based on the comments by del Fante, Edgington, and others, a Geth developer by the screen name “Lightclient” cautioned developers against including a blob capacity increase in Pectra. “We are already at capacity for some people, and increasing the target is going to put more people at capacity and beyond. So, I don't really know what data we can provide, since there's already data saying that we're kicking people off the network and are making it difficult for them to do their duties as a home validator,” he said. Lightclient suggested limiting the scope of Pectra to the EIPs on Devnet 3 and doing a data availability focused upgrade thereafter for rollups.
Potuz chimed in to say that developers could postpone a decision regarding the final scope of Pectra to a future call after more data-driven investigation on the impact of blobs on home stakers given that the changes to blob capacity are relatively simple and minor. Potuz asserted that the changes could be rolled out by client teams “in less than a day.” Jayanthi agreed with this sentiment and offered concrete next steps for developers to gather concrete data about the impact of blobs and increases to blob activity on nodes.
Based on the discussion, Beiko proposed moving forward with a limited scope for Pectra and deciding later the inclusion of the blob-related EIPs in the upgrade after further investigation by client teams. If the blob-related EIPs are not included in Pectra, Beiko recommended potentially including them in a separate upgrade before Fusaka. About Fusaka, Beiko stressed that developers should wait until both PeerDAS and EOF have been fully implemented on devnets before adding more EIPs to the Fusaka upgrade.
Beiko said, “As much as I would like to close the scope [on Fusaka] and say that we're going to commit these things and not have anything else, I think it's just an unrealistic thing to commit to. I think we can’t commit to making decisions about inclusions until we're actually ready to write more code and this [plan] maximizes how long we have to actually think about different proposals.” Developers did not discuss the inclusion of SSZ-related EIPs in a forthcoming upgrade. Geth Guillaume Ballet asked what the status of Verkle is given the new development roadmap for Pectra and Fusaka. Beiko said that realistically Verkle will not be included in Fusaka but will be considered for inclusion in the EL upgrade thereafter, nicknamed Amsterdam.
Lightclient asked when developers plan on freezing specifications for Pectra. Beiko recommending leaving roughly a month for developers to make a final decision on the blob-related EIPs. In the short term, developers agreed to aim for launching Pectra Devnet 4 before the next ACDE call in two weeks. To this end, Jayanthi encouraged developers to join the Pectra testing call on Mondays to surface any issues or discussion items related to Devnet 4 launch early.
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.