PeerDAS and Blob Scaling: What Fusaka Changes for Rollup Data

When a rollup posts transaction data to Ethereum, the network needs confidence that the data is available for verification. Scaling that publication channel is a different engineering problem from executing more contract calls inside Ethereum's virtual machine.

Status checked November 6, 2026: the official Fusaka overview records mainnet activation on December 3, 2025, with PeerDAS as its headline feature. PeerDAS is already part of that upgrade; a future capacity change still needs its own network configuration and activation evidence.

The problem PeerDAS addresses

EIP-7594 defines Peer Data Availability Sampling. Instead of requiring every node to download every blob in full to perform its availability check, nodes retain designated portions and sample data from peers.

The protocol extends blob data with erasure coding and organizes it into cells and columns. Cryptographic cell proofs let nodes authenticate the pieces they receive. With enough columns, the original data can be reconstructed. Sampling and custody duties work together: nodes need peers that can actually serve the pieces being checked.

A useful way to reason about this is to separate three questions: does a piece match its commitment, is the data sufficiently available across the network, and are the transactions represented by that data valid? PeerDAS addresses the availability mechanism. A valid proof for one piece is not a substitute for the entire verification process.

Blob capacity and execution capacity have different units

EIP-4844 introduced blob-carrying transactions and a separate blob gas accounting system. The EVM can read versioned hashes of blob commitments through BLOBHASH, but it cannot directly read the full blob contents as ordinary execution data. The transaction carrying blobs still has an execution component.

This distinction matters when interpreting a scaling announcement. More room for rollup data does not specify how much computation an Ethereum contract can perform. Nor does it describe how many queries your application database can answer or how quickly an RPC request will return.

For a design review, we suggest naming the scarce resource every time you write “capacity.” Is the discussion about bytes published for rollups, execution gas, proof generation, network bandwidth, or application request handling? That small habit prevents a protocol improvement in one area from becoming an unsupported promise about another.

Capacity changes still have activation rules

Fusaka also introduced a way to change blob parameters separately from a broad upgrade. EIP-7892 describes Blob Parameter Only forks: targeted configuration changes to the blob target, maximum, and fee update fraction that take effect at a specified activation time.

Consequently, “supports PeerDAS” is insufficient evidence for a particular blob limit. Our operational recommendation is to record the network, client configuration, applicable activation time, and observed block range whenever comparing capacity across periods. Keep old configuration examples out of dashboards that label their values “current.”

A rollup fee requires more context

Imagine two applications using the same rollup. One submits small interactions frequently; another produces larger payloads in bursts. Even with identical Ethereum data availability rules, their measured user costs need not change by the same amount. The application workload and the rollup's own behavior belong in the comparison.

For a useful experiment, choose an actual user action and repeat it under documented conditions. Record the rollup, transaction shape, gas used, charged fee, inclusion time, and measurement window. If the rollup exposes a fee breakdown, retain that breakdown with its documented interpretation. Compare similar actions rather than a quiet-period transfer against a busy-period deployment.

These are measurement recommendations. PeerDAS does not supply a fixed discount for an individual rollup transaction, and this article makes no prediction about future fees. If a product needs a cost estimate, show when it was measured and refresh it using that network's documented estimation path.

Available now does not mean retrievable forever

Ethereum's data availability documentation distinguishes availability for verification from long-term retrieval. Blob data has a limited protocol retention window. A system that needs historical payloads later must account for that separately.

Our suggested application exercise is a recovery drill. Select an old record your team expects to reconstruct, list the data it requires, and identify who retains each item. Then test retrieval through the actual services or storage systems you plan to rely on. Include missing data and a failed upstream in the exercise.

For teams building on rollups, PeerDAS is best understood through that full workflow: publishing data, verifying availability, processing transactions, retaining history, and serving application requests. Give each stage its own evidence and measurements, and a scaling headline becomes a concrete engineering discussion.