This is a quick, easily-digestable wrap-up of the last four protocol development calls with a bit of my own perspective of how it ties in to community commentary. I’ll aim to do one every ~4-5 calls, depending on current events.
Relevant ACD calls:
Pectra fork
Over the last four ACD calls, we’ve moved from a buggy Pectra devnet-5 to a stable devnet-6. Dates to activate the Pectra fork on the two testnets (Holesky & Sepolia) were chosen, with Holesky forking this coming Monday, February 24th at 9:55pm UTC. Audits were completed and Pectra is expected to go live on mainnet ~30 days after a successful Sepolia testnet fork (plus some days for coordination of mainnet launch date choice). The mainnet date, expected early April, will be announced on the EF blog.
The process itself
There was lots of conversation asking client teams and any interested parties to evaluate the upgrade process as seen throughout Pectra so that we can move to make protocol upgrades as efficient as possible. All client teams contributed feedback. There was strong consensus on a desire to increase the frequency of forks and to keep scope smaller per fork. EIP-wise, Pectra has been the largest fork to date. There was also strong recognition that testing is a bottleneck in the process - this led to calls for more uniform testing standards and also better fleshed-out EIPs at the point of considering them for inclusion (”CFI” status).
Other
Hardware & bandwidth recommendations for running an Ethereum node are being finalized into an EIP. And blob-parameter only (“BPO”) forks have been proposed, which would create a separate type of fork to adjust only the number of blobs available. A Fusaka fork could aim for 12 (or more?) blobs, but BPO forks could get us far beyond that before Glamsterdam, the fork after Fusaka.
Going forward
A clear result of the “Pectra retrospective” discussion was a desire for a faster cadence, and it was proposed to freeze the scope of the fork following Pectra, “Fusaka”, within a month (~Mar 13th). The only EIPs in the Scheduled For Inclusion (SFI) status are PeerDAS and EOF. PeerDAS has broad consensus and is already in its fifth devnet but devs are currently in discussion about whether or not EOF is in a place to not slow down the shipping of PeerDAS, which is increasingly being viewed as an urgent upgrade.
The proposal to finalize the Fusaka spec before even shipping the current fork creates a strong departure from the general expectation that Fusaka’s earliest release might even be early 2026 - the goal would be to ship it as quickly and as leanly as possible to aim for ~6 month cadences going forward. Nine other EIPs have been Proposed For Inclusion (”PFI” status) for Fusaka, so we’ll have to see if devs are able to keep scope creep down…
Commentary
We’ve seen a shift toward “accelerationism” in community conversation and I think it’s been a combination of this and of L2s talking to researchers about projected DA needs that have created a sense of urgency around both PeerDAS and increasing the number of available blobs. Scaling for both the L1 and L2 are at odds with keeping node requirements low - as blobs and gas limit increase, node requirements increase. PeerDAS or a flag for validators to choose the number of blobs they want to include are examples of features that mitigate these increases in order to maintain Ethereum’s most valuable asset: its decentralized validator set. If L2s are doing the projections for the DA they’ll need, I encourage them to share those publicly so the community can unite behind the need for scaling and the magnitude and timeline of that need.
