Ethereum’s weekly All Core Developer calls are a lot to keep up with, so this “Checkpoint” series aims for high-level updates roughly every 4-5 weeks, depending on what’s happening in core development. See the previous update here.
tl;dr
Core developers are focused on getting Fusaka out the door and choosing the headline feature(s) for the following upgrade, Glamsterdam. Discussions are ongoing and stakeholder feedback is being solicited. Gas limit increases and history expiry have both been delivered!
Fusaka
Fusaka will deliver cheaper L2 transactions and more data availability. Developers were already fast-tracking the upgrade to ship PeerDAS and it’s now crunch time. They’re aiming for a release by end of year, which may not seem soon but the timeline is subject to a few key constraints: Devconnect in November and time buffers requested by the community and security teams. Because of these constraints one feature that wasn’t quite ready had to be dropped from the Fusaka scope.
Timeline
Two 30-day buffers have been built into the upgrade timeline since the Pectra upgrade:
- 30 days between client releases and the first testnet upgrade. This was requested by security teams, who need time to facilitate security reviews and audit competitions. With this buffer, we improve the chances of smooth testnet upgrades. When Holešky fell into an unfinalizing state with the Pectra testnet upgrade, app devs made it clear that, although these networks are purpose-made for testing, they themselves also rely on them to prepare their protocols for the upgrades and would like to minimize turbulence on them
- 30 days notice prior to the mainnet upgrade date. L2s and bridges have their own processes to go through to prepare for an ethereum upgrade that sometimes include their stakeholders voting to opt into it or triggering a time-locked process that cannot be sped up. This buffer affords protocols predictability in ethereum upgrades in order to be ready at the time of the upgrade instead of scrambling to be ready
In addition to this, the upgrade is run through multiple testnets (these days, two: Sepolia & Hoodi) that resemble the ethereum mainnet more closely than the devnets. Time is needed to evaluate the upgrade on these testnets, identify any issues, and coordinate final fixes. This typically takes a couple weeks per testnet.
EIP-7907
EIP-7907, which increases the contract code size limit and adds a gas metering to code loading, was removed from Fusaka because it lacked necessary benchmarking and risked delaying the Fusaka timeline. While simpler proposals to increase the codesize were put forward as alternatives, their timelines were unclear and still likely would have delayed Fusaka and so were rejected. This was a disappointment to many developers but, for those interested, there’s an opportunity to help get it into shape for the next upgrade, Glamsterdam. It is not currently guaranteed to be included and will need a champion to get it into shape.
Glamsterdam
A new, more organized process for determining the features of an upgrade is being piloted with this upgrade. The upgrade will first choose its ‘headlining feature(s)’, then select the other, small features based on the headliner(s). The intention is to choose a maximum of one headliner for the consensus layer and one for the execution layer. A new EF-built tool, Forkcast, is aiding this effort by accessibly presenting the headliner options and how they affect different categories of stakeholders.
To complement this, feedback is being solicited to ask the community to voice their opinions on what should headline this upgrade and these are being considered alongside client team perspectives.
Decision timeline
The options for both layers are being discussed until mid-August when a decision is expected to be made. The next upcoming calls are July 31st (consensus) and August 7th (execution). Once headliners are chosen, the timeline for smaller feature proposals that can go in alongside the larger headline features will be discussed. This is, for example, when an EIP-7907 champion would need to be coming to calls.
Gas limit
During Berlinterop, testing teams and clients found a safe level to recommend a gas limit increase to: 45M. Once the recommendation was made, it wasn’t long before enough operators had set their limits to 45M (or upgraded their clients with a new default). At the time of writing, the latest block’s gas limit is 45,043,901 gas. Testing teams are now on the path to figure out how to get us to progressively higher limits – there will no longer be years between gas limit increase recommendations.
source: gaslimit.pics
History expiry
History expiry has been delivered! Clients now default to dropping pre-merge history in validators. The next step for history expiry is implementing ‘rolling’ history expiry – meaning the date before which history is dropped will follow in realtime so that storage doesn’t continuously grow. Notes for the history expiry planning session at Berlinterop can be found here.
In order to get Fusaka released before Devconnect, clients need to cut releases by mid-to-late August and the testnet upgrades need to see minimal issues. That would place a mainnet upgrade in early November. If we hit snags, however, we lose a couple weeks and it’s somewhat unrealistic to expect core developers to be available during a very well-attended, large conference like Devconnect. We could see a post-Devconnect, pre-’holiday season’ upgrade (and we have in the past!). The motivation to get this fork out is high and I still expect to see it by the end of the year.
Glamsterdam headliner discussions have been amiably contentious – most of those advocating for a feature feel very strongly about its urgency. If we can ship Fusaka by the end of the year, it makes these conversations a bit softer because a faster upgrade cadence lessens urgency to get a feature inserted into the very next upgrade.
I’m very encouraged by the number and variety of ethereum community members that have chimed into the discussions: L2s, bridges, RPC providers, staking protocols, DAOs, relays, home stakers, custodians, DEXs, etc. are actively engaging in the process to shape the core protocol.
Relevant ACD calls:
[ June 16th – July 28th ]
- ACDT: #46, #45, #44, #43, #42, #41, #40
- ACDC: #161, #160, #159
- ACDE: #216, #215, #214
