On 14 February 2026, an Arbitrum swap cost a user $0.008. A year earlier, the same swap cost $0.34. Nothing about the swap changed — the rollup did, briefly, but mostly Ethereum's data layer changed underneath it. That change is called PeerDAS, and it shipped in the Fusaka hard fork on 3 December 2025 at slot 13,164,544.
In Part 1 of this series, we walked through the arc from Pectra to Fusaka and previewed Glamsterdam. This article zooms in on the single most consequential piece of Fusaka: EIP-7594, Peer Data Availability Sampling. It is the unglamorous plumbing upgrade that quietly cut Layer-2 fees by another order of magnitude.
What "data availability" actually means
When an optimistic or zk rollup posts a batch to Ethereum, it doesn't post EVM transactions for the L1 to re-execute. It posts compressed transaction data plus a proof or fraud-proof window. The L1's only job is to make sure that data is available — that anyone, including a future challenger, can download it and reconstruct the rollup's state.
If the data disappears, the rollup is functionally a permissioned database. So data availability is not a nice-to-have; it's the security model.
Before EIP-4844 (Dencun, 13 March 2024), rollups paid for this by stuffing data into regular transaction calldata, competing for the same gas as everything else on L1. Dencun introduced blobs — a separate fee market and a separate data lane. Each blob is exactly 4,096 field elements × 32 bytes = 128 KiB. We covered the blob fee market and EIP-1559 mechanics in our gas fees and blobs guide.
Blobs are pruned from consensus nodes after roughly 18 days. That's fine: by then, anyone who cared has archived them.
The download problem
Dencun's design had an obvious scaling ceiling. Every full node had to download every blob to verify availability. Pectra (May 2025, EIP-7691) raised the per-block target/max from 3/6 to 6/9 blobs. At the max, that's 9 × 128 KiB = 1.15 MB per 12-second slot, every slot, on every full node, forever (until pruned).
You cannot keep raising that number without pricing out home stakers. And if home staking dies, Ethereum's neutrality story dies with it. The validator-side economics of that trade-off are covered in our staking and LSTs primer.
The original roadmap answer was Danksharding: 64 to 128 blobs per slot, with full 2D erasure-coded data availability sampling. PeerDAS is the first real step toward that endgame, and it shipped under a less ambitious name to keep complexity manageable.
Three concepts you need: erasure coding, sampling, KZG
Let's define the three pieces, briefly and concretely.
Erasure coding is a redundancy trick. Take a chunk of data, treat it as the coefficients of a polynomial, and evaluate that polynomial at more points than you started with. With 1D Reed-Solomon at 2× extension — exactly what PeerDAS uses — you turn N pieces of data into 2N pieces, with the property that any N of them are enough to reconstruct the original. Lose up to half, no problem.
Sampling is the security claim that flows from erasure coding. If a malicious block proposer wants to hide even one byte of the original blob, they have to hide more than half of the extended data — because any 50% is enough to reconstruct. Hiding more than half is loud; many independent nodes randomly asking for small pieces will, with overwhelming probability, ask for at least one piece that's missing. Each node only has to download a tiny sample to be statistically certain the data is fully available.
KZG commitments are the cryptography that ties it all together. KZG (Kate-Zaverucha-Goldberg) lets you commit to a polynomial with a single elliptic-curve point, then later prove that the polynomial evaluates to a specific value at a specific point — with a proof that's also a single elliptic-curve point. PeerDAS uses KZG cell proofs so that each small sampled piece can be verified against the blob's commitment without trusting the peer who served it.
If you've read our account model and EVM explainer, the mental model is similar: cryptographic commitments let you verify pieces of state without holding the whole thing.
How PeerDAS actually works
In PeerDAS, each blob's extended data is split into 128 columns. The full block's blobs are arranged together so that columns span across all blobs in a slot — that's the key trick that makes per-node bandwidth grow with column count, not blob count.
The gossip network is reorganized around column subnets. There are 128 of them. A typical home validator subscribes to and custodies 8 column subnets — that's its sample. Bandwidth-wise, 8/128 of the extended data is roughly 16 KiB per slot of blob payload at current targets, instead of the full ~1 MB.
Validators with an effective balance of 4,096 ETH or more — the upper end of the MaxEB range Pectra introduced — can opt to run as supernodes, custodying all 128 columns. Supernodes are the backbone that guarantees reconstruction is always possible; everyone else samples.
When a node needs a column it doesn't custody (for example, to reconstruct missing data, or because a rollup asked), it requests it via peer-to-peer. KZG cell proofs make those requests trustless: you verify the cell against the published blob commitment yourself, no honest-peer assumption required.
The fee story: numbers, not vibes
PeerDAS made it cheap to raise blob counts without melting home stakers. The Ethereum community used a new mechanism called Blob Parameter Only forks (BPOs) — small, fast, parameter-only upgrades — to do exactly that.
- 3 December 2025 — Fusaka: target/max stays at 6/9, but PeerDAS is live.
- 9 December 2025 — BPO1: target/max raised to 10/15.
- 7 January 2026 — BPO2: target/max raised to 14/21.
More than doubling the blob ceiling in five weeks, with no panic, was unthinkable a year earlier. The fee impact was immediate. L2 transaction fees, which sat in the $0.20-$0.50 range through late 2025, fell to $0.005-$0.02 by Q1 2026 — the Arbitrum swap from the opener was not a cherry-picked outlier.
The second-order effects came faster than most people expected. The cleanest example: in early 2026, ENS publicly cancelled its Namechain L2, citing the collapse in L1 gas and blob fees as removing the cost case for a dedicated chain. "Just stay on L1" became a defensible answer for the first time in years.
What this does to the alt-DA pitch
For the last two years, alternative data-availability layers — Celestia, EigenDA, Avail — pitched themselves as the way out of expensive Ethereum blobs. EigenLayer in particular crossed $18 billion in restaked ETH by February 2026, and EigenDA was the marquee restaking application.
PeerDAS doesn't kill that pitch, but it changes the math. L2BEAT classifies rollups that post data to alt-DA layers as Validiums or Optimiums rather than true rollups, because their exit guarantees depend on a separate honest-majority assumption outside Ethereum's validator set. When Ethereum blobs cost $0.50, that trade-off was easy to defend. When they cost a fraction of a cent, you have to argue much harder for why your users should accept weaker security.
We expect a sorting: latency-sensitive or extremely high-throughput chains (gaming, orderbook DEXs) will keep using alt-DA, while most general-purpose L2s will quietly migrate fully back to Ethereum blobs. A few already have.
What PeerDAS is not
A few clarifications worth nailing down, because they come up constantly:
- PeerDAS does not make Ethereum L1 itself faster. L1 throughput is unchanged. The win is entirely on the rollup data path.
- PeerDAS does not mean blobs are stored forever. The 18-day pruning window is the same. Long-term archival is still a separate problem (and a real one).
- PeerDAS is not Danksharding. Full Danksharding requires 2D erasure coding and a target of 64-128 blobs per slot. PeerDAS is the 1D, single-digit-blob-count starter version. The endgame is still ahead.
If you hold ETH and use rollups regularly, the practical takeaway is straightforward: bridging to and from L2s, swapping on rollup DEXs, and using any L2-native app got materially cheaper in Q1 2026, and the trend is intact. Our guide to holding ETH in Zelcore covers the mechanics of bridging and rollup-aware wallets in more depth.
Coming in Part 3: Glamsterdam
Fusaka was the data-layer fork. Glamsterdam, targeted for H1 2026, is the consensus-layer fork. Its two flagship items — enshrined Proposer-Builder Separation (ePBS) and Block Access Lists (BAL) — go after MEV and execution parallelism, not data availability. We'll unpack both in Part 3, including what ePBS means for solo stakers and why BAL is the prerequisite for serious EVM parallelization.
PeerDAS bought Ethereum cheap data. Glamsterdam is about what the L1 itself does with the breathing room.
