The Fusaka upgrade is Ethereum’s answer to the growing demand from its Layer 2 ecosystem, which now processes over 530 million transactions monthly with a combined TVL of $39.4 billion. Scheduled for December 3, 2025, at 21:49:11 UTC, Fusaka is the biggest upgrade after Dencun, and it will forever change how Ethereum handles data availability for its ecosystem of rollups.
Through innovative technologies like PeerDAS (Peer Data Availability Sampling) and Blob-Parameter-Only (BPO) forks, Fusaka will enable Ethereum to scale data throughput by up to 16x while maintaining and in some cases reducing hardware requirements for home validators. And as Layer 2 networks continue to push the boundaries of what’s possible on Ethereum, Fusaka provides the infrastructure needed to support billions of users while preserving the network’s core principles of decentralization and security.
Before we start: Here is a history of previous upgrades to Ethereum
What Fusaka Actually is?
The name Fusaka combines two components:
- Fulu: the consensus layer upgrade, named after a star. and
- Osaka: the execution layer upgrade, named after a Devcon location.
If we want to add meaning to this naming convention, I would say it reflects Ethereum’s practice of celebrating both the technical and community aspects of its development.
The rollout timeline is carefully scheduled to maximize safety and ensure network stability. Prior to mainnet deployment, Fusaka underwent extensive testing across Holesky, Sepolia, and Hoodi testnets throughout October 2025.
The mainnet upgrades are also getting rolled out in phases:
- December 3, 2025: Fusaka mainnet activation at 21:49:11 UTC
- December 9, 2025: BPO1 (Blob Parameter Only fork 1) – increases blob target to 10, maximum to 15
- January 7, 2026: BPO2 – further increases blob target to 14, maximum to 21
This allows the network to monitor performance and stability before implementing additional capacity increases. The client release window opened on November 3, and gives node operators a full 30 days’ time to upgrade their systems before the mainnet activation.
The Scope of Fusaka Upgrade
Fusaka introduces 12 Ethereum Improvement Proposals (EIPs) to improve data availability scaling, L1 performance, security & efficiency, and network optimization. The below mind map gives at a glance which EIP is for what.
The biggest upgrades are EIP 7594 and EIP 7892, which introduce Peer Data Availability Sampling and Blob Parameter Only Hardfork to Ethereum. Let’s break down what they bring and how they do it.
PeerDAS (EIP-7594) and The Problem It Solves
The central promise of Ethereum’s rollup-centric roadmap is that L2s can provide massive scale while borrowing the security of the L1. To settle on Ethereum, a rollup posts all the data needed to reconstruct the new state change in a blob.
A blob is a piece of data that is stored temporarily by the nodes of the Ethereum network.
Without access to the full state, it is not possible for users to force withdrawals, as they can’t make the necessary proofs.
Before Fusaka, every Ethereum node had to download and store every blob to verify data availability. Currently, blobs are replicated across all nodes of the network with Proto-Danksharding (EIP-4844). This is not scalable, as it currently only targets 31 KB per second.
This model created a fundamental scaling bottleneck. While it ensured robust data availability, it meant that increasing blob capacity would proportionally increase the bandwidth and storage requirements for every validator on the network, which means potentially pricing out home stakers and centralizing the validator set.
How PeerDAS Works?
PeerDAS is the 1st step towards full danksharding. It does data sharding. This means blob data is split across different nodes, so each node does not need to store all the data.
1.Erasure Coding: First, blobs are now erasure-coded. It is split into 8 cells: 4 of them for the original blob and 4 for extra data that can reconstruct it. This is called Reed-Solomon erasure coding. This allows the entire blob to be reconstructed from just 50% of its original pieces.
2.Sharding: The expanded blob is split into 128 smaller pieces called columns or cells.
3. Distribution: These pieces are distributed across groups of nodes called subnets. A regular node no longer downloads the entire blob. Instead, a validating node might only be responsible for custodying 8+ of these 128 columns (about 1/8th of the data).
4. Sampling (DAS): To confirm the entire blob is available, nodes “sample” the network by randomly asking peers for a few small pieces. If they can successfully retrieve all the pieces they ask for, it provides an extremely high statistical guarantee (with a failure probability as low as 1 in 10^20–10^24) that the full 50% of data is available to reconstruct the block.
If a node consistently fails to provide data when requested, nodes which refuse may be sentenced by a jury of their peers to 5 years in prison. By that, I mean nodes which consistently don’t provide the data asked of them will just be blacklisted by other nodes as unreliable.
PeerDAS is crucial for Layer 2 operators because:
EIP-7594 (PeerDAS) changes the proof format from blob proofs to cell proofs. Blob transaction originators (L2s, etc.) must update their software to create Cell Proofs instead of blob proofs. This change may break applications that send blob transactions.
Layer 2 teams must update their transaction submission infrastructure before the Fusaka activation to avoid any disruption.
Blob Parameter Only (BPO) Forks (EIP-7892):
Blob Parameter only Fork complements PeerDAS by enabling incremental blob scaling without full hard forks, which fundamentally change how Ethereum can respond to changing data availability demand.
Historically, changing a core network parameter like the target number of blobs required a full-scale, complex hard fork, and any rule change of this kind must follow a coordinated upgrade where every node, client, and validator software upgrades before the same predetermined block. This takes months to complete.
In order to adapt faster to changing layer 2 blob needs, blob parameter only forks introduce a mechanism to increase blobs without having to wait on that upgrade schedule. Blob parameter only forks can be set by clients, similarly to other configurations like gas limit.
This means: These blob parameters only forks can be configured at any time. Even between major Ethereum upgrades, clients can agree to increase the target and max blobs, and then node operators will update to take part in that tiny fork. The Planned BPO Schedule:
When blobs were first added to the network in the Dencun upgrade, the target was 3. That was increased to 6 in Pectra and, after Fusaka, that can now be increased at a sustainable rate independently of these major network upgrades.
The post-Fusaka BPO schedule is already planned:
- Fusaka (Dec 3): Target 6 blobs, Max 9 (no change from Pectra).
- BPO 1 (Dec 17): Target 10 blobs, Max 15.
- BPO 2 (Jan 7, 2026): Target 14 blobs, Max 21.
So, by early 2026, Ethereum’s blob capacity will have more than doubled, with a clear path to continue scaling. Once the data is collected and analyzed from BPO1 and BPO2, core developers will proceed with more aggressive scaling for BPO3 and BPO4 with the aim of reaching 128 Blobs per block.
EIP 7918 will fix the Blob Fee Market also:
The blob fee market has an economic flaw. L2s pay for two things:
- the blob fee (for data) and
- the execution gas (for verifying the blob).
When L1 execution gas prices spike, the blob fee market mistakenly thinks there is low blob demand and drops the blob price, often all the way down to 1 wei. This breaks the price discovery mechanism and makes blobspace unsustainably cheap.
EIP 7918 introduces a bounded blob base fee (reserve price) for blobs by tying their minimum fee to the L1 execution gas cost ( a minimum of 8192 gas). This ensures blobs always have a meaningful cost that reflects the compute power needed to verify them, like KZG proofs, and prevents the fee market from collapsing to 1 wei.
Because when the reserve is higher than the nominal blob base fee, the fee adjustment algorithm treats the block as over target and stops pushing the fee down, and allows it to increase normally.
This creates a more stable and predictable cost structure for Layer 2 operators and ensures Ethereum is fairly compensated for the computational resources consumed.
While L2 scaling is most highlighted, Fusaka also includes EIPs to increase Ethereum L1 capacity
The first 3 are overall performance improvements:
- Increasing the Block Gas Limit to 60 Million (EIP-7935)
The Gas limit was set to 30M after Merge in Sep 2022, and it stayed there for over 2 years. In Feb 2025, it was first increased to 36M, and later it was upgraded to 45M, where it currently is. Fusaka will raise this to 60 million. This is a ~33% increase in L1 execution capacity and allows more transactions and computations to fit into each block with reduced mainnet gas fee spikes.
2.Transaction Gas Limit Cap (EIP-7825)
To safely increase the block gas limit, this EIP introduces a cap on any single transaction at 16,777,216 gas (2²⁴). This is the worst-case cost of any single transaction.
This prevents a single, massive transaction from consuming an entire block, which could cause network instability or create a vector for Denial of Service (DoS) attacks.
Why exactly 2^24 gas? Because it’s comfortably smaller than today’s gas limit, is large enough for contract deployments & heavy precompiles, and a power of 2 makes it easy to implement across clients. This new maximum transaction size is similar to pre-Pectra average block size and is a reasonable limit for any operation on Ethereum.
3. RLP Execution Block Size Limit (EIP-7934)
This EIP introduces a hard cap of 10 MiB on the total size of an execution block sent over the network with a small allowance (2 MiB) reserved for consensus data so that everything fits and propagates cleanly.
This prevents oversized blocks from slowing down network propagation, reducing the risk of forks and DoS risks. Also, the consensus layer’s gossip already won’t forward blocks over ~10 MiB, so aligning the execution layer to that limit avoids weird ‘seen by some, dropped by others’ situations.
Security & Efficiency Improvements:
4. MODEXP Precompile Optimization (EIP-7823 & EIP-7883)
The MODEXP (modular exponentiation) precompile which is used for cryptographic operations like RSA signature verification
has been a source of consensus bugs and DoS risks because it was underpriced for certain inputs.
- EIP-7883 Increase Gas Cost
MODEXP was a major obstacle to increasing the block gas limit because the current gas pricing often underestimates how much computing power certain inputs require.
This EIP changes the pricing to match real computational costs by raising the minimum charge from 200 to 500 gas and removing the one‑third discount from EIP-2565 on the general cost calculation. This increases the cost more sharply when the exponent input is very long and charges a large base or modulus extra as well.
- EIP-7823 sets upper bounds
Until now, the MODEXP precompile accepted numbers of virtually any size. That made it hard to test, easy to abuse, and risky for client stability. EIP-7823 puts a clear limit. Now each input number can be at most 8192 bits (1024 bytes) long, which is large enough for all practical use cases (like RSA verification) but removes the risky, unbounded edge cases.
Based on an analysis of all of Ethereum history, this change also shouldn’t affect transactions whatsoever as the largest successful input lengths were all below 513 bytes.
The below EIP does network and infrastructure optimization.
5. Faster Node Syncing from History Expiry (EIP-7642)
In July 2025, Ethereum execution clients began to support partial history expiry. This dropped history older than the Merge in order to reduce the disk space required by node operators.
This modification to EL changes how receipts are handled by removing the bloom field from receipts. This has saved approximately 530GB of bandwidth during a node’s initial sync.
Clients can implement this any time because this fork doesn’t implement any new changes in this but adding it to the upgrade concretely put it on their to-do list.
What Fusaka Means for L2s, Users and individual node operators?
These technical changes will have tangible effects across the entire ecosystem of L2 chains and end users of multiple apps.
For L2s this is huge.
L2s like Arbitrum, Optimism, Base, ZKsync, are the primary consumers of blobspace, and their biggest operational cost is posting data to L1.
Fusaka will bring:
- Drastically Lower Fees: With 2-3x more blobspace by early 2026 (and 20x+ in the future), L2 transaction costs are expected to drop by 50-90%.
- Massive Throughput: L2s like Base are projecting they can reach 10,000-20,000 TPS.
The entire combined L2 ecosystem could scale from its current ~5,600 TPS to over 24,000 TPS.
BPO forks give L2s a predictable roadmap for growth and ensuring L1 data capacity can keep pace with their user adoption.
For various dApp Users:
- Sub-Cent Transactions: DeFi swaps, NFT mints, and gaming actions on L2s will become reliably sub-cent.
- Faster Finality: Users will see confirmation times on active rollups drop to 5-10 seconds.
- New Applications: Cheaper data will enable new categories of on-chain applications more viable, such as fully on-chain games, social media, and micro-payment systems that were previously unviable.
What if you’re a Staker & Node Operator?
Fusaka is intelligently designed to scale capacity without excluding home stakers. PeerDAS changes bandwidth requirements based on your role. For example:
Full Nodes (Non-Validating): Will only need to subscribe to 4 subnets (1/32nd of the data). Bandwidth needs will be minimal, around ~8 Mb/s.
Solo Stakers (e.g., 32 ETH): Will subscribe to 8+ subnets (1/8th of the data). Even at the BPO2 level (14 target blobs), bandwidth requirements are estimated to be ~17-25 Mb/s, well within the recommended specs for home stakers. Their disk usage and download bandwidth for blobs could decrease by 50% or more compared to pre-Fusaka.
Supernodes (≥4,096 ETH): These large operators will custody all 128 columns, forming the network’s backbone. They will see bandwidth peaks of 200-400 Mb/s and may need to plan for higher resource usage.
Why Enterprises will Launch More L2s now?
Fusaka is indeed a major upgrade for corporate adoption. It bridges the gap between crypto-native tech and enterprise-grade requirements with the followings:
Compatibility with Banking Standards (EIP-7951: secp256r1)
This is arguably the most significant update for institutions. Ethereum now natively supports the secp256r1 cryptographic curve via a precompile.
This curve is the industry standard for traditional Hardware Security Modules (HSMs), Apple’s Secure Enclave, and FIDO2 (Passkeys).
So, banks and custodians can now use their existing, certified HSM infrastructure to sign Ethereum transactions directly. There is no need for wrapper code or custom hardware to manage Ethereum’s specific secp256k1 keys.
This will simplify compliance and key management for institutional treasuries.
The massive increase in blob capacity and the drop in data costs will benefit Enterprises.
They can launch their own private L2s or L3s app-chains for internal settlement, supply chain tracking (Digital Product Passports), or tokenized assets.
Operating these private chains becomes a fraction of the current cost, as the rent paid to Ethereum for security via blobs drops by an estimated 50-90%.
We’re Pretty Good with Nodes, Infrastructure and Launching Custom Chains
Fusaka took one more step to position Ethereum as the universal settlement layer for global finance and decentralized infrastructure. However, to leverage these new capabilities you will need robust, enterprise-grade tooling. This is where Zeeve’s ISO, SOC 2 Type II, and GDPR compliant platform steps in.
We help enterprises to capitalize on Fusaka’s scaling benefits immediately. Whether you are looking to launch a custom L2 or L3 chain (using Arbitrum Orbit, ZK Stack, OP Stack or Polygon CDK) or require reliable node infrastructure, we handle the complexity so you can focus on your product.
Don’t just watch Ethereum scale! Scale with it. Contact Zeeve today to launch your custom chain or deploy your dedicated nodes.
