Back to writing
Ethereum8 min read

Fusaka Hard Fork: PeerDAS and What's Actually Changing

Breaking down PeerDAS, blob fee changes, BPO forks, and the protocol cleanup coming in Fusaka

Fusaka Hard Fork: PeerDAS and What's Actually Changing

Fusaka's live on Holesky/Sepolia/Hoodi, mainnet December 3rd. Here's what's actually changing.

tl;dr: PeerDAS + a bunch of protocol cleanup. We're scaling blob capacity without nuking node requirements, fixing some annoying fee volatility, and setting up the path to full Danksharding.

PeerDAS: The Big One

EIP-7594 (PeerDAS) is the headline feature.

Remember Dencun gave us blobs? Rollups loved them. Blobs are way cheaper than calldata for posting L2 data to L1. Arbitrum, Optimism, Base, all the major rollups immediately started using blobs and fees dropped dramatically.

But it hit capacity limits fast. We only have 6 blobs per block (target of 3). When rollup activity spikes, blob space fills up, and fees get... weird. The blob fee market is separate from the regular gas market, and it's been volatile. During high demand periods, blob fees can spike 100x in minutes.

PeerDAS fixes the capacity problem without requiring every node to download every blob.

How DAS Works

The key insight is Data Availability Sampling (DAS). Instead of every node downloading all blob data, nodes sample a fraction of data from peers and use cryptographic proofs to verify the whole thing is available.

Think about it. If you have 1000 nodes each sampling random 1% of the data, and they all find what they're looking for, you have very high confidence that 100% of the data is available. The math works out. You don't need everyone to download everything.

This is huge for scaling. Without DAS, increasing blob count means increasing bandwidth requirements for every node. Solo stakers on home connections get squeezed out. Centralization pressure increases.

With DAS, we can scale blobs without proportionally scaling bandwidth requirements. Nodes do more sampling, but the total data they download stays manageable.

KZG Commitments

One clever bit: each blob has its own KZG commitment. KZG (Kate-Zaverucha-Goldberg) commitments let you prove properties about data without revealing the data itself.

When a blob is posted, its KZG commitment is included in the block. Anyone can verify that samples they receive match the commitment. If the commitment is valid and your samples check out, you know the full blob is available.

The verification stays cheap for everyone. You don't need to download the blob to verify it. You just need to check the commitment against the samples you received.

What This Means for Rollups

Rollup fees are still bottlenecked by L1 data availability. Even with blobs, there's only so much space per block. When demand exceeds supply, fees spike.

PeerDAS gives us room to grow. We can increase blob targets and maximums without making solo staking unviable. More blob space means more rollup capacity means lower fees.

Fees should be more stable during peak times. The spikes happen when demand suddenly exceeds the hard capacity limit. With higher limits, we have more buffer before hitting that wall.

Still not free though. There's always going to be a cost for L1 DA. But the ceiling is higher now.

Fee Stuff: EIP-7918

Fusaka brings a blob basefee floor tied to actual L1 execution cost.

Here's the problem with the current blob fee market. When demand is low, blob fees can drop to almost nothing. Like, fractions of a gwei. That sounds great for users, but it creates issues.

First, it enables spam. If blobs are essentially free, people can fill them with garbage. The network stores this data (temporarily), and there's real cost to that even if users aren't paying for it.

Second, the volatility is jarring. Fees go from near-zero to massive spikes and back. That's bad UX. Users don't know what to expect. Fee estimation becomes a guessing game.

The blob basefee floor sets a minimum price tied to actual L1 execution cost. Blobs can't be absurdly cheap anymore. There's a floor below which fees won't drop.

This smooths out the fee market. You get less volatility, more predictable pricing. The downside is slightly higher prices when demand is low. But "slightly higher than almost zero" is still pretty cheap.

BPO Forks: EIP-7892

This one's about governance agility.

Previously, adjusting blob parameters (target count, max count) required a full hard fork. Hard forks take months of coordination. If blob demand spikes and we need more capacity, we're stuck waiting 6+ months for the next scheduled fork.

EIP-7892 introduces BPO (Blob Parameter Only) forks. These are lightweight forks that only adjust blob parameters. No new EVM features, no consensus changes, just tweaking the numbers.

If demand spikes, we can respond faster. Not instant, but faster than a full hard fork cycle. We're not stuck watching fees spike for half a year while we wait for the next Pectra or Fusaka.

This is about fast iteration on the DA layer. The blob fee market is new and we're still learning how it behaves. Being able to adjust parameters without full hard forks lets us tune things as we learn.

The question I'm curious about: how aggressive do we get with BPO forks? Do we wait for sustained demand to prove we need more capacity? Or do we preemptively increase limits to stay ahead of rollup growth?

Conservative approach: wait until fees are consistently high, then increase. Aggressive approach: increase proactively to keep fees low and encourage rollup adoption.

There are arguments both ways. I expect we'll start conservative and get more aggressive as we gain confidence in PeerDAS behavior.

Protocol Hygiene

A few smaller but important changes:

EIP-7825: Transaction Gas Cap

New 16.7M gas limit per transaction. Individual transactions can't exceed this, even if the block has room.

Why does this matter? DoS resistance mostly. A single massive transaction can cause problems for clients. Processing, storing, propagating, these all get harder with extremely large transactions. The cap sets a reasonable maximum.

It also helps with client parallelization. If you know transactions have bounded size, you can make assumptions that enable parallel processing. This is groundwork for future performance improvements.

EIP-7642: eth/69

The p2p protocol gets cleaned up. eth/69 drops pre-merge bloat and creates a leaner sync protocol.

Remember, Ethereum used to be proof-of-work. The merge happened years ago, but the p2p protocol still carried code paths for PoW sync. eth/69 removes that cruft.

Leaner sync means faster initial sync for new nodes. Less complexity means fewer bugs. It's not exciting, but it's good hygiene.

The Path to Danksharding

Zooming out, PeerDAS is a step toward full Danksharding.

Danksharding is the endgame for Ethereum DA. Instead of 6 blobs per block, we're talking hundreds. Massive DA capacity for rollups. L2 fees could drop to fractions of a cent.

But Danksharding requires DAS. You can't have hundreds of blobs if every node needs to download all of them. The bandwidth requirements would be insane.

PeerDAS is the DAS implementation. It proves the sampling approach works at scale. It lets us gradually increase blob counts while monitoring network health. Each increase teaches us something.

By the time we're ready for full Danksharding, we'll have years of DAS experience in production. We'll know how the network behaves, what the failure modes are, how aggressive we can be with parameters.

This is Ethereum's approach: ship incrementally, learn in production, scale gradually. Not as flashy as "we 10x'd capacity overnight" but safer.

What I'm Watching

A few things I'm curious about post-Fusaka:

Which rollup stack benefits most first? Different rollups have different blob usage patterns. Some batch more aggressively, some post more frequently. The capacity increase will help everyone, but the marginal benefit varies.

BPO fork politics: The first few BPO forks will set precedent. How much demand triggers an increase? How much do we increase by? These decisions will shape blob economics for years.

Solo staker bandwidth: PeerDAS is supposed to keep solo staking viable. But "viable" is subjective. I want to see actual bandwidth measurements from home stakers. Are we hitting the targets?

Fee market behavior: The blob fee market with higher capacity and a basefee floor is a different beast. How does it behave in practice? Does the floor actually reduce volatility?

Fusaka isn't the splashiest fork. No new opcodes, no account abstraction, no big DeFi features. But it's critical infrastructure. Scaling DA is how Ethereum supports the rollup-centric roadmap. PeerDAS is the technology that makes it possible.

December 3rd, mainnet. Let's see how it goes.

Topics

ethereumfusakaPeerDASblobsEIP-7594