“`html
Ethereum’s weekly All Core Developer calls can be quite overwhelming, so this “Checkpoint” series aims to provide high-level summaries approximately every 4-5 weeks, contingent on developments in core programming. Refer to the earlier update here.
tl;dr:
Since the previous Checkpoint, the Pectra upgrade was successfully implemented, and core developers have placed significant focus on keeping the subsequent upgrade (Fusaka) streamlined to facilitate the release of PeerDAS, a scalability enhancement. Testing for Fusaka is in progress, and developers remain hopeful for a 2025 launch date. Suggestions for the main feature of the upgrade that follows Fusaka (“Glamsterdam”, ~2026) are being accepted until June 20th.
Pectra
Pectra proceeded without complications, providing staking quality-of-life enhancements, a significant improvement for wallet user experience, expanded blobs, and additional features. Although Q1 testnet issues stirred a bit more apprehension than typical, the upgrade was seamless with all new functionalities performing as anticipated. It is now upon the application layer to leverage these feature releases for users—whether to ensure staking providers will integrate maxEB, or for wallet providers to back 7702, and so on.
Fusaka
Fusaka’s primary feature, PeerDAS, has been in feature-specific evaluation since 2024 and recently completed its seventh development network. The inaugural multi-feature Fusaka devnet was launched last week and the following one will be initiated during Berlin Blockchain Week.
The quantity of devnets necessary for comprehensive testing is contingent on various factors, such as the number and intricacy of the features and their compatibility. This generally fluctuates from ~5-13, and each is usually very short-lived as each devnet introduces or modifies one or several features at a time. As devnets advance and features are integrated, you can monitor these features transition from the Considered status to the Scheduled status. The upgrade will only be launched on a testnet once all features are stable across the devnets.
Blob Parameter Only (BPO) fork testing is also in progress! This will enable adjustments to the number of blobs available outside of hard forks to facilitate quicker scaling for L2s. As part of the evaluation, blob counts are being modified up and down, and the functionality has been performing as intended thus far.
Gas limit evaluations are assessing whether a 60 million gas limit will be adequate for Fusaka. Gas limit modifications don’t necessitate a hard fork and can be adjusted by validators.
“““html
independently, yet obligations towards assessing their security during an enhancement proves beneficial to dispatching elevated defaults in client applications. Spoiler alert: 60m looks promising, even for residential stakers.
Groups dedicated to upgrading the Sepolia testnet ahead of the Hoodi testnet for Fusaka and moving forward to maintain Hoodi as an essential app-testing framework prior to mainnet enhancements.
Glamsterdam
The Glamsterdam dialogue began in ACDC #158 with two suggested headliners: ePBS & FOCIL. EIP advocates presented their argument for these as key components of the upgrade. Others are starting to establish their own cases too. If you possess an EIP you believe would be the prime headliner for Glamsterdam, feel free to propose it utilizing the proposal template in the EIPs category for dialogue.
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 introduced history expiry on Sepolia with other clients expected to follow shortly. History expiry is already experimentally accessible on mainnet with multiple clients but is user-defined rather than default. Upon thorough examination by all clients on Sepolia, it will be implemented in default software configurations. Progress can be monitored in the #history-expiry channel on the Eth R&D Discord.
Process
A resolution was reached to shift the existing upgrade testing discussions to Monday testing sessions, now termed All Core Devs Testing (ACDT), while Thursday sessions will address future upgrade scoping. Adjustments to the upgrade procedure are ongoing and will likely see further reconfiguration during Berlin Blockchain Week sprints. Everyone is welcomed to express their views on
“““html
Ethereum Magicians.
Primary developers have consistently focused on maintaining Fusaka’s efficiency and have been vigorously dismissing any elements that may hinder its prompt release, which gives me optimism for a 2025 Fusaka.
Established patterns are challenging to alter, and implementing procedural changes in decentralized governance is tough – even with the resolution to shift Thursday discussions to future fork planning, we’ve had four meetings since Pectra yet only began talking about Glamsterdam in the most recent one. To accelerate delivery, we must adhere closely to the suggested Glamsterdam timelines and determine not only the methods to expedite upgrades but also the methodologies that individuals will genuinely adopt and adhere to.
Fusaka’s development is progressing as planned, and if the objectives are [ enhance L1, amplify blobs for L2, enhance UX ] – we are undoubtedly moving in the right direction.
Relevant ACD calls
Now including ACDT(esting) calls too!
Source link
“`
