← Ayo Osunjuyigbe

· Web3

With PeerDAS, your node no longer downloads every blob

Fusaka activated on 3 December, epoch 411392, slot 13,164,544, 21:49:11 UTC. Six days later, BPO1 moved the blob target from 6 to 10 and the cap from 9 to 15. If you only watch blobs per block, Fusaka looks like a nothing-burger for six days and then a parameter tweak. But something else changed on the 3rd.

Something else changed. Until last week, every full node on this network downloaded every blob. That was the security model. If the data was on your disk, it had been published. PeerDAS (EIP-7594) ends that. A normal full node now stores four columns of a 128-column matrix and samples eight per slot. Eight of 128 is one sixteenth of the extended data. The rows are Reed-Solomon doubled, so that slice is one eighth of the original blob bytes. Reconstruction needs half the columns. The L2 still posted the data. You did not keep it.

I have been waiting for this fork more than I waited for Pectra. Pectra doubled blob count. Fusaka changed what “available” means.

What we were actually doing since Dencun

Blobs showed up in Dencun, 13 March 2024, EIP-4844. A blob is 128 KiB of ephemeral data with a KZG commitment in the execution payload. Rollups stopped stuffing calldata. Nodes kept the sidecars for about 18 days (4096 epochs) and then dropped them. The target was 3 per block, max 6.

That was proto-danksharding. The “proto” meant: we have the commitment and the fee market, we do not have sampling. Every honest node still fetched the whole sidecar set. Bandwidth scaled with blob count. You could not raise the target forever without kicking home nodes off the network.

Pectra, 7 May, EIP-7691, moved the target to 6 and the max to 9. Same model, twice the blobs. The EF’s Fusaka announcement is honest about why they stopped there: since Dencun, L2s had been bumping the 9-blob ceiling. The next jump was not safe if every node still had to eat every byte.

So they shipped sampling first, and left the target at 6/9 on the Fusaka block itself. The capacity bump is a different object. EIP-7892 calls it a Blob Parameter Only fork: change target, max, and baseFeeUpdateFraction in config, no new code. BPO1 was already in the Fusaka client releases. It fired on 9 December. BPO2 is on the calendar for 7 January, 14/21.

If you only watch “blobs per block,” Fusaka looks like a nothing-burger for six days and then a parameter tweak. The parameter tweak is only legal because of the thing that happened on the 3rd.

What PeerDAS actually does

The EIP is a networking spec. The math lives in the consensus specs under Fulu.

Each blob is a row. Reed-Solomon extend it to twice the length. Slice the extended row into 128 cells (64 field elements each). Stand those cells up as columns. A column is one cell from every blob in the block. Gossip those columns on 128 subnets.

Your node ID picks a deterministic set of custody groups. A full node with no validator attached has CUSTODY_REQUIREMENT = 4: it stores four columns and serves them. Every slot it also samples. SAMPLES_PER_SLOT is 8, and you download max(8, your custody count) groups. Teku’s write-up is the clean version: store four, sample four more, check the cell KZG proofs. If the samples come back, you treat the block’s blobs as available. You do not reconstruct the rollup batch. You do not need to.

The “1/8” line on ethereum.org is this sampling slice measured against the original blobs, not 4 ÷ 128. Four stored columns is 1/32 of the extended matrix. Eight sampled columns is 1/16 of the extended matrix and, because of the 2× code, 1/8 of the data the rollup actually posted. EIP-7594’s “small constant fraction” is the same number. People collapse custody and sampling into one fraction and then cannot explain why the constants are 4 and 8.

If you ever do need the whole matrix — you are building a block, you are healing, you are a supernode — you can rebuild from any 50% of the columns. That is why the extension is 2×. Half the cells are redundant on purpose. ethereum.org puts the chance of reconstructing garbage in the 10⁻²⁰ to 10⁻²⁴ range. The EIP’s withholding table, for a 10,000-node network, says fooling 2% of nodes without publishing enough to reconstruct is already 10⁻²⁰. Fooling 5% is 10⁻³⁰⁶. The attack they care about is a proposer who shows you a commitment and hides the data. Sampling makes “hide the data, trick the network” a combinatorial problem that gets worse as the network gets bigger.

A few details people skip and then get surprised by.

The sender computes the cell proofs. Proof generation is expensive. Verification is cheap. EIP-7594 changes the blob-tx gossip wrapper: wrapper_version = 1, and proofs becomes cell_proofs for every cell of every extended blob. If you post blobs, your stack now does that work before the tx hits the pool. The block producer is not recomputing proofs for a full block of blobs on the critical path.

There is a 6-blob-per-transaction cap. Not per block. Per tx. Clients reject bigger submissions. Batch posters that were packing more than six into one type-3 transaction have to split.

Columns, not rows. Sampling a whole blob would mean reconstruction over “extension blobs” that nobody has. Sampling a column cuts across every blob in the block. Most of those blobs were already in the public pool. Reconstruction stays on data the network already gossiped.

Validators custody more. A node with a validator attached starts at 8 groups, not 4. The spec adds a group per 32 ETH of attached effective balance, floored at 8 and capped at 128. At 2048 ETH you already hold 64 columns — enough to reconstruct by yourself. At 4096 ETH — two max-balance validators after Pectra’s EIP-7251 — you are a supernode. You custody every column. You download everything, the way we all did last month, and you are the people the rest of us request missing columns from.

That last point is the one I want home-stakers to sit with. PeerDAS does not make the data lighter for everyone. It makes it lighter for the modal node by concentrating the full copy on nodes that already had more stake.

What this does to L2 posting cost

PeerDAS by itself does not lower the blob base fee. The Fusaka block still targeted 6. Same auction, different download.

BPO1 does. Target 10, max 15, and a new baseFeeUpdateFraction so the fee controller still moves at a sane rate with the wider gap. More blob gas per block before the fee starts climbing. If demand stays where it was last month, the fee should come down. If demand fills the new target, you get the same fee at more throughput. Either way the scarce thing got bigger.

That is the L2 story people wanted from this fork. It is real. It is also not free, and it is not “DA is now cheap forever.”

EIP-7918 sits under the auction so the blob fee cannot die at 1 wei when execution gas is doing all the work. L2s pay two bills to post: blob fee, and the execution gas to carry the commitments. When the second bill dominates, the 4844 controller treats the block as empty and walks the blob fee into the floor. 7918 compares BLOB_BASE_COST (2¹³) times the execution base fee against the cost of a full blob in blob gas. If the reserve is higher, calc_excess_blob_gas stops subtracting the target. The fee can rise. Congestion still shows up in the price. You do not get a market that stopped talking.

The other half of posting cost is local. Cell proofs on the sender. The 6-blob tx cap. If your batcher assumed “one transaction, as many blobs as the block will take,” that assumption expired on the 3rd.

BPO2 is scheduled for 7 January: 14/21. Same mechanism, another step on the same schedule. I am not going to pretend I know the fee on that day. I know the knob now exists without waiting for Glamsterdam.

ethereum.org is also blunt: Fusaka does not cut L1 gas. The gas-limit work in this fork (60M default, 2²⁴ per-tx cap) is a different axis. If your users live on an L2, the blob market is the one that moved. If they live on L1, they got a bigger block and a transaction size limit, not cheaper calldata.

What this does to a home node

At the same blob count, a non-validating full node downloads about an eighth of what it did. ethereum.org says blob disk and download can drop around 80%, down to a few megabytes of that data. That is the decentralization pitch. You can raise blobs later without the modal node’s NIC being the constraint.

A solo staker is not that node. You custody at least 8 columns. Download falls around 50%, not 80%. Upload goes the other way. If you build locally you have to put the columns you have, and the ones you fetched, back out so the rest of the network can sample. ethereum.org’s number at Fusaka activation is 2–3× the old upload. After BPO2 they want you thinking about 100 Mbps, roughly 5×. That is the sentence solo stakers should have read before they called this a bandwidth cut.

Large operators scale with balance. Around 800 ETH you are on 25 columns and about 30% more download than pre-Fusaka. At supernode you are back to “store everything,” plus more of it once the BPOs finish climbing.

So the hardware story is not “nodes got lighter.” It is “the typical node got lighter, the proposer-and-healer path got heavier, and the protocol is now allowed to turn a config knob that used to require a named fork.” If you only run geth + a consensus client and you do not validate, your blob disk should look smaller this week even though BPO1 just raised the target. If you propose, watch upload, not the marketing 1/8.

History expiry is in the same fork (EIP-7642 as a “clients must do this by Fusaka” notice). Pre-Merge history can go away. That is disk, not DA. Do not mix the two savings.

What you are trusting now

This is the part I keep seeing flattened into “DAS means we don’t store the data.”

The data is stored. It is stored in pieces, across custody groups, with enough Reed-Solomon that any 50% rebuilds the rest. A withholding proposer who publishes fewer than 64 columns cannot produce a reconstructable matrix. A withholding proposer who publishes 64 or more has published the data, even if your node only holds 16 columns of it.

What you are not doing, on a normal full node, is independently possessing the rollup’s batch. You sampled. The KZG cell proofs matched the commitments in the block. The sampling set is a function of your node ID and the slot. You believe, on the EIP’s combinatorics, that a proposer cannot satisfy enough random samples across enough nodes without crossing the reconstruction threshold.

That is a different trust object than “I have the bytes.” It is closer to “the network has the bytes, and I checked a random slice.” For consensus, that is the property we needed: do not finalize a block whose DA can be hidden. For an L2 user who wants to reconstruct state from L1, it is not enough. You still need a rollup node, a bridge watcher, or someone who fetched the columns and rebuilt the rows. Those people always existed. They still have to exist. PeerDAS did not replace them with a light client.

The supernode set is the practical backbone. They custody all 128. They answer requests. If that set is small, sampling still works in theory — the EIP’s bound is about n, the number of sampling nodes, not the number of supernodes — but reconstruction latency and heal quality are a different question. I will care about how many nodes advertise full custody once BPO2 lands and the target is 14.

One more honesty check. PeerDAS is one-dimensional. Columns. Danksharding’s original picture was 2D sampling. This is the scheme they could ship: gossip, peer requests, cell proofs in the tx wrapper, custody from node ID. EIP-7594 says the 1/8 fraction can become 1/16 or 1/32 later by shrinking samples. That is a future parameter change sitting on top of this networking design. It is not what activated last week.

What I watch after the fork

I am watching three things, and I am not watching “is IL down on my L2.”

Did BPO1 actually fill. Target 10 is a two-thirds jump from 6. If blocks sit at 6–7, the fee falls and the rollups got cheaper DA they are not using yet. If they slam 15, the fee market is doing its job and the next conversation is whether BPO2 on 7 January is early.

Who is serving columns. Full nodes at 4 groups, solo stakers at 8, supernodes at 128. The 1/8 story only holds if the people with 128 keep answering. Local builders paying 2–3× upload are part of that, whether they wanted to be or not.

Whether “I run a node” still means “I can recover an L2 batch.” It does not. It has not, strictly, since blobs expired after 18 days anyway. Sampling makes the gap explicit. If your mental model of Ethereum DA was “my disk is the archive,” update the model. The archive is the erasure-coded network plus whoever chose to keep the rows.

Fusaka did not make blobs free. It made it possible to have more of them without every home node becoming a blob CDN. The 3rd changed the download. The 9th changed the supply. January will change the supply again. The trust change is the one that does not get a BPO: you now check a sample, not a sidecar.

References