Ethereum All Core Developers Execution Call #199 Writeup
On October 24, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #199. 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 #199, developers reconfirmed the decision to include EIP 7742 in Pectra as a pre-requisite for also including a blob capacity increase in the upgrade. They discussed the merits of doubling the block gas limit over a two year period after the Pectra upgrade through a change to the default settings of client software. This would not require a hard fork. Developers did not reach a decision about making such a change. They did agree to keeping the regular cadence of testing and ACD calls the week of November 18, which is the week following the Ethereum developer conference, Devcon.
Pectra Devnet 4 Updates
Developers launched Pectra Devnet 4 on Friday, October 18, 2024. EF Developer Operations Engineer Barnabas Busa said the following clients are experiencing issues on the new devnet: Erigon, EthereumJS, and Grandine. Pectra Devnet 3 has been shut down. Busa and his team will conduct further tests of clients on Devnet 4 in the coming weeks.
Then, developers discussed various specifications changes to Pectra that should be included for Pectra Devnet 5.
Pectra Devnet 5 Specifications Changes
The first were changes to the gas costs for EIP 2537, precompile for BLS12-381 curve operations. For months, developers have been debating the appropriate gas costs to price operations interacting with the BLS curve, a cryptographic signature scheme that will make signature aggregation and zero-knowledge proof generation more cost-effective on Ethereum.
A developer on the call with the screen name “Kev” explained that one of the outstanding issues about the EIP related to whether subgroup checks should be included in cost calculations has been resolved. He said due to potential dependencies related to the subgroup checks developers will keep these checks included in cost calculations. He added that he is concerned about the use cases for this EIP in practice among smart contract developers. “Some of [the app developers] have infrastructure that make it pretty hard to switch away from BM 254 to BLS 12-381 so I’m not sure what the use cases for this precompile are,” said Kev.
Another developer on the call by the name Paweł Bylica said that he does not think that a 2x increase across the board is a good proposal for accurately repricing BLS operations. Bylica recommended restarting the cost analysis from scratch and rebuilding a new “lookup table” for operations. Besu developer Gary Schulte agreed that there were some operations in the EIP that were already overpriced based on his benchmarking analysis so a 2x increase across the board would not be helpful. Developers agreed to redo the cost analysis and prepare final numbers for implementation and testing on Pectra Devnet 5. Beiko recommended using next Monday’s testing call to coordinate with client teams on the status of EIP 2537 repricing efforts.
Secondly, Geth developer Felix Lange presented one specification update to EIP 7685, general purpose execution layer requests, and a related change to the Engine API. Most developers on the call were in favor of these changes. However, Lange noted that he expected some pushback on them from consensus layer (CL) client teams as these changes may have an impact on their implementations of the EIP. Beiko said that based on the approval for the changes expressed thus far, they should be added for implementation on Pectra Devnet 5 for now. Busa said that these two have already been included to the required specifications list for Pectra Devnet 5.
Thirdly, a developer by the screen name “Frangio” shared changes to EIP 7702. He explained, “[EIP] 7702 currently introduces a new type of account that can change its code hash. … This is a strictly new kind of way of changing the code hash, because it can happen even if the code doesn't include self-destruct [and] even if the code doesn't include delegate call. So, it weakens the guarantees that one gets from looking at the code hash of an account. If a contract relies on [the code hash] to trust the way that the account is going to behave, it could be vulnerable, because it's able to temporarily masquerade as a different kind of contract.”
Based on feedback about the proposed changes to EIP 7702, Beiko recommended modifications to the proposal involving the use of a hard coded return value. Beiko said that once these modifications have been made and reviewed, the change should be included in the list of Pectra Devnet 5 specifications.
Last but not least, developers reconfirmed the decision from last Thursday’s ACDC call to include EIP 7742, uncouple blob count between CL and EL, in Pectra. Lodestar developer Gajinder Singh has raised a few concerns about the impact this EIP will have on block gas calculations for the EL. Developers agreed to discuss these concerns asynchronously on GitHub and Discord channels. Representatives from client teams including EthereumJS, Lodestar, Prysm, Besu, and Nethermind all shared that they have started work to implement EIP 7742 for Pectra Devnet 5.
Block Gas Limit Increase Debate
Before moving on to discussing Erigon developer Giulio Rebuffo’s proposal to increase the block gas limit from 30m to 60m gas, Beiko briefly mentioned a comment on this week’s call agenda by Ryan Berckmans, an Ethereum community member and investor. Berckmans has raised several questions related to defining and tracking the minimum bandwidth requirements for operating Ethereum validators. Beiko recommended that developers with thoughts on this matter chime in on the Ethereum Magicians thread.
Then, Rebuffo shared updates on EIP 7790, controlled gas limit increase guidelines, and 7783, add controlled gas target increase strategy. Rebuffo said that implementation work for EIP 7783 has been completed in the Reth, Erigon, and Geth clients. He added that the Nethermind team also plans on implementing EIP 7783. He shared his follow-up proposal to EIP 7783, which is numbered EIP 7790, to double the block gas limit gradually in a linear fashion over the course of 2 years. He said he gathered feedback on this proposal from several client teams and the majority have told him that they foresee no issue with the increase.
Nethermind developer Ben Adams wrote in the Zoom chat that he supports EIP 7790. Geth developer Marius van der Wijden was against the proposal saying the increase to 60m requires further research and testing. Others such as EF Researcher Toni Wahrstätter said developers should not increase the block gas capacity without first limiting the maximum block size through an increase to the cost of call data, as defined in EIP 7623. Geth developer “Lightclient” said that he would like to see progress on EIP 4444, history expiry, before implementation of EIP 7790. Rebuffo pushed back on many of the disagreements about EIP 7790 saying that the increase would be gradual over two years so there would be runway to implement EIP 4444, along with EIP 7623, after the activation of EIP 7790. Rebuffo added that unlike other EIPs aimed at improving scalability, EIP 7790 does not require a hard fork and so it would be easier to implement and coordinate across clients.
Based on the lack of consensus about EIP 7790, Beiko recommended tabling the discussion and continuing it asynchronously on other forums. At the end of the day, Beiko said a change to the block gas limit is not something that Ethereum protocol developers control and thus, it is not the highest priority for them to figure out.
Revert Error Codes for Contract Calls and November ACD Call Schedule
Then, Lange presented a case to add official revert error codes for contract calls to the Execution API. Lange said, “We have received this issue multiple times over the year that people have complained there's no standard way to get access to the revert data when accessing contracts using the eth_call, eth_estimategas, or eth_bidaccess operations. We would like to basically introduce the way we've been handling it in Geth as the official one. In Geth we have this error code, error code three, that we use for this purpose. The most important thing is just to have a defined error code and just basically ensure that all the clients behave same way.”
A few developers on the call expressed their support for Lange’s proposal. Beiko recommended continuing the conversation about it on other channels and moving forward with it assuming there is no further pushback on the matter.
Beiko recommended cancelling the ACD call on November 21, as it is scheduled to occur a week after the Ethereum developer conference, Devcon. Support for this recommendation was not unanimous among call participants. Van der Wijden, Busa, and others expressed that they would like to keep the call on the 21.
Beiko wrote in a post-call summary of ACDE #199 that developers would keep the call on November 21 but cancel the Monday testing calls on November 11 and 18.
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.