How the Fusaka Upgrade is Scaling Ethereum for the Next Wave of Onchain Activity
A detailed guide to the Ethereum Fusaka upgrade covering all 12 EIPs and their impact on scalability, cryptography, gas rules, and validator operations.
The Ethereum Fusaka upgrade is the next major coordinated Ethereum hard fork that combines changes to both the execution layer and consensus layer. Fusaka brings together the Osaka execution layer updates with the Fulu consensus layer updates, forming one of the most comprehensive protocol upgrades in recent years. It is already running on testnet and is projected to activate on Ethereum mainnet on December 3, 2025.
Fusaka follows the broader roadmap toward more scalable data availability and prepares the network for future Danksharding. It introduces changes to blob handling, cryptographic primitives, gas and execution rules, and validator coordination. Developers will see updated fee markets, new precompiles, new proof formats for Layer 2s on Ethereum, and better predictability in block production.
Table of Contents
- What Is the Ethereum Fusaka Upgrade
- Why the Ethereum Fusaka Upgrade Matters
- Fusaka EIPs Overview
- Data Availability and Scalability
- Cryptography and Math Primitives
- Gas and Execution Changes
- Validator Coordination and History Improvements
- How the Fusaka Upgrade Works in Practice
- Common Questions About the Ethereum Fusaka Upgrade
- Final Thoughts
- About OnFinality
What Is the Ethereum Fusaka Upgrade
Fusaka is a combined upgrade that merges two naming traditions. The Fulu component represents consensus layer changes and takes its name from a star. The Osaka component represents execution layer updates and takes its name from a previous Devcon location. Together they introduce twelve Ethereum Improvement Proposals (EIPs) across four categories:
• Data availability and scalability
• Cryptography and math improvements
• Gas and execution changes
• Validator and history management updates
Each category addresses different bottlenecks in Ethereum’s architecture. Fusaka is designed to make data storage more efficient, reduce node load, modernise signature verification, and create a more predictable environment for rollups and validators.
Why the Ethereum Fusaka Upgrade Matters
Fusaka addresses real scalability and sustainability issues:
• Higher blob throughput and lower L2 data cost
• A sampling based availability check that reduces node workload
• Modern authentication primitives for enterprise and consumer use cases
• More predictable gas markets for complex math operations
• Reduced long term storage requirements for nodes
• Better validator coordination and proposer predictability
Fusaka marks a transition from a single blob capacity model to a dynamic data system that can scale safely through parameter changes.
Fusaka EIPs Overview
Fusaka includes twelve EIPs:
• EIP 7594 PeerDAS
• EIP 7892 Blob Parameter Only Hard Forks
• EIP 7918 Blob Base Fee Bounded by Execution Cost
• EIP 7939 CLZ Opcode
• EIP 7951 secp256r1 Precompile
• EIP 7823 MODEXP Bound
• EIP 7883 MODEXP Gas Cost Increase
• EIP 7825 Transaction Gas Limit Cap
• EIP 7934 RLP Block Size Limit
• EIP 7935 Default Gas Limit 60M
• EIP 7917 Deterministic Proposer Lookahead
• EIP 7642 History Expiry and Simplified Receipts
Below is an expanded explanation of each one.
Data Availability and Scalability
Ethereum’s data layer gets its biggest improvement since EIP 4844. Fusaka introduces PeerDAS, flexible blob parameter adjustments, and a more stable fee market for data posting. These changes allow Ethereum to scale blob throughput safely, reduce node burden, and prepare the protocol for future Danksharding.
EIP 7594: Peer Data Availability Sampling (PeerDAS)
PeerDAS is the most important component of Fusaka and a foundational step toward a sharded data system. It updates the way Ethereum verifies blob availability, allowing the network to scale data throughput without increasing the burden on individual nodes.
The problem with the pre Fusaka model
Under EIP 4844, nodes verify availability by downloading entire blobs. This approach limits blob capacity because each participating node must handle the full blob size. As the network grows, the cost of data propagation becomes a major bottleneck.
How PeerDAS changes the model
PeerDAS introduces a sampling based verification method. Instead of downloading entire blobs:
• Nodes request small random data segments called samples
• Samples are pulled from different peers
• Nodes independently verify these segments
• If enough correct samples are accessible to enough nodes, the blob is considered fully available
This method distributes the verification workload across the network. A node no longer needs to handle complete blobs to contribute to data availability.
Why sampling works
Sampling works because of erasure coding and the statistical reliability of randomly checked segments. If data is available, peers can respond to random sample requests. If data is unavailable or withheld, nodes quickly detect inconsistencies. The approach allows Ethereum to scale blob capacity by increasing the number of encoded fragments without increasing per node bandwidth requirements.
Developer impact
PeerDAS introduces new responsibilities:
• Nodes must store encoded pieces temporarily
• Nodes must answer sample requests from peers
• Nodes propagate segments instead of full blobs
Most importantly, PeerDAS replaces blob proofs with a new format called cell proofs. This is a breaking change for:
• Rollup sequencers
• DA pipelines
• Blob transaction publishers
• Tools that prepare blobs off chain
Rollups must update their encoding, proof generation, and publishing processes before mainnet activation.
The long term importance of PeerDAS
PeerDAS brings Ethereum closer to the data sharding model described in the Ethereum roadmap. It enables larger blob capacity and allows future increases through parameter updates, not hard forks. Rollups should expect much larger posting capacity at lower cost after adoption.
EIP 7892: Blob Parameter Only Hard Forks
Previously, any adjustment to blob limits required a full coordinated hard fork. EIP 7892 introduces a new mechanism that allows blob related parameters to be updated independently. These lighter changes are known as Blob Parameter Only hard forks.
This allows Ethereum to increase or decrease blob capacity more frequently and safely. Rollups can expect a more stable fee curve because changes can align with real usage rather than waiting for large upgrade cycles.
EIP 7918: Blob Base Fee Bounded by Execution Cost
Blob fees are part of a separate fee market from execution gas. Under certain conditions blob fees could fall near zero if blob usage was low, even when execution demand was high. This created misalignment and could underprice the data availability layer.
EIP 7918 introduces a reserve price for blob gas that depends on execution gas conditions. This ensures blob fees cannot collapse entirely and keeps the fee market functional and predictable.
Cryptography and Math Primitives
Ethereum’s cryptographic toolbox is getting a significant upgrade in Fusaka. These changes introduce faster low level arithmetic operations and native support for widely used signature schemes. Developers working with verification heavy logic and secure authentication flows will see meaningful performance and usability improvements.
EIP 7939: CLZ Opcode (Count Leading Zeros)
The CLZ opcode returns the number of leading zeros in a 256 bit word. Before this addition, developers relied on loops in Solidity to perform bit scanning or log scale operations. These loops are expensive and slow.
CLZ enables:
• Faster log2 calculations
• Normalization in arithmetic operations
• Efficient randomness and bitmask operations
• Lower gas usage for math heavy DeFi or rollup contracts
This addition improves performance across a wide range of low level operations.
EIP 7951: secp256r1 Precompile
EIP 7951 adds native verification support for the secp256r1 elliptic curve, also known as P 256. This curve is widely used across modern authentication systems including:
• WebAuthn
• FIDO2 hardware keys
• Browser based signature systems
• Enterprise security modules
Previously, verifying P 256 signatures required off chain validation or custom EVM math libraries, both of which introduce cost and complexity. With this precompile, developers can integrate passwordless authentication and secure hardware based signing directly on chain.
Gas and Execution Changes
Fusaka updates several core execution rules to improve predictability, strengthen DoS resistance, and expand block capacity. These changes refine how complex computations are priced, set clearer execution boundaries, and increase the total space available for transactions. Applications with heavy computation or batching logic will notice more consistent performance.
EIP 7823 and EIP 7883: MODEXP Bound and Gas Increase
These two EIPs update the MODEXP precompile by capping input size and adjusting gas costs. Modular exponentiation is one of the most expensive operations in on chain cryptography. Underpriced calls could expose Ethereum to resource based denial of service risks.
The updated rules ensure that cryptographic verification involving large exponentiation is priced correctly and processed consistently across clients.
EIP 7825: Transaction Gas Limit Cap
This EIP sets a hard upper limit on how much gas a single transaction can consume. Without such a cap, a single transaction could theoretically fill an entire block, causing slot timing issues or delaying other transactions.
Developers building batch operations or complex multi stage logic must ensure execution fits within the new per transaction boundary.
EIP 7934: RLP Block Size Limit
EIP 7934 adds an upper limit to the RLP encoded block size. This helps reduce propagation delays and keeps block size more consistent across the network. Client implementations become easier to optimise because they no longer need to handle unbounded RLP encoded blocks.
EIP 7935: Block Gas Limit Increased to 60 Million
Fusaka raises the default block gas limit to 60 million. This expansion increases available block space for:
• Larger rollup batches
• Complex contract interactions
• Data heavy state updates
It supports the growth of Layer 2 ecosystems and applications that depend on batching large amounts of data.
Validator Coordination and History Improvements
The upgrade brings important enhancements for validators and node operators by improving proposer visibility and reducing long term data storage requirements. These changes create a more stable builder ecosystem and lighten node operation overhead. Both stakers and infrastructure providers gain a smoother, more efficient workflow under the new rules.
EIP 7917: Deterministic Proposer Lookahead
Under the previous model, validators had limited visibility into upcoming proposers. EIP 7917 introduces deterministic proposer lookahead, allowing validators to know future proposers several slots ahead.
This improves:
• Block builder coordination
• Relay efficiency
• MEV smoothing
• Reorg resistance
Builders and relays can now prepare bundles with more stability.
EIP 7642: History Expiry and Simplified Receipts
State size continues to grow as the blockchain expands. EIP 7642 introduces history expiry, allowing nodes to prune old chain data after a standard retention window. It also simplifies the structure of transaction receipts, making them easier to decode and store.
Node operators benefit from reduced disk usage and faster client sync. Applications that require old receipts must rely on archival service providers once expiry is active.
How the Fusaka Upgrade Works in Practice
Fusaka requires coordinated changes across multiple parts of the Ethereum ecosystem:
• Node operators must upgrade their clients to versions that support PeerDAS, cell proof handling, new gas rules, and new proposer lookahead logic.
• Rollups must update their blob transaction pipeline to generate cell proofs instead of blob proofs.
• Wallets and dApps using WebAuthn or hardware based authentication can integrate native secp256r1 verification.
• Infrastructure providers, explorers, and indexing systems must adjust for new block size limits, new receipts, and PeerDAS sampling behaviour.
The development experience becomes more predictable as the fee market stabilises and as the network supports larger data throughput.
Common Questions About the Ethereum Fusaka Upgrade
When will Fusaka activate on mainnet
Fusaka is live on testnet and is targeting a mainnet activation date of December 3, 2025.
How does PeerDAS affect rollups
PeerDAS requires rollups to use cell proofs. Sequencers and DA pipelines must update their blob publishing tools. Rollups can expect higher blob capacity and lower data posting cost after implementation.
What changes for wallets
Wallets that already support WebAuthn or FIDO2 can now perform signature verification directly using the new secp256r1 precompile.
How will gas fees change
Blob fees become more predictable and execution costs become more stable due to updated gas schedules. Some cryptographic operations may cost more due to corrected MODEXP pricing.
Final Thoughts
The Ethereum Fusaka upgrade is one of the most comprehensive updates in the network’s evolution. It improves data scalability, modernises signature verification, refines the fee market and reduces storage pressure on nodes. Developers building rollups, DA systems, authentication flows, or performance critical smart contracts should begin testing on the Fusaka testnet and ensure their infrastructure is ready for the shift to cell proofs and the new gas environment.
About OnFinality
OnFinality is a blockchain infrastructure platform that serves hundreds of billions of API requests monthly across more than 130 networks, including Avalanche, BNB Chain, Cosmos, Polkadot, Ethereum, and Polygon. It provides scalable APIs, RPC endpoints, node hosting, and indexing tools to help developers launch and grow blockchain networks efficiently. OnFinality’s mission is to make Web3 infrastructure effortless so developers can focus on building the future of decentralised applications.