ACDE #215: Call Minutes
The call where developers agreed to pick the Glamsterdam headliner by Aug 14
Good evening,
Today, developers made headway in their efforts to finalize the Fusaka upgrade.
However, due to outstanding issues regarding Fusaka specifications, as well as new bugs that have not been fully resolved in clients on Fusaka Devnet-2, they were not ready to discuss plans for Fusaka Devnet-3.
Instead, they confirmed a schedule for planning the fork after Fusaka, called Glamsterdam. Developers agreed to choose a headliner feature for Glamsterdam by August 14.
Below is my full call summary for All Core Developers Execution Call (ACDE) #215.
Yours truly,
Christine D. Kim
🛎️ Programming note: I am seeking a sponsor for this weekly free edition of the ACD After Hours newsletter. If you're advancing Ethereum’s technical roadmap, client development, or protocol research, and would like to promote your work with a diverse and engaged audience of Ethereum stakeholders, please reply to this email. Thank you!
Key Decisions & Announcements
(For background on the ACD process and jargon used on these calls, refer to the Ethereum Governance 101 document in the ACD Toolkit.)
Fusaka Devnet-2
Several clients are experiencing syncing and peering issues on Fusaka Devnet-2.
Representatives from the Besu, Reth, and Prysm teams said fixes for their clients are close to being or are already resolved.
Fusaka Specifications
Developers are strongly leaning towards adding EIP 7910, eth_config JSON-RPC method, to Fusaka so that they can easily verify the runtime configurations for clients in lead-up to a hard fork upgrade. They agreed to discuss this EIP on next Monday’s All Core Developers Testing (ACDT) call.
Developers agreed to the following three changes to EIP 7907, contract code size limit increase:
PR 9910 – Reduce the code size limit, increase the cost per word, and fix the EXTCODESIZE issue.
CODESIZE Warm Read Removal (Draft) – Remove the warm read cost for CODESIZE.
PR 9955 – Account for large contracts at transaction entry.
They also reconfirmed that the “maxBlobsPerTx” parameter in EIP 7892, blob parameter only (BPO) hard forks, should be moved to EIP 7594, peer data availability sampling (PeerDAS), set to a constant of 6, and made only updateable through regular Ethereum hard forks.
They agreed to triple the cost of the “ModExp” precompile in EIP 7883, ModExp gas cost increase, out of an abundance of caution for future block gas limit increases.
They agreed to double the cost of the “secp256r1” precompile in EIP 7951, precompile for secp256r1 curve support, also out of an abundance of caution and lack of appropriate benchmarking analysis for more precise pricing estimations.
Glamsterdam
Tim Beiko, the chair of today’s ACD call, reminded developers that the deadline for Glamsterdam headliner proposals has passed.
He suggested that developers utilize the ACDE calls scheduled on July 31 and August 14 to decide on the headliners EIPs for the next Ethereum upgrade.
He added that once the headliner(s) have been chosen, developers can move on to discussing the inclusion of other EIPs for Glamsterdam. No deadline has been set for proposing non-headliner EIPs for Glamsterdam.
EIPs that were previously considered for inclusion (CFI’d) for Glamsterdam will be either withdrawn or re-proposed for inclusion in Glamsterdam.
History expiry
Geth developer Matt Garnett requested feedback on a new standardized file format, called EraE, for nodes serving expired history data. He requested feedback by the end of the month.
Garnett also said a blog post by the Ethereum Foundation would be published this week or next announcing the expiry of pre-Merge history data in some clients as a default setting.
Notable Discussion
(Quotes featured in this section may be edited slightly for grammar and clarity. For more information on the people quoted in this section, refer to the ACD Call Directory in the ACD Toolkit.)
Rapid fire decision-making
Several decisions about final Fusaka specifications were made on ACDE #215.
First, developers agreed to strongly consider the addition of EIP 7910 in Fusaka as a way to verify the correctness of client fork configurations.
Ethereum Foundation (EF) Developer Operations Engineer Barnabas Busa said about this EIP:
“I really want this to be included to be honest because we need to verify if the config[uration] is correct and I don’t understand how this was not there before. … All clients should use the same format.”
Developers also agreed to multiple changes in EIP 7907 that would limit the impacts of the code change considerably and reduce the need for further benchmarking analysis on the EIP.
Speaking to the rationale for changing EIP 7907, Reth developer Dragan Rakita said:
“It’s mostly to side with caution. A 10 times increase in the contract size seems too much and with this EIP [changes] we are doubling it and preparing to work for further increases in future hard forks.”
Third, developers said they would also err on the side of caution and reprice the gas cost of two EIPs in Fusaka, EIP 7883 and 7951.
About the decision to triple the cost of EIP 7883, EF Researcher Ansgar Dietrichs said in the Zoom chat:
“The downside here is super asymmetric. If we raise cost 3x, we slightly inconvenience a small % of users. If we don't raise cost, we risk not being able to deliver meaningful extra throughput to all users of the chain. Seems like a super clear cut case, even if we are unsure whether that 3x price is necessary.”
Erigon developer Milen Filatov said his team is conducting further investigation on the pricing for EIP 7883 and suggested a few more days for further discussion on the code change.
The majority of developers were in favor of moving forward with the 3x increase to the cost of the ModExp precompile and including this for testing on Fusaka Devnet-3.
On the repricing for EIP 7951, Geth developer Marius van der Wijden said:
“The last benchmark we did, it felt like it was also underpriced compared to other precompiles and that we should also consider repricing it. The number we kind of looked at was 2x the price but I have low context on this as well.”
No other developers had additional context or data to offer about the correct pricing for the secp256r1 curve precompile.
To avoid further delays to Fusaka, Dietrichs recommended moving forward with the repricing to EIP 7951 as well:
“If we don’t have more data on this, we should just 2x.”
Next steps for history expiry
History expiry refers the removal of old block and transaction data from computers, also called nodes, connecting to Ethereum. Up until recently, Ethereum clients by default did not prune any historical data from nodes. However, as discussed on ACDT #40, clients can now safely drop historical data prior to the Merge upgrade and thereby free up hard disk space for their users.
Geth developer Matt Garnett shared that the Ethereum Foundation will soon release a blog post announcing the rollout of history expiry in clients. He also mentioned that the goal is to make it possible for nodes to regularly prune historical block and transaction data.
However, in order to support history expiry on a rolling basis in clients, client teams have to agree on a standardized file format that nodes can use to retain data from expired history that is still needed for syncing. Garnett presented his ideas for this format called, “EraE.” He said:
“EraE is kind of the one thing in our way from really going from pre-merge history expiry to expiry up to the Cancun hard fork . That's kind of why I'm like trying to get feedback on this and iterate on this pretty quickly. … The faster that we can get EraE sorted out, the faster we can generate the files, and the faster we can get people to store these files, and the faster we can begin expiring history post-merge.”
Garnett said he would like to reach consensus on EraE by the end of the month. He encouraged developers on the call to reach out to him directly or share comments about EraE in the “history-expiry” channel on the Ethereum R&D Discord.
🌻That’s all for my summary on ACDE #215. You are officially caught up on the state of Ethereum protocol development and governance. Stay tuned for my insights on the call coming out tomorrow.
🌻New to the ACD calls and want to learn how to engage in them yourself? Check out the ACD Toolkit. It contains evergreen resources and materials that teach you the fundamentals of contributing to the evolution of Ethereum like a pro:
🌻I also offer professional consultations on Ethereum protocol development and governance. If you’d like to book a meeting with me to get tailored insights into the evolution of Ethereum for your business or portfolio, please use my Calendly scheduling page:
Below are links for further reading on the topics discussed on ACDE #215:
Forkcast: Ethereum Upgrade Tracker (Website, Ethereum Foundation Protocol Support Team)
An Ethereum Foundation Researcher’s perspective on slot restructuring in Glamsterdam (X post, Toni Wahrstatter)
New Besu client release with history expiry enabled by default (X post, Hyperledger Besu)
A Nethermind developer’s benchmarking analysis on EIP 7883 (Google Slides, Marcin Sobczak)
Here’s what’s coming up next week on the Ethereum Protocol Call Calendar:
Monday July 7
12:00 UTC/8:00 ET, Eth Simulate Implementors Meeting #56 (Meeting link shared on Telegram)
14:00 UTC/10:00 ET, All Core Developers Testing Call #43 (Meeting link shared on Discord)
15:00 UTC/11:00 ET, RPC Standards Call #8 (Meeting link shared on Discord)
Tuesday July 8
16:00 UTC/12:00 ET, EIP Editing Office Hour #64 (Meeting link shared on Discord)
Wednesday July 9
14:00 UTC/10:00 ET, Protocol Research Call #3 (Meeting link shared on Discord)
14:00 UTC/10:00 ET, Rollcall #13 (Meeting link shared on Discord)
15:00 UTC/11:00 ET, L2 Interop Working Group Call #11 (Meeting link shared on Telegram)
Thursday July 10
14:00 UTC/10:00 ET, All Core Developers Consensus Call #160 (Meeting link shared on Discord)
Friday July 11
No calls scheduled on this day.
📅 Call days and times may be subject to change so please utilize the links shared above to reconfirm meeting details day of. For a comprehensive overview of all recurring calls and meetings on the Ethereum Protocol Call calendar, refer to this post in the ACD Toolkit.📅
🙂 Thank you for reading another edition of ACD After Hours! If you like what you read today, consider sharing it with a friend who might also enjoy the content.
🤔If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.
🥳 Finally, if you’re a premium subscriber, don’t forget to join the subscriber chat. It’s an exclusive space to discuss and debate the future of Ethereum with me and other fellow ACD After Hours readers.
Newsletter credits:
Special thanks to Shinhye Kim for the graphics in this newsletter.