Ethereum: A Closer Look at the New Features Introduced by the Fusaka Upgrade
December 3, 2025
In this post
Fusaka is Ethereum’s latest upgrade and one of the most important since The Merge. It introduces PeerDAS, a major step forward for data availability, along with a series of technical optimizations aimed at improving network performance and resilience, particularly through the use of blobs. In this article, we review Fusaka and its technical implications.
Context
Since The Merge in 2022, Ethereum’s roadmap has focused on improving scalability, user experience and transaction costs, while preserving the decentralization that defines the network.
Over the past two years, two major upgrades have pushed this trajectory forward: Dencun and Pectra.
Dencun, introduced in March 2024, brought several important improvements, including the addition of blobs, a new data format designed for L2s. As L2 networks have grown rapidly in recent years, Ethereum has increasingly oriented part of its efforts toward making their development easier.
Blobs support this goal by offering a form of temporary storage whose data is erased after 4096 epochs, which corresponds to around 18 days. This duration is more than sufficient for L2s, which only need to retain proofs of these data after that period. In practice, this ephemeral design has reduced transaction costs on these networks by more than an order of magnitude.
Pectra, deployed in May 2025, continued in this direction by increasing the number of blobs per block from 3 to 6. Since November 2024, L2 usage has been high enough that all blob capacity was used in every block, which made raising the initial threshold necessary. So far, the 6-blob target has not yet been consistently reached, but usage is getting closer.
Pectra also introduced EIP-7702, which allows any address to benefit from account abstraction features, and EIP-7251, which now lets validators stake between 32 and 2048 ETH (compared to a fixed 32 ETH previously).
Fusaka extends this trajectory by strengthening the use of blobs, primarily through the implementation of PeerDAS. It also includes several technical optimizations whose long-term impact could be significant.
→ For a deeper dive into the main EIPs in Pectra, you can read our previous analysis:
Loading post...
What is the Fusaka upgrade on Ethereum?
Fusaka is the third major Ethereum upgrade focused on L2 scalability after Dencun (2024) and Pectra (2025). Like the previous two, it in fact combines two upgrades:
- Osaka, which concerns the execution layer and defines how transactions are processed within the EVM
- Fulu, which updates the consensus layer and determines how nodes agree on block order and validity
It bundles 13 EIPs that directly extend the work started with Dencun and Pectra. The main goal is to improve how Ethereum handles data produced by layer 2 networks, while refining several core network parameters.
One of the key innovations is PeerDAS, a mechanism that distributes blob data across a large number of validators instead of requiring each one to store the entire blob. This approach improves blob scalability without imposing excessive hardware requirements on validators.
The upgrade also introduces several adjustments to better control blob usage, including a more flexible way to change the number of blobs and a minimum fee level to ensure processing remains profitable for validators. These mechanisms stabilize the blob fee market and prepare the network for gradual growth in L2 activity.
In parallel, Fusaka brings several optimizations related to gas and node operation. The progressive increase of the block gas limit continues, in order to raise network capacity without meaningfully harming decentralization. New precompiles, including one for secp256r1 signatures, make some on-chain operations simpler and cheaper.
Finally, the upgrade includes several changes aimed at making validator operations easier: more predictable parameters, clearer data limits and mechanisms to reduce the risk of client desynchronization.
In short, Fusaka does not introduce visible changes for end users, but it is a key step in Ethereum’s scalability roadmap. It prepares the infrastructure for the growing needs of layer 2s and contributes to a more robust, stable and predictable network.
Blobs and PeerDAS
PeerDAS: scaling blob capacity
PeerDAS (EIP-7594) is the main innovation introduced by Fusaka. PeerDAS, or Peer Data Availability Sampling, is a protocol that distributes blob data storage across many validators.
Today, each validator must be able to access the full content of all blobs. With PeerDAS, each validator stores only a random fraction of each blob. Thanks to Ethereum’s very large validator set (around 1.12 million validators), it becomes statistically very likely that the complete data remains available at any time.
In its initial configuration, PeerDAS requires each validator to store at least 1/8 of each blob, with the option to store more. At constant bandwidth, this suggests that current validators could theoretically support eight times more blobs than today. Over time, this requirement could be reduced to 1/16 or even 1/32.
Historically, decentralization and scalability have often been in tension. Networks like Solana can process large volumes of transactions because running a validator requires high bandwidth and powerful hardware. At the other extreme, running a Bitcoin node is very lightweight, precisely because throughput is low enough for even modest nodes to stay in sync.
Ethereum continually looks for designs that balance these constraints. L2s are a clear example of scalability that offloads part of the burden while preserving strong cryptographic guarantees on the base layer.
PeerDAS follows the same logic. On paper, it slightly reduces decentralization, since validators must rely on their peers to reconstruct full blob data. In return, it leverages the sheer size of the validator set to provide strong statistical guarantees. In practice, it significantly boosts scalability while only marginally affecting decentralization.
EIPs improving blob functionality
Several other EIPs in Fusaka are also related to blobs. EIP-7918 (Blob base fee bounded by execution cost) introduces a minimum base fee for blobs. Before Fusaka, blobs had their own gas market, with prices fluctuating solely based on L2 demand.
When demand exceeded the 6-blob target per block, the blob gas price increased at the next block. When demand dropped, the price went down. The issue is that, during long periods of low demand, blob gas could fall below the actual execution cost for validators, making it unprofitable for them to process blobs. EIP-7918 addresses this by setting a floor price that is meant to cover validator operating costs.
EIP-7892 (Blob Parameter Only Hardforks) defines so-called BPO hard forks (Blob Parameter Only), a new type of hard fork restricted to blob-related parameters.
Today, changing the target number of blobs per block, a key parameter for blob gas pricing, requires a full hard fork, since it is not backward compatible. This makes adjustments heavy to coordinate, even though this parameter needs to evolve quickly in response to L2 demand.
EIP-7892 solves this by introducing a simplified hard fork limited to blob parameters, making such adjustments far easier to deploy.
Together, these three EIPs provide the foundations needed to support growing blob usage and the continued expansion of L2s.
Gas and optimizations
Increasing the block gas limit
The main gas-related change in Fusaka is EIP-7935 (Set Default Gas Limit to 60M), which raises the block gas limit from 36 to 60 million units, an increase of about 66 %. This directly allows more transactions to be included in each block.
This type of change is not new. In 2022, the limit doubled from 15 to 30 million gas per block. Earlier in 2025, it was raised from 30 to 36 million. These adjustments provide immediate on-chain scaling, at the cost of slightly higher hardware requirements for validators. The growth remains conservative compared to improvements in commodity hardware over the past few years.
Precompile for the secp256r1 curve
EIP-7951 is not strictly a gas optimization, but its importance is greater than it may appear. Precompiles are special contracts integrated into the protocol to perform common on-chain operations efficiently.
These tasks could be implemented in a regular smart contract, but that would be like repairing a car after first building your own tools. Precompiles act as a native toolbox that is simpler, more standardized and safer for both developers and users.
EIP-7951 adds a precompile for verifying ECDSA signatures using the secp256r1 elliptic curve. This type of signature is supported by secure hardware in many Android and Apple devices, as well as various hardware security keys.
With this precompile, signature verification can be implemented using more efficient code than existing approaches, reducing gas costs while improving security. It opens the door to smoother Ethereum integration across a wider range of devices with hardware security modules.
Other gas-related EIPs
Fusaka includes five additional EIPs that are directly or indirectly related to gas usage:
- EIP-7825: sets a maximum of 16.7 million gas per transaction (2^24) to reduce the risk of denial-of-service attacks
- EIP-7939: introduces a new opcode that counts the number of leading zeros in a 256-bit integer. This is useful for many mathematical operations and will reduce gas consumption in some contracts
- EIP-7823: sets a limit on the size of the input data passed to the MODEXP precompile, mainly to fix recurring bugs caused by overly long inputs
- EIP-7883: adjusts the gas cost model for MODEXP to ensure it always covers the real cost for validators
- EIP-7934: sets a maximum block size of 10 MB for propagation and acceptance on the network. This helps preserve decentralization by capping the amount of data that every node must receive and verify, and it also provides an extra layer of protection against denial-of-service attacks
Other improvements in Fusaka
Fusaka also contains three additional EIPs:
- EIP-7917: makes it possible to deterministically determine the proposers for the next epoch’s 32 blocks. Since EIP-7251 (MaxEB), the amount of ETH staked by a validator can exceed 32 ETH and change during an epoch. The proposer selection algorithm partially depends on stake variations in the previous epoch. EIP-7917 simplifies validator operations by giving them clear and predictable visibility on their upcoming roles
- EIP-7642: prunes some data from before The Merge, saving several hundred gigabytes of storage and bandwidth across the network. This does not delete the blockchain itself, but removes ancillary data that remains accessible through archive nodes
- EIP-7910: adds a new JSON-RPC method intended to reduce the risk of client desynchronization, an issue that had been observed during Pectra testing on the Holesky testnet
Conclusion
Fusaka’s main contribution is PeerDAS, a major advancement that should have a decisive impact on L2 scalability over the coming months, with the potential to increase blob capacity by several multiples.
Alongside this, the upgrade brings a collection of technical adjustments that have limited visible impact in the short term but collectively improve the network’s overall efficiency. Taken together, these EIPs reduce the operational burden on validators and support smoother, more linear scaling through gradual increases of the block gas limit.
