{"id":1766,"date":"2026-07-09T21:09:30","date_gmt":"2026-07-09T21:09:30","guid":{"rendered":"https:\/\/nownodes.io\/blog\/?p=1766"},"modified":"2026-07-09T21:22:19","modified_gmt":"2026-07-09T21:22:19","slug":"ethereums-fusaka-hard-fork-why-december-2025-will-be-a-turning-point","status":"publish","type":"post","link":"https:\/\/nownodes.io\/blog\/ethereums-fusaka-hard-fork-why-december-2025-will-be-a-turning-point\/","title":{"rendered":"Ethereum Fusaka Upgrade: What It Changed & What’s Next"},"content":{"rendered":"

Ethereum Fusaka Upgrade Explained: What Changed, What It Did, and What Comes Next<\/h1>\n\n\n

Fusaka is live. Ethereum’s biggest data-scaling upgrade since Dencun activated on mainnet on December 3, 2025, and by early January 2026 the network had already tripled its blob capacity through two follow-up mini-forks. If you searched for a “Fusaka launch date,” that moment has passed \u2014 so this guide covers what the upgrade actually delivered, the numbers behind it, and how it changes what you build on.<\/p>\n\n\n\n

The short version: Fusaka introduced PeerDAS, a smarter way for nodes to check that Layer 2 data is available without downloading all of it, plus a new mechanism to raise capacity in small, safe steps. The result is cheaper rollup transactions and a base layer prepared for far higher throughput. Here’s how each piece fits together, starting from the ground up.<\/p>\n\n\n

What Is the Ethereum Fusaka Upgrade?<\/h2>\n\n\n

Fusaka is a hard fork \u2014 a coordinated, backward-incompatible change to Ethereum’s protocol that every node must adopt to stay on the canonical chain. It shipped as Ethereum’s second major upgrade of 2025, following Pectra in May, and continues the network’s long scaling arc from the Merge (2022) through Dencun (2024).<\/p>\n\n\n\n

The name follows Ethereum’s convention of pairing two upgrades that ship together. “Fulu” refers to the consensus-layer changes, named after a star; “Osaka” covers the execution-layer changes, named after the city that hosted a recent Devcon. Combine them and you get \u2014 one upgrade, two layers moving in tandem.<\/p>\n\n\n\n

What makes Fusaka distinct from user-facing upgrades is its focus. It re-engineers how the network handles the data that Layer 2 rollups post to Ethereum \u2014 the plumbing beneath the fees you actually pay. That backend focus is exactly why its impact took a few weeks to show up on-chain rather than landing all at once.<\/p>\n\n\n\n

\n

Hard fork:<\/strong> a protocol change that isn’t backward-compatible, requiring all node operators to update their software. Nodes running old versions get disconnected from the network at the fork block. See the Ethereum Foundation’s Fusaka overview<\/a> for the full technical scope.<\/p>\n<\/blockquote>\n\n\n

Why Ethereum Needed Fusaka: The Blob Bottleneck<\/h2>\n\n\n

To see why it mattered, you have to go back to Dencun in March 2024. That upgrade introduced blobs<\/strong> \u2014 temporary data containers where rollups like Arbitrum, Optimism, and Base post their transaction data cheaply, then have it discarded after roughly 18 days. Blobs cut Layer 2 fees dramatically, in many cases by 90% or more.<\/p>\n\n\n\n

The problem was success. As rollup activity grew through 2024 and 2025, the ecosystem kept bumping against Ethereum’s blob ceiling. Before Fusaka, the network handled a target of 6 blobs per block with a maximum of 9 \u2014 and during peak usage, L2s were saturating that space, pushing fees back up. The cheap data lane was filling faster than it could grow.<\/p>\n\n\n\n

The obvious fix \u2014 just raise the blob limit \u2014 carried a hidden cost. Under the old design, every full node had to download every blob<\/strong> to confirm the data was available. Doubling or tripling blob capacity would have doubled or tripled the bandwidth and storage burden on ordinary nodes, quietly pricing out home stakers and pushing the network toward centralization. Ethereum needed a way to scale data without<\/em> making nodes heavier. That’s the puzzle PeerDAS solves.<\/p>\n\n\n

How Fusaka Works: The Core Changes<\/h2>\n\n\n

Fusaka bundled roughly 12 Ethereum Improvement Proposals (EIPs). Most are quiet efficiency and safety tweaks, but three changes carry the weight of the upgrade. Here’s each one, from the headliner down.<\/p>\n\n\n

PeerDAS (EIP-7594): Sampling Instead of Downloading<\/h3>\n\n\n

PeerDAS \u2014 Peer Data Availability Sampling \u2014 is Fusaka’s flagship. Instead of forcing every node to store every blob, it splits blob data into columns and distributes them across the network, so each full node custodies only about one-eighth<\/strong> of the total data.<\/p>\n\n\n\n

The clever part is the guarantee. Any portion of the data can be reconstructed from any existing 50% of the whole, which drives the probability of missing or fraudulent data down to a cryptographically negligible level. Nodes verify availability by sampling<\/em> small slices from their peers rather than downloading everything \u2014 which is why the upgrade’s mascot is a zebra, its stripes echoing PeerDAS’s column-based structure.<\/p>\n\n\n\n

The bandwidth savings are substantial. For a home validator, PeerDAS cuts the blob data they need to download by roughly 85%<\/strong> \u2014 one CoinGecko analysis put it at a drop from around 750 MB of blob data per day to about 112 MB. That reduction is what makes scaling blob capacity safe: you can add far more data lanes without asking solo stakers to move into a data center.<\/p>\n\n\n\n

\n

Data availability sampling:<\/strong> a method of confirming that data exists and is retrievable by checking small random samples rather than downloading the full set. It underpins Ethereum’s long-term path toward full Danksharding. Details in EIP-7594<\/a>.<\/p>\n<\/blockquote>\n\n\n

Blob Parameter Only Forks (EIP-7892): A Dial, Not a Fork<\/h3>\n\n\n

The second key change is procedural but powerful. Historically, raising blob capacity meant waiting 12 to 18 months for the next full hard fork. EIP-7892 introduced Blob Parameter Only (BPO) forks<\/strong> \u2014 lightweight, config-only upgrades that adjust the blob target and maximum without touching anything else in the protocol.<\/p>\n\n\n\n

Think of it as a dial rather than a switch. Alex Stokes of the Ethereum Foundation described the design on the EthStaker launch livestream: developers could<\/em> have turned capacity up 8x instantly, but chose not to. As he put it on the stream, sampling is a very new technique and cranking the dial to maximum on day one would not be the wisest decision. BPO forks let the network step capacity up in measured increments, watching telemetry between each move.<\/p>\n\n\n\n

The BPO model came directly out of the Layer 2 world \u2014 OP Labs engineers proposed it, and it shipped as EIP-7892. That origin matters: it’s a scaling mechanism designed by the teams whose rollups depend on the extra capacity.<\/p>\n\n\n

The 60M Gas Limit and Safety Caps (EIP-7935 and friends)<\/h3>\n\n\n

Fusaka also raised the default block gas limit target to 60 million<\/strong>, up from 36 million \u2014 a coordinated client setting rather than a hard rule, letting the base layer fit roughly 20\u201330% more computation per block. Paired with that increase are several safety EIPs: a per-transaction gas cap of about 16.7 million gas (2\u00b2\u2074) so no single transaction can hog a block, and a strict block-size limit to prevent oversized blocks from slowing propagation. Capacity up, abuse vectors down.<\/p>\n\n\n

The Numbers: What Fusaka Delivered by January 2026<\/h2>\n\n\n

This is where the refresh matters most \u2014 the upgrade didn’t finish on day one. Fusaka rolled out as three sequential events<\/strong> over 35 days, each dependent on the last landing cleanly.<\/p>\n\n\n\n

Event<\/th>Date<\/th>Blob target<\/th>Blob max<\/th><\/tr><\/thead>
Fusaka mainnet<\/strong><\/td>Dec 3, 2025, 21:49 UTC<\/td>6<\/td>9<\/td><\/tr>
BPO1<\/strong><\/td>Dec 9, 2025<\/td>10<\/td>15<\/td><\/tr>
BPO2<\/strong><\/td>Jan 7, 2026<\/td>14<\/td>21<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Both BPO forks activated on schedule. BPO1 lifted the target from 6 to 10 blobs; BPO2 pushed it to 14, with the maximum reaching 21. Together, the two forks roughly tripled blob capacity within a month<\/strong> \u2014 the most meaningful expansion of Ethereum’s data availability since blobs were introduced.<\/p>\n\n\n\n

The transitions were smooth. Network telemetry showed the participation rate holding near 99% through BPO1, with only a brief dip around the activation epoch, and finality never interrupted. Blob demand has since climbed steadily without approaching the new ceiling, which is exactly the “spare capacity” outcome developers were aiming for.<\/p>\n\n\n\n

Reliability data does carry one caveat worth watching. Independent telemetry suggests the baseline block-miss rate sits near 0.5%, but climbs as blocks fill with blobs \u2014 reaching roughly 1.79% (about 3.5x baseline) at the 21-blob ceiling. That miss-rate curve is precisely why core developers are holding further increases (BPO3 and BPO4) pending review rather than pushing the dial higher on a fixed timetable.<\/p>\n\n\n\n

For the L2 economics: a typical Layer 2 transaction that cost around $0.50 in late 2025 dropped to roughly $0.20\u2013$0.30 in the weeks after Fusaka, with further room as capacity gets used. The combined L2 ecosystem currently processes on the order of 5,600 TPS, with developers projecting 24,000+ TPS as the BPO schedule progresses.<\/p>\n\n\n

What Fusaka Means for Developers and Node Operators<\/h2>\n\n\n

Strip away the acronyms and the practical picture is straightforward. If you build on a rollup, your users’ data-posting costs fell and have more headroom to keep falling. If you run infrastructure, the resource math changed in your favor.<\/p>\n\n\n\n

For node operators and home stakers<\/strong>, PeerDAS is the headline benefit. Because each node now custodies a fraction of blob data instead of all of it, disk usage and download bandwidth for blobs can drop by 50% or more compared to pre-Fusaka \u2014 even as total network capacity climbs. A solo staker running 32 ETH stays comfortably within home-hardware bandwidth ranges at BPO2 levels. Keeping solo staking viable while scaling is the whole point; it’s how Ethereum avoids “scale by centralization.”<\/p>\n\n\n\n

For application developers<\/strong>, Fusaka also shipped smaller quality-of-life additions: native support for the secp256r1 signature curve (EIP-7951), which opens the door to signing transactions with smartphone biometrics like Face ID, and a new CLZ opcode for cheaper on-chain math. These won’t headline a marketing page, but they matter if you’re building wallets or gas-sensitive contracts.<\/p>\n\n\n\n

One operational note if you run your own node: Fusaka required updates to both<\/strong> the execution-layer and consensus-layer clients, and validators needed to update their beacon node and validator client together. Anyone relying on managed infrastructure \u2014 for example, a dedicated Ethereum node<\/a> \u2014 inherited Fusaka support without touching client software, which is one reason teams offload this. If you’re newer to how these two layers split responsibilities, our guide to running and connecting to blockchain nodes<\/a> walks through the basics.<\/p>\n\n\n

Where Fusaka Fits in Ethereum’s Roadmap<\/h2>\n\n\n

Fusaka isn’t an endpoint \u2014 it’s the data-availability chapter of a longer story. Placing it in sequence makes its role clear:<\/p>\n\n\n\n