How the Fusaka Upgrade Will Transform Ethereum’s Scalability and Layer-2 Costs
Ethereum’s Fusaka upgrade will activate on the main network on December 3, 2025, at slot 13,164,544. The name combines the Fulu consensus-layer fork and the Osaka execution-layer fork, reflecting the dual nature of the changes. Fusaka follows this year’s Pectra upgrade and represents a major step in Ethereum’s plan to improve scalability and user experience.
Its most prominent feature is Peer Data Availability Sampling (PeerDAS), which allows nodes to check only small portions of large data blobs rather than downloading the entire payload. This change is designed to increase the capacity for rollup data on Layer‑2 networks and reduce transaction fees.
The upgrade is part of Ethereum’s long‑term roadmap. After the Merge (2022), Shapella (2023) and Dencun (2024) brought staking withdrawals and temporary data blobs for rollups, while Pectra (2025) introduced account abstraction features. Fusaka builds on these changes by addressing both the Surge and Verge/Purge stages of the roadmap, scaling data availability and improving client efficiency, while setting the stage for future upgrades such as the Glamsterdam fork.
Scaling Layer‑2 Data Through PeerDAS
Layer‑2 rollups bundle transactions and post the results back to Ethereum in blobs. Under the pre‑Fusaka model, every full node downloads every blob to verify its availability. This method limits how many blobs can be included per block because it burdens validators with large bandwidth and storage requirements.
In practice, the network currently allows a target of six blobs and a maximum of nine blobs per block. As rollup activity increases, this small “cargo bed” creates a bottleneck that pushes up fees and threatens decentralization.
PeerDAS (EIP‑7594) resolves this problem by enabling nodes to verify blob data through sampling. Instead of downloading entire blobs, nodes request random samples of the data and use erasure coding to ensure that the full data set can be reconstructed if enough samples are available.
The official Ethereum blog notes that this mechanism lets nodes verify availability without increasing bandwidth requirements and paves the way for higher blob targets. Quicknode explains that PeerDAS could immediately increase the amount of data the network handles by up to eight times. By reducing the burden on each validator, PeerDAS keeps node operation accessible, which is critical for decentralization.
From a user’s perspective, more blob capacity means greater space for rollups to publish data, reducing competition for limited slots and lowering fees on Layer‑2 networks. Quicknode notes that cheaper Layer‑2 data leads to cheaper Layer‑2 transactions, directly benefiting users of DeFi, gaming, and social applications.
However, PeerDAS also introduces a three‑tiered network: light clients that perform sampling, typical validators that store only a fraction of the data, and “supernodes,” larger operators such as RPC providers, that store all data. This architecture raises centralization concerns, but proponents argue that the design still relies on network consensus rather than trust.
Flexible Data Capacity with BPO Forks and Fee Stability
PeerDAS alone does not increase blob capacity on day one; it provides the foundation for future expansions. To raise blob limits safely, Ethereum introduces Blob Parameter Only (BPO) forks (EIP‑7892). Instead of waiting for a major hard fork to change blob settings, BPO forks allow client teams to adjust the target and maximum number of blobs through smaller upgrades.
According to the Ethereum Foundation, Fusaka will be followed by two BPO updates: the first, scheduled for December 9, 2025, will raise the per‑block blob target from six to ten and the maximum from nine to fifteen, while a second in January 2026 will raise the target to fourteen and the maximum to twenty‑one. These incremental increases let the network respond to Layer‑2 demand without prolonged coordination cycles.
Ethereum also introduces a new blob fee market. Currently, Layer‑2 operators pay two fees when posting blobs: a blob fee and the execution gas fee needed to verify the blob. When execution gas fee dominates, the blob fee auction can sink to nearly zero, undermining the price signal. EIP‑7918 establishes a reserve price proportional to execution costs, ensuring that the blob fee market responds to congestion and that rollups pay a fair share for the compute they impose on nodes. This change prevents the blob fee from collapsing to 1 wei during high Layer‑1 gas periods and stabilizes costs for rollups.
Boosting Layer‑1 Throughput and Security
While Fusaka is largely about Layer‑2 scaling, it also enhances the Layer‑1 chain. EIP‑7935 increased the default block gas limit from 45 million to 60 million gas, expanding the amount of computation that can fit in a block and allowing more complex or numerous transactions on the main chain.
To prevent abuse as limits rise, EIP‑7825 caps the gas that any single transaction can consume at 16,777,216 gas (2^24). By bounding the worst‑case transaction, Ethereum ensures that one heavy operation cannot monopolize an entire block, facilitating safe increases in the block gas limit.
Fusaka also imposes a physical block size limit. EIP‑7934 sets a cap of 10 MiB on the RLP‑encoded execution block, with a 2 MiB safety margin reserved for consensus data. Aligning execution blocks with the consensus layer’s gossip limit prevents large blocks from causing propagation delays or reorgs.
The network further hardens itself against denial‑of‑service risks through changes to the MODEXP precompile. EIP‑7823 sets upper bounds on input sizes, rejecting numbers longer than 8192 bits to avoid abusive cases, while EIP‑7883 revises gas pricing to reflect real computational costs. These adjustments ensure that modular exponentiation cannot stall the network and prepare the chain for future gas limit increases.
Related: How AI is Revolutionizing Decentralized Finance and Market Making
Improving User Experience and Developer Tools
Fusaka is not just about raw capacity; it also enhances usability and tooling. EIP‑7917 introduces deterministic proposer lookahead. Currently, validators cannot reliably know who will propose a block in the next epoch because balances may change. With this upgrade, the Beacon Chain will list proposers for the current and upcoming epoch.
This determinism enables Layer‑2 protocols to offer faster pre‑confirmations, as they can coordinate with upcoming proposers to commit transactions earlier. Better visibility also reduces the risk of malicious manipulation of the proposer schedule and simplifies client implementation.
Developers gain new primitives. EIP‑7939 adds a Count Leading Zeros (CLZ) opcode, which returns the number of zero bits at the start of a 256‑bit word. Many low‑level operations, such as computing logarithms, finding the first set bit, or normalizing numbers, benefit from this instruction. By replacing manual loops with a single opcode, the CLZ instruction cuts gas costs for math‑heavy smart contracts and zero‑knowledge applications.
On the user experience front, EIP‑7951 introduces a precompile for the secp256r1 (P‑256) curve. This precompile enables contracts to verify signatures generated by modern hardware like Apple’s Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices. Wallets can integrate these flows to allow users to sign transactions with device-native biometrics such as Face ID or fingerprint sensors. Developers can integrate these flows easily, as the precompile takes a 160‑byte input and returns a 32‑byte output.
Fusaka also adds the eth_config JSON‑RPC method (EIP‑7910), which lets node operators query their current and upcoming fork settings. This tool addresses misconfiguration issues seen during earlier testnet forks and helps operators verify that they are ready for the upgrade.
Implications for Validators, Rollups, and Users
The Fusaka upgrade affects various stakeholders differently. Rollup operators and Layer‑2 platforms stand to benefit the most from the increased data availability. Quicknode notes that with PeerDAS, cheaper Layer‑2 data fees will translate to significantly lower transaction costs for end users. The Ethereum Foundation explains that as blob capacity scales, rollup fees can decrease while preserving data availability. The new blob fee mechanism also ensures that rollups always pay at least a meaningful portion of the computational costs they impose on the network.
Validators and node operators must prepare by updating their software to versions that support PeerDAS, cell proofs, and the new gas rules. According to the official guide, Fusaka requires updates to both execution and consensus clients, and node operators must run supported releases to stay synchronized after the upgrade. It emphasises that operators should check their hardware, storage, and bandwidth requirements because the amount of data a validator needs to store depends on its staked ETH. Validators with larger stakes (e.g., 32 ETH, 320 ETH, 1,024 ETH, etc.) will hold more data, while typical nodes will download and store less than before.
A notable trade‑off is the emergence of “supernodes.” Quicknode explains that while PeerDAS reduces the data each validator must store, it creates a role for powerful nodes that download all blob data. These nodes, often operated by large infrastructure providers, carry higher storage and bandwidth requirements. Some researchers worry that reliance on supernodes could concentrate the full data layer among a few actors. Others argue that the network only depends on their availability, not on trusting them, because cryptographic sampling still ensures data availability. Balancing scalability with decentralization remains an ongoing debate.
For everyday users and ETH holders, the impact is mostly indirect. The Ethereum Foundation stresses that holders do not need to take any action; their ETH balances remain intact, and there is no need to “upgrade” tokens. Anyone instructing users to convert their ETH is likely attempting a scam. Instead, users should expect lower fees on rollups and smoother transaction confirmations once Layer‑2 networks incorporate the new capacity.
Positioning in the Roadmap and What Comes Next
Fusaka is a crucial part of Ethereum’s Surge and Verge/Purge phases, which focus on scaling the network through rollups and making nodes lighter. PeerDAS and BPO forks push the Surge forward by expanding blob capacity and making data sampling the norm. History expiry (EIP‑7642) and network protocol cleanups drop pre‑Merge fields and receipt bloom filters, reducing sync bandwidth requirements and simplifying client. Together, these changes prepare the network for consistent capacity increases without requiring every node to become a data-center-grade machine.
Following Fusaka, Ethereum plans to implement Glamsterdam in 2026, which is expected to introduce enshrined proposer‑builder separation (ePBS) and block‑level access lists. While exact details remain under development, the combination of PeerDAS, BPO forks, and upcoming features is aimed at enabling a modular Ethereum stack capable of supporting more than 100,000 transactions per second when Layer‑2 throughput is added on top of Layer‑1 settlement. The Ethereum roadmap emphasizes that sustained scaling must not compromise decentralization, a balance that Fusaka seeks to advance through sampling and flexible parameter adjustments.
Related: How Solana Is Powering the Next Generation of Blockchain Apps
Conclusion: A Foundation for the Next Era
The Fusaka upgrade marks a turning point in Ethereum’s evolution. By introducing PeerDAS, BPO forks, gas‑limit changes, and new developer tools, the upgrade tackles both the bandwidth constraints of Layer‑2 data and the computational limits of Layer‑1. Official documentation shows that PeerDAS allows nodes to verify data availability through sampling, enabling higher blob throughput without burdening individual validators. Flexible blob parameter forks and a stabilized fee market ensure that capacity can grow in response to demand.
For users, rollups, and developers, Fusaka promises lower costs, faster confirmations, and better integration with modern authentication methods. Validators must upgrade their clients and adjust hardware, but typical nodes will need less storage thanks to sampling. Debate continues about the role of supernodes, yet the network remains committed to decentralization through cryptographic guarantees. As Ethereum moves into 2026 and beyond, Fusaka will likely be remembered not merely as a single fork but as the upgrade that unlocked a scalable, more flexible future for the world’s leading smart‑contract platform.
