Fusaka is (nearly) here, and with it comes one of the most meaningful steps forward for Ethereum scaling and validator operations since Dencun. This upgrade introduces a higher gas limit, blob-focused enhancements, and critical data-availability improvements through PeerDAS.
For stakers and operators, Fusaka brings new performance considerations, new hardware thresholds, and a clearer path toward a more scalable Ethereum without compromising validator integrity. Below is a quick overview of what’s changing, what to watch for, and how this impacts anyone running or delegating to Ethereum validators.
Fusaka is (nearly) here!
Scaling is the theme of the Fusaka upgrade. The gas limit is increasing from 45M to 60M:
(Source: gaslimit.pics)
PeerDAS is going live, paving the way for faster scaling of L2s through more blobs. Rather than requiring validators to download and custody all blobs, PeerDAS allows most validators to download a sample only. This breaks the connection between the number of blobs that are hardware requirements for most validators.
(Source: l2beat.com)
Blob parameter only (BPO) forks are also baked into Fusaka:
-
BPO1 will increase the target and max number of blobs from 6 and 9 to 10 and 15 on December 17th.
-
BPO2 will increase the target to 14 and the max to 21 on January 7th.
Importantly, if there are any issues related to an increase in blob numbers, core devs can delay further BPO forks or reduce the number of blobs.
A reminder for anyone running validators: the more ETH a validator client manages, the higher the hardware requirements will be after Fusaka due to increased blob-related data demands. Here is an example of a supernode—one with 4,096 ETH associated with it (or greater):
(Source: Parithosh and Samcm at ethPandaOps, EF)
Notice that disk usage increases at Fusaka by about 100 GB for the target of 6 blobs and by around 175 to 200 GB for a max of 9 blobs.
Interested operators are encouraged to explore the different hardware requirements for disk usage, download, and upload across the different staked ETH thresholds. (For a full list of EIPs see this meta EIP).
What are the Implications of Fusaka?
There will be a step up in the gas limit and the data associated with blobs (though the actual number of blobs will be unchanged through the Fusaka fork).
The increase in the gas limit is unlikely to have a major impact on Ethereum as many validators (over 60%) have already increased their gas limit without any notable events. It seems unlikely that the remaining 40% of validators increasing their gas limit from 45M to 60M will cause any issues.
With blobs, generally, the upload bandwidth requirements will likely increase across the board starting at Fusaka. Most other nodes—those with less than 2,048 ETH associated with it—will have less hardware requirements for disk usage and download speeds at Fusaka. There is a chance that some validators with 2,048 ETH or more could struggle if they do not meet the new, higher hardware requirements.
As with any fork, watching the participation rate and the time taken to finalize around the fork are good starting points. You can see this dashboard already set up on beaconcha.in for Fusaka:
For those who want to observe Fusaka, the timing of the fork is December 3rd at 21:49:11 UTC. There is also an ETHStaker watch party:
What’s Next?
Glamsterdam is coming up next year. Scoping is still in process but many EIPs have already been scheduled for inclusion, including the two headliner EIPs: EIP-7732 (Enshrined Proposer Builder Separation/ePBS) and EIP-7928 (Block-Level Access Lists).
The vast majority of blocks being proposed today are created by an external network of builders. Proposers (i.e., validators) outsource this function through MEV-Boost or commit-boost—optional sidecars that enable out-of-protocol proposer builder separation. The idea with ePBS is to bring this in-protocol. To get a sense of how this might work, readers can review the specs under EIP-7732, but should treat these as tentative.
The idea with EIP-7928: Block-Level Access Lists is to extend the execution payload to add a list containing “all accounts and storage locations accessed during block execution, along with their post-execution values.” The ability to see all accounts that are affected by a block paves the way for parallel execution, which could allow for more throughput and/or faster execution.
Looking Forward
Fusaka marks another major milestone in Ethereum’s long-term scaling roadmap, and it meaningfully shapes the operational landscape for validators.
Most stakers will benefit from the upgrade’s efficiency gains without needing to take action, while operators of large validator clusters should double-check hardware plans, bandwidth capacity, and blob-related storage requirements ahead of the fork.
As participation stabilizes and the network adjusts to new gas limits and PeerDAS sampling, attention will quickly shift to next year’s Glamsterdam upgrade, including ePBS and Block-Level Access Lists, both of which carry deep implications for MEV, proposer duties, and validator performance. Ethereum continues to evolve, and Fusaka is another step toward a more scalable, secure, and high-throughput network for stakers everywhere.
