“`html
Ethereum’s weekly All Core Developer meetings are quite demanding to monitor, thus this “Checkpoint” series aims to provide overarching updates approximately every 4-6 weeks, contingent upon core development activities. Refer to the preceding update here.
If you’re interested in core development updates, you might also be eager to know that Forkcast now offers summaries, discussions, and transcripts for each All Core Devs meeting, typically accessible within a few hours post-call.
tl;dr:
The Fusaka upgrade is almost upon us, Glamsterdam is gaining momentum, with its primary features in development and minor aspects currently being determined. Discussions regarding the Heka / Bogotá upgrade will commence shortly.
If you wish to contribute your thoughts on which minor elements to incorporate into Glamsterdam, now is the opportunity. There’s still no consensus on whether the anti-censorship transaction feature (FOCIL) will be included or postponed to a subsequent upgrade. If you possess a significant feature you’d like to suggest for Ethereum, you should begin assembling your headliner proposal for the Heka / Bogotá upgrade debate, expected to commence in early 2026.
It’s Devconnect week! A slower-than-usual pace for the next two weeks is anticipated. Conversely, face-to-face discussions could enhance decisiveness in Glamsterdam resolutions.
Fusaka
The testing for this forthcoming upgrade has concluded, with Fusaka and both BPO forks successfully deployed on all three main testnets with minimal issues. In historical context, the testnet fork processes were significantly smoother than is typically observed with these Ethereum upgrades. Although some clients are still experiencing minor concerns, they are not consensus-critical and, hence, will not hinder the upgrade.
Fusaka is set to launch on December 3rd at 21:49 UTC & a viewing party will broadcast from the Ethereum Protocol YouTube channel. Node operators must perform updates before that time to ensure compatibility with the network post-upgrade. A summary of its features can be located in the mainnet announcement blog post and on ethereum.org.
Timeline
A reminder for node operators: the Fusaka-ready client releases include configurations for all three of the following forks. Only one update is necessary to appropriately follow the upgrades.
| Event | Time (UTC) | Target blobs | Max blobs |
|---|---|---|---|
| Fusaka mainnet | 2025-12-03 21:49 | 6 (unchanged) | 9 (unchanged) |
| **BPO fork 1** | 2025-12-09 14:21 | 10 | 15 |
| **BPO fork 2** | 2026-01-07 01:01 | 14 | 21 |
Glamsterdam
As Fusaka concludes, attention is transitioning toward upcoming enhancements. Directly succeeding Fusaka, Glamsterdam aims for ‘sometime in 2026’. Its primary features (”headliners”), enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs) were selected in August while the additional (”non-headlining”) features are presently being discussed.
When the Pectra fork was outlined in 2024, the upgrade schedule was relatively flexible, lacking a distinct headliner, resulting in an overwhelmed fork that required separation into two parts. In reaction to this, the ACDE call facilitator Tim Beiko suggested a clearer, more rigorous framework for outlining an upgrade to enhance the process.
This marks the first upgrade that has established a definitive timeline and deadlines from the outset, resulting in an increased number of features being proposed compared to the past. The deadline for submitting non-headlining features was October 30th, with 48 features submitted in time. Core developers and the community are currently evaluating this list to decide which features should be prioritized. Selections will be made based on overall necessity/urgency, compatibility with other features, and their complexity levels.
If any of these features is particularly critical for users of the core protocol, the Ethereum community is invited to voice their opinions to aid core developers in understanding that necessity.
FOCIL
While the headliner process motivated the community to select solely one feature each for the execution and consensus layers for simplicity, Fork-choice enforced Inclusion Lists (FOCIL), a censorship-resistant feature, received overwhelmingly strong backing and was elevated to a conditional “Considered” status while the two prioritized features were moved to “Scheduled” status. This was deliberated as reliant on the advancement of ePBS (the consensus layer feature) and also necessitates that FOCIL does not significantly postpone the upgrade.
During this week’s All Core Devs, there was backing for advancing FOCIL to the subsequent upgrade following Glamsterdam, Heka / Bogotá, conditional on a yet-to-be-determined credible commitment for it to be included in that upgrade. This decision will provide better clarity for developers regarding their capacity to work on the minor features, ensuring they are not left uncertain about whether or not they need to be outlining with FOCIL in consideration.
Timeline
Currently, there is no proposed schedule for Glamsterdam aside from ‘sometime in 2026.’ The timeline will hinge on the overall extent of the selected features and the advancement made on the primary developments. It is probable that the confirmed collection will be established by the end of this year, allowing developers to concentrate on carrying out implementation and selecting the main attributes for the next upgrade.
It’s Devconnect week, indicating that face-to-face discussions can hasten the agreement for next week’s All Core Devs Execution call, but the upcoming two Monday Testing calls have been cancelled.
Gas limit
Every client has affirmed their preparedness for 60 M by Fusaka. Node operators are not required to undertake any actions beyond standard client updates prior to Fusaka – all clients will default to 60 M. Anticipate regular increments to the default gas limit now that there’s a defined framework by Nethermind to contemplate safe limits to aim for. Node operators may still indicate their approval for elevated values by manually adjusting their limits.
Heka / Bogotá upgrade
With an established rhythm of planning one fork while executing the other, we can initiate discussions regarding the key features for the Heka / Bogotá upgrade once Fusaka is operational. Heka was selected as the stellar name and the portmanteau is still being debated. Following this week’s All Core Devs meeting, we can anticipate FOCIL to emerge as the leading contender in the headliner selection process.
Fusaka has undergone pressures between two shipping priority approaches: ship securely or ship quickly. The community has advocated for swifter forks, evident in decision-making – Fusaka will launch 6 months and 26 days after Pectra, partly due to prioritizing speed more than ever before. Where timelines in prior forks were generally established based on when all clients were prepared, Fusaka’s timeline was more inclined towards when most clients were ready.
There was a unique advantage to Fusaka’s preparation in that its principal features were initially part of Pectra before the upgrade was divided into two, allowing for a head start in their implementation. I don’t anticipate observing the same promptness in Glamsterdam, although I do foresee an ongoing effort to release as swiftly as possible.
If this newly structured process, initiated in the Glamsterdam upgrade, leads to diminished chaos and stress alongside increased efficiency compared to Pectra, it appears evident that the greatest benefit lies in long-term strategy and clarified structure for each phase of the upgrade, rather than merely urging developers to accelerate their pace, allowing us to experiment with improved parallel planning and development for upcoming forks.
However, if Glamsterdam continues to feel as daunting as Pectra did initially, we’ll need to determine more effective ways to manage enthusiasm for adopting an expansive array of features and the mindset of “we can achieve it all” at the beginning of an upgrade.
Regarding FOCIL being relocated to Heka / Bogotá: it’s challenging to definitively commit to a feature in a future upgrade two forks ahead. We’ve encountered this issue before when a feature was planned, but the community shifted their interest, leading to a difficult process of having to remove it when developers are anticipating it and have already commenced work.
Should it be deferred to the subsequent upgrade, the optimal course for developers and the community concerning FOCIL is to maintain active backing for its swift inclusion and not pivot to another enticing major feature that may lessen the perceived urgency. Censorship resistance is essential for Ethereum’s fundamental value, and it’s crucial not to lose sight of that if an alternative exciting feature gains significant traction.
pertinent ACD calls:
[ October 2nd – November 13th ]
Source link
“`