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:

1. 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
2. 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

Ethereum’s weekly All Core Developer calls are a lot to keep up with, so this “Checkpoint” series aims for high-level updates depending on what’s happening in core development. See the previous update here.

This is a special edition of the series!

Kicking off Berlin Blockchain Week, ethereum core devs and researchers got together for an interop hacking week to make progress both on long-term research directions and short-term implementation of the Fusaka upgrade and gas limit increases. Two of these days solicited feedback on longer-term research directions from L2 and zk teams.

The most recent in-person interop was in Bangkok prior to Devconnect but previous interops focused on Pectra & PeerDAS (Nyota), Shapella & Protodanksharding (Edelweiss), the Merge (Amphora), and Eth2 (Ontario)

Short-term implementation

Fusaka

Last week’s interop, Forschungsingenieurtagung (or more practically referred to as Berlinterop), focused on an all-week coworking session where devs launched fusaka-devnet-1 on day 1 and berlinterop-devnet-2 on day 5. Throughout this hacking week, devs found changes that would be useful but could not include them in a canonical “fusaka-devnet-2” without consulting the public ACD governance process on these decisions, which they’ll do this Thursday.

Following this progress, devs will launch a fusaka-devnet-2 and, in an optimistic scenario, don’t expect to need a devnet-3 before moving onto the Sepolia testnet around the end of the (boreal) summer.

This week’s All Core Devs Testing call covered the Fusaka devnet timeline here.

Gas limit testing

In order to make way for the network to safely handle ambitious goals in gas limit increases, devs got together to identify and remove hurdles for throughput increases.

The week included a stress-testing challenge with a leaderboard where devs were awarded points for breaking or hardening devnets. Shout out to Kamil and pk910 for their invaluable participation!

They did indeed come to consensus on a safe immediate higher throughput level and a plan for higher levels, which will be shared from the EthPandaOps twitter account and in the Eth R&D discord when client optimizations that ensure the safety of the 45M throughput level are released within the next week.

This Mondays’s All Core Devs Testing call covered Berlinterop gas limit testing.

Long-term research directions

More detailed summaries and chronological notes from sessions related to all the following sections (and more!) will be posted in the coming weeks in the ethereum/pm Github repo.

Slot restructuring

Devs & researchers discussed two possibilities of slot restructuring: shortening slots and rebalancing the sub-slot timings. They also covered the interplay of various proposals that touch slot structure or are affected by it: ePBS, Delayed Execution, FOCIL.

The session then covered the benefits of shorter slot times: better markets with less stale data, makes big blocks smaller, more competitive builder markets, faster + cheaper interop, more leaders per second, higher censorship resistance.

Two action items that came out of this were to address open questions in this PR to prepare to merge and to adjust the language in specs so that clients must attest as soon as a block is validated and wait until the 4 second mark.

History expiry

There was encouraging progress on history expiry! Expect a blog post here in the next couple of weeks on how validators will default to dropping pre-merge history on mainnet

There was good agreement on Era file standards, and further updates will be provided in the next two months on rolling history expiry and on the implementation of a distribution mechanism for dropped history. There will be a public community call this coming Friday to discuss the future of Portal.

These updates were covered on this Monday’s All Core Devs Testing call.

CL hardening

Devs met to evaluate areas they’d like to improve to make the consensus layer more robust against disruptive situations like the Holešky Pectra fork and came out with 26 areas for improvement. These areas should be addressed in the next year or so and range from simpler items such as being able to checkpoint sync from a nonfinalized state to more complex ones such as how to optimize client resource usage during nonfinality periods.

These changes will help maintain a healthy network even in the case of nonfinality. Keep up with this progress in the #consensus-dev channel of the Eth R&D Discord server.

L2 day

Representatives from Arbitrum, Base, Linea, OP Labs, Polygon, Scroll, Soneium, Starkware, World Chain, and ZKsync provided feedback about optimizing the L1 <> L2 relationship going forward and helped to identify three areas of focus:

1. Requests from L2s as users of the L1: more blobs and faster finality
2. L2s as stakeholders in EVM changes: because EVM equivalence means that changes affect them, they’d like to be considered and kept in the loop to have time to prepare for any adjustments. Some specific focuses were calldata pricing and finding more extensibility points
3. L2s pointed out that they’ve accumulated a wealth of knowledge on running high-throughput networks and can be useful in collaborating on scaling designs on the L1

ZK day

Representatives from Brevis, Ethproofs, Irreducible, Kakarot, Linea, Lita, Matter Labs, OpenVM, powdr, RISC Zero, Scroll, Snarkify, Starkware, Succinct, Whirlaway, Zirkuit, Zisk, and ZKM collaborated on the path to a zkEVM future with various areas of focus:

1. Guest programs & primitives – Teams unanimously agreed that it was too early to enshrine any particular ISA. They favour sticking with a generic RISC-V target (riscv64gc-unknown-linux-elf). Nethermind wants a compilable execution layer guest and hopes to collaborate by EOY on the zkvm benchmarking framework they’ve been working on. Hash choice is still open-ended: No consensus on poseidon2 or a specific field.
2. Standardisation + security – supported standardizing around syscalls and shared Rust libraries that invoke precompiles. There was consensus that 300KB proof is reasonable and that groth16 wrapper could be dropped.
3. zk-stateless client roadmap – Year-end goal for a zk-verified stateless client (starting on Reth); biggest questions are censorship-resistant state sources and how to pay/align provers.

Summary

Interop weeks are enormously productive as they remove async-communication barriers and create contagious motivation among devs and researchers – a lot of things that have been taking months to make progress were given a big push this last week. Having in-person sessions with L2 and zk teams was also beneficial to orient ambitious research directions with wider stakeholder feedback.

As for current development… I’m beginning to think we really will see a 2025 Fusaka!

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:

Since the last Checkpoint, the Pectra upgrade shipped and core developers have maintained a heavy emphasis on keeping the next upgrade (Fusaka) lean to get PeerDAS, a scaling unlock, out the door. Fusaka testing is ongoing and developers are still optimistic about a 2025 release date. Proposals for the headlining feature of the upgrade following Fusaka (”Glamsterdam”, ~2026) are being solicited until June 20th.

Pectra

Pectra went without a hitch, delivering staking quality-of-life upgrades, a huge unlock for wallet UX, increased blobs, and more. Though Q1 testnet hiccups created a little more anxious anticipation than usual, the upgrade was smooth and all new features behaved as expected. It is now up to the app layer to take advantage of these feature unlocks for users – for staking providers to adopt maxEB, for wallet providers to support 7702, etc.

Fusaka

Fusaka’s headlining feature, PeerDAS, has been undergoing feature-specific testing since 2024 and recently concluded its seventh devnet. The first multi-feature Fusaka devnet launched last week and the next will go live during Berlin Blockchain Week.

The number of devnets required for thorough testing depends on a number of factors, like the number and complexity of the features and how easily they play together. This typically ranges from ~5-13 and each is usually very short-lived as each devnet adds or adjusts one or more features at a time. As devnets progress and features get implemented, you can watch these features move from the Considered status to the Scheduled status. Only when devnets have all features stable will the upgrade go live on a testnet.

Blob Parameter Only (BPO) fork testing is also ongoing! This will allow the number of blobs available to be adjusted outside of hard forks to enable faster scaling for L2s. As part of testing, blob counts are being adjusted up and down and the feature has been working as intended so far.

Gas limit testing is determining if a 60 million gas limit will be safe for Fusaka. Gas limit adjustments don’t require a hard fork and can be adjusted by validators independently, but commitments to testing their safety as part of an upgrade is helpful to getting higher defaults shipped in client software. Spoiler alert: 60m is looking good, even for home stakers.

Teams committed to upgrading the Sepolia testnet before the Hoodi testnet for Fusaka and going forward to preserve Hoodi as a critical app-testing environment prior to mainnet upgrades.

Glamsterdam

Glamsterdam conversation kicked off in ACDC #158 with two proposed headliners: ePBS & FOCIL. EIP champions made their case for these as the main features for the upgrade. Others have begun to make their cases as well. If you have an EIP that you think would be the best headliner for Glamsterdam, you can propose it using the proposal template in the EIPs category for discussion.

Timeline

• May 26 – Jun 20: Fork Focus Discussion & Headliner Proposals
• Jun 23 – July 17: Headliner Discussion & Finalization
• Jul 21 – Aug 21: Non-Headliner EIP Proposals
• Sep 4 – Sep 11: Non-Headliner EIP CFI Decisions

History Expiry

Besu has released history expiry on Sepolia with other clients soon to follow. History expiry is already experimentally available on mainnet with several clients but is user-configured instead of default. Once sufficiently tested by all clients on Sepolia, it will roll out in default software configurations. Progress can be followed in the #history-expiry channel in the Eth R&D Discord.

Process

A decision was made to move current upgrade testing conversation to Monday testing calls, now called All Core Devs Testing (ACDT), while Thursday calls should discuss future upgrade scoping. Upgrade process changes are ongoing and will likely see more reconfiguration during Berlin Blockchain Week sprints. All are invited to voice their opinions on Ethereum Magicians.

Core devs have remained truly intent on keeping Fusaka lean and have been aggressively rejecting anything that will slow its release down, which makes me hopeful for a 2025 Fusaka.

Old habits are hard to break and process changes are difficult to apply in decentralized governance – despite the decision to move Thursday calls to future fork scoping, we’ve had four calls since Pectra but only started discussing Glamsterdam in the last. To ship faster, we’ll need to stick well to the proposed Glamsterdam deadlines and figure out not just the processes that will make upgrades faster, but the process that people will actually use and stick to.

Fusaka development is on track though and if the goals are [ scale L1, scale blobs for L2, improve UX ] – we are certainly well on our way.

Relevant ACD calls

Now featuring ACDT(esting) calls as well!

02.06.25: ACDT #39 (EthMag)

29.05.25: ACDC #158 (EthMag)

26.05.25: ACDT #38 (EthMag)

22.05.25: ACDE #212 (EthMag)

19.05.25: ACDT #37 (EthMag)

15.05.25: ACDC #157 (EthMag)

12.05.25: ACDT #36 (EthMag)

08.05.25: ACDE #211 (EthMag)

01.05.25: ACDC #156 (EthMag)

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 calls, depending on what’s happening in core development. See the previous update here.

tl;dr:

The past month centered on locking in the scope of the Fusaka upgrade and final Pectra deployment details. The Pectra upgrade ships on mainnet in just about a week, after which focus will shift to Fusaka testing and deciding what goes into the Glamsterdam upgrade (in other words, the ”scope” of the upgrade). A new All Core Developer (”ACD”) call structure will split testing and scoping into separate calls to parallelize and accelerate shipping upgrades.

Pectra

Mainnet client releases are out for the Pectra upgrade and it’s scheduled to go live on May 7th.

Since the last Checkpoint, Pectra went live on ethereum’s newest long-lived testnet, Hoodi. It went well, much to the relief of client devs and testing teams who were cautious to celebrate too soon after bumpy Holešky and Sepolia upgrades.

In response to these bumpy upgrades, guardrails were established in the forms of process formalization, expected timelines between testnet upgrades and mainnet upgrade scheduling, incident response roles, and configuration standardization.

Pectra’s main features are summarized on the ethereum.org Pectra page and a watch party will follow the fork going live.

History expiry

History expiry allows clients to stop storing pre-Merge history, easing hardware and network requirements. This does not require a hard fork. Clients are set to support pre-Merge history expiry on the Sepolia network by May 1st. Mainnet support is expected shortly after Pectra on mainnet.

Long-term history will still be available through archive nodes and the Portal network and client implementations will allow a user to optionally disable pruning.

Fusaka

The headliner of the Fusaka hard fork is PeerDAS and the broad scope has been finalized.

Outside the headlining EIP,

Not all of the CFI’d EIPs will necessarily make it into the fork (two of them, 7762 & 7918, are either/or). They’ll be added into the testing pipeline and moved to SFI if their implementation progresses smoothly without introducing excessive complications. Fusaka fork testing will have a number of devnets, then fork on testnets, before being scheduled for mainnet. Shipping PeerDAS is paramount!

PeerDAS

PeerDAS lets nodes verify blobs by sampling instead of needing the full payload, making room in bandwidth and storage requirements for other upgrades. This makes way for scaling – cryptographically secure sampling techniques means that we can scale without sacrificing ethereum’s decentralized validator set. Testing is ongoing, just having concluded its sixth devnet, with the seventh set to launch this week. Testing has been a collaborative effort between client teams, Ethereum Foundation teams, L2 core devs, and network tooling researchers.

EOF

EOF is a multi-EIP upgrade to the EVM. Because of a significant divide on opinions on if (and what version of) EOF should be implemented, it was removed from the Fusaka scope during the 28 Apr EOF “final decision” discussion. It may yet be proposed for future upgrades.

Debate centered around its complexity, long-term relevance, and the potential to add its features piecemeal instead. Critics argue that it could double maintenance costs (legacy + EOF) and needs more review from app layer devs.

Supporters and implementers acknowledge its imperfections, but argue that it’s needed to pay down tech debt, increase security, unlock compiler & gas-efficiency gains, and establish a cleaner foundation for future EVM evolution.

BPO forks

The third EIP SFI’d for Fusaka is the Blob Parameter Only (BPO) forks. This would allow preconfigured blob scaling between hard forks. Blob increases would be baked into clients and happen on a pre-defined schedule while being monitored for issues. This EIP has broad support and plays a significant role in accelerating scalability.

Process improvements

Pectra has tested the limits of the current All Core Devs process – this upgrade is the biggest fork in ethereum’s history by number of EIPs, and was even larger before it was split into two: it originally contained PeerDAS and EOF!

To improve the efficiency of this process, changes are taking shape that:

• Better parallelize upgrades so that the upgrade two forks ahead is already being scoped before the current fork goes live (for example, if we had the process down right now, the Glamsterdam fork scope would be finalized while Pectra is in its last stages and Fusaka implementation is ongoing)
• Split regular calls into “all core devs” testing and “all core devs” scoping. Testing calls would cover the current fork and scoping calls would deal with CFI’ing EIPs for the next fork
• Create a new call series that discusses longer-term goals and guides research directions. Ideally, this would lead to more agreement and less debate by the time scoping and then testing is ongoing.

Core devs are ambitiously targeting to fork to Fusaka, which focuses on scaling, by the end of 2025: doable but difficult. In my opinion, if it doesn’t ship by a few weeks prior to Devconnect, it won’t ship until February 2026 because of momentum lost over the holidays, so a “by EOY 2025” delivery would be by October.

The new process of splitting the ACD calls does seem promising to keep conversations on topic, bring in new voices, and minimize the problem of revisiting old conversations so calls aren’t bogged down by debates around scoping as has been the case with EOF. It also may mitigate any tendency to conflate short-term implementation plans with long-term research directions.

Despite some doom & gloom chatter in wider crypto circles, there’s a ton of momentum in ethereum core protocol development. The process is evolving, research is strong, and implementation is speeding up!

Relevant ACD calls

28.04.25: EOF discussion (timestamped)

24.04.25: ACDE #210 (EthMag)

17.04.25: ACDC #155 (EthMag)

10.04.25: ACDE #209 (EthMag)

03.04.25: ACDC #154 (EthMag)

27.03.25: ACDE #208 (EthMag)