Part III · Chapter 43 of 43 · Fulu · Osaka (Fusaka)

EIP-7594: PeerDAS, blob data without downloading it all

Blobs made rollup data cheap — but every node still downloaded every blob, so throughput couldn't grow. Derive PeerDAS one fix at a time: erasure-code each blob, split it into columns, custody a slice, and sample the rest until absence is a near-impossibility.

Updated Sep 13, 2026 · 12 min
Assumed
  • EIP-4844 blobs
  • how a node syncs

EIP-4844 gave rollups a cheap data lane — but it left one thing untouched: every full node still downloads and stores every blob. That’s fine at three blobs a block; it’s a wall the moment you want thirty. PeerDAS (EIP-7594), the headliner of the Fusaka upgrade (mainnet December 3, 2025), removes the wall so blob throughput can keep climbing without asking every node to hold more. It looks like magic — a node that stores a fraction of the data still knows all of it is there — until you build it, one fix at a time.

1 step The download wall

Cheap data still meant everyone downloads everything

Blobs solved price — a separate lane, dropped after ~18 days, its own fee market. What they didn’t solve is scaling. To be sure a blob was really published, every full node still had to download the whole blob and keep it until it could be pruned. So the per-node cost grows linearly with blob count: double the blobs and you double what every node on Earth must pull down each block. That linear coupling is exactly what caps the target at a handful of blobs — raise it and you price out home stakers on ordinary bandwidth.

→ Step 2: make half the data enough to rebuild the whole.

2 step Half is enough

Erasure coding: any 50% reconstructs the rest

Before splitting a blob up, make it redundant. Treat the blob as a polynomial and extend it with a Reed-Solomon erasure code Encoding that adds redundancy so the original data can be reconstructed from any sufficiently large subset of the pieces. Here each blob is extended so that any 50% of the extended data is enough to rebuild all of it. so the encoded data is twice the size — and any 50% of it reconstructs the original entirely. This flips the availability question from a fragile one to a robust one. Without coding, hiding a single missing byte means checking every byte. With it, the data is unrecoverable only if more than half is missing — and “more than half is gone” is an easy thing to catch by looking at a few random spots.

→ Step 3: cut the coded blob into columns and hold just a few.

3 step Split and custody a slice

128 columns, spread across the network

Arrange the extended blobs into a grid and slice it into columnsNUMBER_OF_COLUMNS = 128 of them — each gossiped on its own p2p subnet. Now a node doesn’t subscribe to all the data; it custodies only a configurable subset of columns (a full node targets roughly 1/8 of them). The data still exists in full across the network — every column is held by many nodes — but no single node carries the whole thing. Per-node storage and bandwidth are decoupled from total blob count: raise the number of blobs and each node’s slice barely moves.

→ Step 4: sample random columns until absence is near-impossible.

4 step Sample until sure

Data-availability sampling: turning odds into certainty

To consider a block’s blob data available, a node asks peers for a handful of random columns it doesn’t custody. Here’s why that suffices. Thanks to the erasure code, a blob is unrecoverable only if more than half its columns are missing. So if an adversary tries to withhold enough to make the data unrecoverable, then every random column a node asks for has under a 50% chance of being answerable. Ask for k independent columns and the probability the node is fooled — accepting a block whose data is genuinely gone — falls off a cliff.

Formula
P(fooled) ≤ ( 1/2 1 )^ k 2
  1. 1 erasure coding means >50% of columns must be missing to make the data unrecoverable, so each random sample has under a 50% chance of landing on an available column
  2. 2 the number of independent columns the node samples
Sample a few dozen columns and the chance of accepting a block whose blob data is actually unavailable drops to roughly one in 10^20–10^24 — cryptographically negligible, with no node holding more than a slice.

That is the whole reversal: certainty about all of the data, from a random taste of it. Every node validates full availability while downloading a fraction, so blob capacity can rise without raising the per-node burden.

Data-availability sampling (DAS) Verifying that a block's data was fully published by fetching a few random pieces rather than the whole. Combined with erasure coding — which forces an attacker to withhold a majority of the data to hide anything — a few dozen samples make undetected withholding astronomically unlikely.

Where it lands. Blobs (4844) made rollup data cheap; PeerDAS (7594) makes it scalable — decoupling what the network can carry from what any one node must hold, and doing it with a probability bound rather than trust.

04 Go Deeper Where to take it from here