After the Pectra upgrade on Ethereum, the community’s attention has shifted to Fusaka, a follow-up upgrade that is considered critical for Layer 1 itself. This is not just a technical update but also a test to see how Ethereum will optimize performance and user experience in the coming phase.
This article will focus on the main changes in Fusaka, why it is being closely watched, and what it means for both users and developers.
What is Fusaka Upgrade?
Fusaka is the next major hard fork of Ethereum. This upgrade combines improvements at both the execution layer (inspired by Osaka in Japan) and the consensus layer (named after the star Fulu in Chinese astronomy).
Fusaka primarily focuses on scaling, improving network performance, and enhancing data handling capacity for Layer 2 (L2), without introducing major changes to user experience (UX) or staking like Pectra did.
With around 11 - 12 Ethereum Improvement Proposals - EIPs, Fusaka promises to multiply data capacity, reduce transaction costs on L2 to lower levels, and strengthen the decentralization of the network. This is part of the “The Surge” phase in Ethereum’s roadmap, aimed at boosting scalability through rollups, increasing user and transaction activity, and making it easier to run nodes.
Fusaka not only helps Ethereum compete better with other blockchains such as Solana or BNB Chain, but also lays the groundwork for further upgrades in the future like Verkle Trees or Stateless Ethereum.
The Fusaka Upgrade Details
The Fusaka upgrade includes 11 Ethereum Improvement Proposals (EIPs) with the goal of going deep into the technical infrastructure to address three core bottlenecks that are limiting Ethereum’s scaling potential:
- Increasing transaction throughput.
- Reducing storage burden for nodes.
- Improving the experience for decentralized application developers.
Below are some key EIPs that contribute to the innovations Ethereum will see in the Fusaka update.
Scaling and Data Availability
These EIPs focus on increasing data availability (DA) capacity for Layer 2 (L2) such as rollups, helping Ethereum process more transactions without reducing security or decentralization.
One of the most important upgrades in Fusaka is PeerDAS (EIP-7594), short for Peer Data Availability Sampling. This solution focuses on handling Blob data from rollups. Before Fusaka, Ethereum required nodes to download all Blob data to verify data availability.
This caused bandwidth and storage usage to grow quickly and became a scaling barrier, especially as more Layer 2 transactions depend on Blobs to post data to Ethereum.
PeerDAS changes this mechanism by allowing nodes to sample only part of the Blob data. Thanks to verification based on statistical methods, the network can still ensure that the full data is truly available without requiring every node to process everything. This is an important step on the path toward Danksharding, the full sharding solution that Ethereum has set in its long-term roadmap.
Thanks to PeerDAS, the number of Blobs per block will increase from 6 to 9, while the target Blobs per block parameter is adjusted down to 5 to keep costs more stable. This helps rollups post more data at lower cost, directly reducing fees users pay on Layer 2 networks and significantly expanding transaction throughput.
Besides EIP-7594, there are 2 other EIPs that also play an important role in scaling and improving DA.
EIP-7892 - “Light hard fork” that only adjusts blob parameters
Simply put, EIP-7892 gives Ethereum a very light-weight type of hard fork, used only to tweak three “knobs” related to Blobs:
- target: the desired average number of Blobs per block.
- max: the maximum number of Blobs allowed per block.
- baseFeeUpdateFraction: how fast Blob fees adjust up or down.
Instead of touching too much source code and complex logic, the network only needs to change these parameters to increase or decrease data availability (DA) capacity. Thanks to this, Ethereum becomes more flexible when L2 demand rises sharply, reduces risk for each upgrade, and adapts more easily to the ecosystem’s scaling speed.
EIP-7918 - Setting a “floor” for Blob fees
The current issue is that Blob fees can sometimes fall to very low levels (almost 0) while execution gas is much higher. EIP-7918 adds a “floor” to ensure Blob fees do not drop too far.
The idea is that if execution cost is still more expensive than the cost of a Blob, then the fee mechanism will stop treating Blobs as “excess” capacity. This keeps Blob fees stable around about 1/16 of execution fees, instead of dropping near zero and then spiking sharply afterward. This brings:
- More stable fees for L2, avoiding situations where fees are unusually cheap at times and then surge suddenly.
- Encouragement for more regular use of Blobs instead of only “taking advantage” when they are extremely cheap.
- Assurance that Blob users still pay part of the cost of verifying KZG proofs, which is especially important in Fusaka with PeerDAS and helps make Ethereum’s economics in the Surge phase more sustainable.
EIP-7935 and EIP-9678: Increasing the Gas Limit
This group of EIPs adjusts how gas fees and block size limits are calculated to increase throughput (number of transactions processed) while still limiting the risk of DoS attacks and keeping the network stable even as capacity is expanded.
DoS (Denial of Service) is a type of attack where someone deliberately “floods” the network with too many requests or data, creating spam transactions or consuming resources so that nodes cannot keep up, causing the network to slow down or stall.
Fusaka aims to increase Layer 1 transaction processing capacity through two important EIPs:
- EIP-7935 proposes increasing the gas limit per block from 36 million to 45 million.
- EIP-9678 targets 150 million, which is more than 4 times the current level.
The current Ethereum gas limit is around 30 million gas per block, with an average block time of 12 seconds, resulting in a maximum throughput of about 140 transactions per second.
This figure is not enough to meet growing demand. Fusaka introduces a roadmap to gradually increase the gas limit to 150 million gas per block, which is 4 times higher than today. If this target is reached, the theoretical throughput of Ethereum Layer 1 could increase to around 500 to 700 transactions per second, depending on the transaction type.
However, raising the gas limit is not purely beneficial and also comes with challenges. Larger blocks take more time to propagate between nodes, putting pressure on network synchronization.
Storage volume also grows quickly, requiring more resources to maintain a node. Therefore, EIP-7935 and EIP-9678 will be applied in stages with close monitoring in order to balance expansion goals with Ethereum’s long-term stability.
Verkle Trees: Lighter and smarter State management
Currently, Ethereum uses the Merkle-Patricia Tree to manage State (all data about accounts, smart contracts, tokens, and so on). This approach has worked well for many years, but:
- The number of accounts, contracts, and tokens keeps increasing.
- State data has become “bloated”.
- Full nodes have to store hundreds of GB of data.
This makes it very difficult for small users to run their own node if they only have a machine with modest specs. Verkle Trees are designed to solve this problem:
- They use commitment schemes to create very compact proofs.
- Nodes can verify data without storing the entire State.
- Storage requirements are reduced significantly.
- Verification is faster.
- Running a “light” node becomes more feasible.
This removes hardware barriers and makes it easier for more people to run nodes, which in turn makes the network more decentralized. Ethereum maintains its performance even as the number of users and applications continues to grow, and this is also an important step in the Verge phase of the roadmap, aiming for a network that is both decentralized and easy to operate in the long term.
EOF: Restructuring smart contract layout on the EVM
Firstly, it is important to recall how the EVM and its bytecode work. Ethereum uses the EVM as a core component of the network; smart contract code written in high-level languages such as Solidity must be compiled into EVM bytecode before it can run.
Today, on-chain EVM bytecode has no predefined structure. Code and data are mixed together in a single stream of instructions. In contracts like Uniswap, important constants such as fee parameters are embedded directly as raw data inside the same bytecode that contains the executable logic.
Every time a contract is executed, the EVM needs to interpret this monolithic bytecode and perform runtime checks to distinguish code from data. This repeated overhead makes contracts harder to analyze and optimize and also makes execution slower and more expensive.
Fusaka lays the groundwork to clean up this situation through EOF, the Ethereum Object Format. EOF introduces a new format for EVM bytecode that gives smart contracts an explicit layout.
Instead of one opaque block, a contract is split into well-defined sections such as header, code and data. This clearer structure makes it easier for clients and tooling to read and analyze contracts, standardizes gas accounting and reduces risk when new opcodes or features are added to the EVM in future upgrades.
EOF changes how bytecode is organized by:
- Splitting contracts clearly into sections: Header, Code, Data.
- Making it easier for both machines and humans to read, analyze, and optimize.
- Standardizing gas calculation, which reduces waste.
- Limiting risks when adding new opcodes to the EVM in the future.
In terms of implementation:
- EOF comes as a package of 12 EIPs that work together.
- If progress is smooth, this number could be expanded to 16 EIPs.
This is considered one of the deepest structural changes to the EVM, paving the way for smoother future upgrades and reducing challenges for developers.
Although EOF is currently planned to be included in the Fusaka hard fork, its final status is still uncertain due to concerns about complexity and possible delays. Developers emphasize that PeerDAS is being prioritized, and if necessary, EOF may be postponed to a later hard fork to keep Fusaka on schedule.
EIP-7951 (Support for secp256r1)
Fusaka also makes it easier for Ethereum to “talk” to the off-chain world. EIP-7951 adds support for the secp256r1 elliptic curve, which is widely used in enterprise operating systems and security hardware such as Apple Secure Enclave.
With a precompile for this algorithm, Ethereum will be more naturally compatible with wallets on iOS and Android, and it will be easier to integrate into systems such as supply chains, enterprise authentication, or digital identity management.
In addition, EIP-7939 adds the CLZ (Count Leading Zeros) opcode, focusing on improving arithmetic efficiency in smart contracts. Although it is not rated as highly as PeerDAS or Verkle Trees, this opcode is still practically useful: in some complex processing, especially in DeFi with large data volumes, it can save about 2–3% of gas costs.
What will Fusaka bring to Ethereum?
Fusaka focusing on the backend, while Pectra emphasizes the frontend:
- Pectra brings account abstraction, enabling smart wallets.
- Fusaka adds PeerDAS and Verkle Trees to support higher throughput for Pectra’s features.
- Together, they increase throughput and reduce costs, making Web3 more accessible.
Thanks to changes in gas limits on Layer 1 and more efficient data posting for Layer 2, Fusaka opens a new era of throughput for Ethereum.
- When the gas limit increases, the number of transactions Layer 1 can process per block also rises significantly.
- At the same time, PeerDAS allows rollups to write more data at lower cost, which can lead to an explosion in transaction volume on Layer 2.
- Taken together, Ethereum gets closer to the goal of handling thousands of transactions per second, a figure previously associated mainly with high-performance blockchains.
Higher throughput also comes with the story of lower fees, which has always been a common criticism of Ethereum.
- When the network can process more transactions, competition for block space decreases, which pushes average gas prices down.
- For rollups, PeerDAS significantly reduces data costs, so end users indirectly benefit from cheaper and more stable transaction fees.
- This is especially important for new users entering Web3, who are easily discouraged if they have to pay high fees just to try a simple action.
However, increasing throughput does not mean sacrificing stability. Fusaka also pays attention to keeping the network safe from spam and DoS-type attacks. Some proposals adjust gas limits per transaction or increase the cost of overly complex operations to make spamming harder and more expensive. When the number of transactions and on-chain activity grows, this protection layer helps Ethereum maintain smooth operations and avoid scenarios where the network is “choked” by excessive traffic or attacks.
In the long run, Fusaka also helps strengthen Ethereum’s decentralization by reducing the burden on node operators.
- Verkle Trees shrink state data, so more individuals can run nodes with moderate infrastructure, without needing extremely powerful hardware or very high storage costs.
- PeerDAS spreads the data load across more components in the network, making participation in validation lighter.
- As more people are able to run their own nodes, the network becomes less dependent on a small group of validators or large infrastructure providers, and that is the foundation for an Ethereum that is strong, open, and resistant to centralization.
Conclusion
Fusaka marks a phase where Ethereum shifts from mainly “polishing” user experience to upgrading the core of the system. Instead of focusing only on smart wallets or on-chain interactions, Fusaka targets three main pillars:
- Increasing the number of transactions the network can process.
- Reducing storage pressure on nodes.
- Creating a more comfortable environment for dApp builders.
If Pectra is seen as the upgrade that activates more usage demand for Ethereum, then Fusaka plays the role of the infrastructure layer that makes the network strong enough to handle that load, bringing Ethereum closer to the standard of a high-performance blockchain without sacrificing decentralization.
FAQs
Q1. How is Fusaka different from Pectra?
Pectra focuses more on the “frontend” side with features like account abstraction and smart wallets, while Fusaka concentrates on the “backend”, boosting throughput, improving data availability and reducing node burdens through changes like PeerDAS, higher gas limits and Verkle Trees.
Q2. Will Fusaka immediately change my everyday UX on Ethereum?
For most users, Fusaka’s impact will be indirect. You may mainly feel it through cheaper, more stable fees on Layer 2 and smoother on-chain activity, rather than big visible changes in wallet interfaces or how you sign transactions.
Q3. Why is PeerDAS such a big deal for Layer 2 rollups?
PeerDAS lets nodes sample only parts of Blob data instead of downloading everything. This allows many more Blobs per block without overwhelming bandwidth and storage, so rollups can post more data at lower cost, which helps cut fees and increase throughput on L2.
Q4. What problem do Verkle Trees actually solve?
Verkle Trees are designed to shrink Ethereum’s state and make proofs more compact. They help full nodes store less data and verify faster, so more people can run nodes on modest hardware. This supports both scalability and decentralization at the same time.
Q5. Are there risks in raising the gas limit so much?
Yes. Larger blocks can be slower to propagate and require more storage, which adds pressure on node operators and sync times. That is why EIP-7935 and EIP-9678 are planned to roll out gradually and be monitored closely instead of jumping straight to the maximum target.