Ethereum’s next major upgrade, Fusaka, marks an important milestone in the network’s ongoing scalability journey. Comprising the Osaka upgrade on the execution layer (EL) and Fulu on the consensus layer (CL), Fusaka is designed to make Ethereum more efficient and resilient, particularly for rollups, Layer 2s, and validators.
Central to this release is PeerDAS (EIP-7594), a transformative change to how data availability is handled. By introducing data sampling instead of full downloads, PeerDAS allows Ethereum to scale blob space without overburdening validators’ hardware. This post breaks down what operators and stakers need to know ahead of Fusaka’s expected launch later this year and explores how these updates will shape Ethereum’s scaling roadmap in 2025 and beyond.
What is it?
Fusaka is the next scheduled upgrade taking place on Ethereum, with Osaka being the relevant upgrade on the execution layer (EL) and Fulu on the consensus layer (CL). The latest estimates for timing as mentioned on the All Core Devs CL call, suggested December 3rd as a likely date for mainnet:
PeerDAS and Blobs
PeerDAS (EIP-7594) is arguably the most significant upgrade on the CL. This upgrade is all about scaling L2s and breaking the connection between increased blob space and hardware requirements. The goal of PeerDAS from the EIP: “DAS is a method of scaling data availability beyond the levels of EIP-4844 by not requiring all nodes to download all data while still ensuring that all of the data has been made available.”
Today, validators must download all blob data and ensure it is available for 4,096 epochs (18 days). With a target of 6 blobs, max of 9, blob size of 125 kilobytes, storage requirements for validators due to blobs in the worst case is an additional ~150 GB or ~97 GB in the target case, assuming average number of blobs over 18 days is equal to the target number of blobs.
To meaningfully scale blobs available to L2s/apps, i.e., to 10x current blob numbers, for example, the storage and bandwidth requirements of validators would increase as well. To avoid this, PeerDAS replaces the requirement that all validators download and store all blobs to one of sampling – validators must download and store a subset of blob data.
It should be noted that blob data is extended via erasure coding. What this means is that for the same amount of data today, post-Fusaka Ethereum will double the data size. Practically speaking, the amount of data that must be processed and stored by nodes will be dependent on stake associated with that node, see section below: ‘What operators should know’ for more.
Dovetailing in with PeerDAS is the Blob parameter only (BPO) forks upgrade (EIP-7892). With PeerDAS in place, this upgrade sets up a schedule to increase the number of blobs, increasing blockspace for L2s and apps. Importantly, these changes will happen at predefined epochs outside of scheduled upgrades. As referenced above, December 3rd seems likely for Fusaka, December 17th for BPO1 and Jan 7th for BPO2. Readers are encouraged to remember that everything is subject to change before the mainnet fork.
What Operators Should Know
Operators should bear in mind that the amount of stake associated with their validators will determine how many custody groups (i.e., how much data) they are responsible for storing. The cut-offs by stake size are: 32, 320, 1024, 2048, 4096 ETH. These correspond to the quantity of data that must be downloaded and stored for 18 days.
At a minimum, operators should review their storage, download and upload bandwidth to ensure they’ll be able to meet the hardware requirements. Relative to today, where nodes must download all of the blobs, most nodes represented by stake sizes above, will be required to download, upload and store less from a data perspective. Large operators (2048 ETH of stake but less than 4096 ETH) and “supernodes” (at 4096 ETH and above) will be required to process and store more data starting at Fusaka.
This piece by Parithosh and Sam from the Ethereum Foundation is a great primer on PeerDAS and provides a calculator for the different node sizes. Here is an example for storage required for a larger operator:
As a reminder, with blobs (as with blockspace) there is a target and a maximum number of blobs. When the number of blobs is higher than the target the price increases and when it’s lower it decreases. The chart above shows the storage required for both the target and max blobs. Readers can review the number of blobs used recently here (from Etherscan):
The calculator also shows the increased requirements with BPO1 and BPO2 – both for target and max blobs. Operators should ensure that they meet the hardware requirements well in advance of Fusaka and the BPO forks.
As noted by the authors of the piece linked above, the numbers in the calculator are theoretical. There is also an empirical section based on testing; readers are encouraged to review that section in addition to the calculator (theoretical).
All Upgrades:
Here are all of the upgrades in Fusaka:
EIP-7594: PeerDAS – Peer Data Availability Sampling
EIP-7823: Set upper bounds for MODEXP
EIP-7825: Transaction Gas Limit Cap
EIP-7883: ModExp Gas Cost Increase
EIP-7917: Deterministic proposer lookahead
EIP-7918: Blob base fee bounded by execution cost
EIP-7934: RLP Execution Block Size Limit
EIP-7935: Set default gas limit to XX0M
EIP-7939: Count leading zeros (CLZ) opcode
EIP-7951: Precompile for secp256r1 Curve Support
EIP-7892: Blob Parameter Only Hardforks
EIP-7642: eth/69 – Drop pre-merge fields
Client teams MUST support this EIP by the activation of the Fusaka network upgrade.
EIP-7910: eth_config JSON-RPC Method
Client teams MUST support this JSON RPC method by the activation of Fusaka network upgrade.
Our last proposal to highlight is EIP-7917: Deterministic proposer lookahead. This proposal seeks to have Ethereum, at the start of each epoch, store a list of proposers for the current and next epoch. As it stands today, pre-Fusaka, the proposers in the next epoch cannot be known with certainty because validators’ effective balances can change in the current epoch. This change is particularly relevant to preconfirmation protocols like ETHGas and primev.
What Should Stakers Know?
Unlike the Pectra upgrade, Fusaka does not offer stakers options. The upgrade on the CL side should be viewed as largely about scaling L2s and some added work for some validators. The increase in work is limited given the nature of PeerDAS as described above.
It’s helpful to put scaling efforts into perspective. The increase in blobs posted after Pectra, when the number of blobs was increased, is clear:
The increased blob space for rollups and other applications is being absorbed. Accommodating existing L2s and making room for new ones is important for Ethereum’s ecosystem.
Another way to see this is to look at the cost for L2s. Here is a breakdown of costs for rollups:
Looking Forward
Fusaka represents the next evolutionary step in Ethereum’s modular scaling path, making the network more efficient for both validators and rollups. With PeerDAS reducing hardware constraints and Blob Parameter Only forks (EIP-7892) enabling dynamic blob scaling, Ethereum is laying the groundwork for sustained throughput growth without compromising decentralization.
For operators, preparing infrastructure to handle new data responsibilities will be key; for stakers, the upgrade underscores Ethereum’s long-term commitment to scalability and Layer 2 support. As the network moves closer to activation later this year, staying informed and ready for the transition will ensure a smooth experience for all participants in the Ethereum ecosystem. Reach out to Figment to discuss Ethereum staking in more depth.
