PeerDAS Makes Ethereum Data Cheaper, Not Automatically Reconstructible
Ethereum’s PeerDAS rollout changes a core assumption behind rollup scaling: validators no longer need to download every byte of every blob to gain high confidence that the data exists. That is a major capacity breakthrough, but it is not a magic guarantee that every rollup user can always recover the exact transaction inputs needed to exit, challenge, or independently derive Layer 2 state. Understanding the difference matters more now that Ethereum has begun raising blob capacity through Blob Parameters Only forks.
Ethereum’s Fusaka upgrade was not simply another throughput increase. It changed the network’s operating model for rollup data.
Before PeerDAS, Ethereum’s data availability path was intentionally simple, if expensive: rollups published blobs, and nodes that wanted to validate the chain downloaded those blobs in full. The redundancy was substantial. Every participating validator received the same large data objects, even though any one validator needed only enough evidence to decide whether the broader network could retrieve the data later.
PeerDAS, short for Peer Data Availability Sampling, changes that model. Instead of asking each validator to receive every blob in full, Ethereum breaks encoded blob data into smaller pieces called cells. Validators and peers take custody of assigned portions and sample additional portions from the network. If enough independent requests succeed, the network gains strong statistical confidence that the complete data is available somewhere across its peer set.
That redesign is why Ethereum can safely raise blob capacity more aggressively than it could under the old all-download model. Fusaka activated PeerDAS in December 2025, while later Blob Parameters Only, or BPO, forks raised the blob target and cap without packaging every capacity adjustment inside another broad protocol upgrade. The second BPO fork raised the target to 14 blobs per block and the maximum to 21.
But the important word in that description is confidence.
PeerDAS gives Ethereum a way to make data availability highly likely, economically expensive to fake, and practical to check at scale. It does not mean a validator has personally downloaded every byte. It does not mean every rollup has designed a usable escape hatch. And it does not mean a state root alone tells a user how to reconstruct the transaction history that produced it.
Those are three different claims. The crypto industry often compresses them into one vague phrase, “the data is on Ethereum.” PeerDAS makes that shortcut less defensible, because Ethereum is deliberately separating custody, verification and reconstruction across many participants.
The three claims that should never be conflated
Start with the distinctions.
Claim one: data was posted. A rollup sequencer included blob commitments in an Ethereum block. The blob commitment is bound to the block and can be checked cryptographically. This says the sequencer attempted to publish a specific data object through Ethereum’s blob lane.
Claim two: data was sampled as available. Validators and peers were able to retrieve the cells they were assigned or selected to request. Because cells are cryptographically tied to the blob commitment, a peer cannot substitute arbitrary bytes and pass the check. Successful sampling raises confidence that enough of the full encoded object was present across the network.
Claim three: a rollup user can reconstruct the exact inputs required to derive state. Someone can obtain sufficient underlying rollup transaction data, decode it correctly, apply the rollup’s published rules, and reproduce the relevant state transition or exit path.
The first is a publication event. The second is a network availability conclusion. The third is an application level recoverability property.
Ethereum can help strongly with the first two. The third depends on much more: the rollup’s data format, its compression scheme, its batch submission policy, its proof system, its software availability, its state reconstruction process, and the quality of its escape hatch.
That distinction becomes especially relevant for a user evaluating a rollup that advertises itself as “secured by Ethereum.” A validity proof may show that a new state root follows from the prior state under some execution rules. It does not by itself give every user the transaction data necessary to rebuild balances or generate a withdrawal. An optimistic rollup may provide a dispute mechanism, but disputes are only meaningful if challengers can obtain the data necessary to identify and prove fraud.
Ethereum’s scaling strategy rests on rollups, and blobs were introduced as a cheaper, temporary data lane for those systems. PeerDAS extends that strategy by allowing validators to sample rather than fully download blob data, reducing the per-node data burden while retaining strong availability checks.
From sequencer batch to temporary blob
A blob is not ordinary Ethereum state. It is a large, temporary data object attached to a transaction. Rollups use blobs to publish compressed transaction batches, state diffs, or other information that makes their state transitions independently checkable.
The lifecycle begins with a rollup sequencer.
It gathers user transactions, orders them, executes them under the rollup’s rules, and generates a batch. Depending on the rollup design, that batch might contain compressed transaction calldata, state update information, proof inputs, or references to other information necessary for verification. The sequencer then packages the data into one or more blobs and submits an Ethereum transaction containing commitments to them.
Ethereum consensus does not execute the blob bytes as smart contract calldata. Instead, it verifies commitments that bind the transaction to those bytes. The data is propagated through Ethereum’s consensus networking layer and retained for a limited historical period rather than becoming permanent execution state.
That is already a major economic design choice. Ethereum is offering rollups a lower-cost publication layer without asking every future Ethereum node to store every rollup batch forever. The tradeoff is that rollups, infrastructure providers and users who require long-term reconstruction must plan for data retention beyond Ethereum’s temporary blob window.
The phrase “posted to Ethereum” therefore needs precision. A blob commitment in a finalized block is durable evidence that Ethereum accepted a commitment. The full blob data is designed to be broadly retrievable during its availability period, but it is not permanent archival storage.
For a rollup, that means operational responsibility does not disappear when the blob transaction lands. A serious system should operate or encourage independent archival infrastructure, publish open data decoding tools, document its batch format, and make clear what a user can do if the sequencer disappears.
What PeerDAS actually samples
PeerDAS begins with a familiar problem from distributed systems: how can a network check that a large object is available without requiring every participant to download that full object?
The answer is erasure coding plus random sampling.
A rollup’s original blob contains 128 KiB of payload data. Ethereum applies erasure coding to produce an expanded version. In simplified terms, the original data is transformed into redundant pieces such that the original can be recovered from a sufficiently large subset of the encoded pieces. If some pieces are unavailable, the redundancy can fill the gaps.
The encoded blob is divided into cells. A useful mental model is a grid. Each blob becomes a row of cells, and a block containing multiple blobs becomes a larger matrix. Each vertical slice, or column, contains one cell from every blob in that block.
This column structure is important because PeerDAS does not merely ask every validator to choose arbitrary bytes. Validators are assigned custody responsibilities over particular columns. A validator holding a column is responsible for obtaining the matching cells from all blobs in the block. This spreads the storage and bandwidth burden across the validator set while ensuring that the network has structured coverage of the data.
The point of erasure coding is not merely duplication. Ordinary replication says, “Keep several full copies.” Erasure coding says, “Keep enough mathematically related pieces that the original can be rebuilt even when a fraction is absent.”
For an honest peer serving a cell, cryptographic proofs link that cell back to the blob commitment. A validator can check that it received the right piece of the right blob, rather than trusting the peer’s word. That is essential. Availability sampling without authenticity would be vulnerable to a peer serving plausible-looking garbage.
PeerDAS is frequently described as validators downloading “small slices” instead of blobs. That is directionally right, but it hides an important operational detail. A validator is not doing one tiny spot check and going home. It participates in a custody and peer-to-peer distribution system designed so that the network collectively covers the full data set. Sampling is a protocol role, not a casual audit.
Ethereum developers and media coverage described PeerDAS as the mechanism that lets nodes verify blob availability through smaller samples rather than complete blobs, making higher blob throughput possible without pushing ordinary validators toward data center scale requirements.
The probability guarantee, in plain English
The central PeerDAS guarantee is probabilistic.
Suppose an attacker withholds a meaningful portion of a blob’s encoded cells. If validators request cells selected in a way the attacker cannot reliably predict or control, then every successful sample makes it harder for the attacker to hide the missing portion. The more samples the network obtains from diverse peers, the lower the chance that a genuinely unavailable blob will look available.
A basic intuition is:
probability of missing withheld data = (available fraction)^number of independent samples
If 50% of relevant cells were actually unavailable, and a validator took several genuinely independent random samples, the odds that every sample happened to land on available data would fall rapidly. At 10 samples, it would be roughly one chance in 1,024. At 20 samples, approximately one in one million.
Real PeerDAS is more sophisticated than that toy formula. It includes assigned custody, structured columns, peer networking, cryptographic proofs and protocol rules. But the formula captures the core truth: sampling does not prove availability with absolute certainty after one check. It makes successful long-term withholding increasingly unlikely to escape detection.
That probability depends on assumptions.
First, sample choices must have enough unpredictability that an attacker cannot selectively serve only the cells it expects an honest validator to request.
Second, validators must connect to a sufficiently diverse set of peers. If a validator’s network view is controlled by an attacker, the attacker may influence what it can retrieve, delay responses, or selectively isolate it from honest peers.
Third, a meaningful fraction of custodians must be honest, online and reachable. Erasure coding can restore missing cells, but it cannot reconstruct a blob if too much encoded data is truly absent from the accessible network.
Fourth, validators must have enough bandwidth, disk and processing headroom to retrieve their assigned data under block-time pressure. PeerDAS reduces the requirement that every validator download all blob data. It does not abolish the physical work of moving data through the network.
The key phrase is “enough cells.” Erasure coding creates tolerance for loss, not tolerance for unlimited loss. If an attacker can prevent enough required cells from reaching honest custodians and samplers, reconstruction fails. The protocol’s defense is that doing so should be observable and difficult to sustain without disrupting block propagation, attestations or finality.
This is why it is better to say PeerDAS offers high confidence of availability under its network assumptions, rather than saying it makes rollup data permanently available.
What custody shifts onto validators and peers
PeerDAS is often marketed as a bandwidth reduction, which it is. But it is also a redistribution of responsibility.
Under the old model, every validator incurred a straightforward cost: download the whole blob set. Under PeerDAS, each validator has a smaller direct data obligation, while the system depends more explicitly on a peer-to-peer custody pattern.
That changes the cost profile in several ways.
Bandwidth becomes more selective, not irrelevant. A validator needs to retrieve its assigned columns promptly, request samples, validate cryptographic proofs and serve data to other participants. As blob counts grow, the aggregate data moved through Ethereum’s peer network grows too, even if a single validator sees only a fraction of it.
Storage becomes distributed. A validator need not store all blob data, but the network must collectively retain sufficient encoded cells for the relevant availability period. The system is counting on broad participation and correct custody distribution.
Peer quality matters more. In an all-download system, a node can acquire a full blob from any capable source. In a custody model, poor connectivity, overloaded peers, weak gossip behavior and regional outages become more relevant to whether assigned data is promptly retrievable.
Adversarial withholding gets more targeted. Instead of trying to hide a whole blob from every validator, an adversary may attempt to suppress carefully selected cells, manipulate peer connections, flood the network, or serve data selectively to make samples pass while denying enough of the wider network the pieces necessary for reconstruction.
These are not reasons to dismiss PeerDAS. They are the engineering problems it is designed to address. But they are exactly why Ethereum increased capacity in staged steps rather than opening the floodgates at once.
Fusaka was accompanied by BPO forks precisely because blob parameters can now be adjusted separately from a full upgrade. Ethereum can raise the target, maximum and fee adjustment settings, observe network behavior, then decide whether the next increase is prudent.
What the capacity numbers really say
There are two capacity numbers that readers should track: the target and the maximum.
The target is the blob level Ethereum’s pricing mechanism aims to sustain under ordinary demand. The maximum is the short-term ceiling a block can reach when demand is high enough to justify higher blob fees.
At the time of Fusaka activation, Ethereum had a target of six blobs and a maximum of nine. The first BPO increase lifted those levels to 10 and 15. The second BPO increase, finalized in early January 2026, raised them again to 14 and 21.
A blob carries 128 KiB of original data. At the current target of 14 blobs per roughly 12-second Ethereum slot, the target represents about 1.75 MiB per block, or roughly 149 KiB per second of original rollup data capacity. The 21-blob maximum is about 2.625 MiB per block, or roughly 224 KiB per second.
Those figures are useful, but they are not equivalent to “Ethereum transactions per second.”
A rollup can compress some transactions far more effectively than others. A simple token transfer, a complex decentralized exchange interaction, an account abstraction operation and a zero-knowledge proof batch have different data footprints. The same number of blobs can therefore translate into radically different user transaction capacity across different rollups.
The figures also describe original blob payload, not the full networking overhead. PeerDAS introduces encoded data, proofs, request traffic, peer responses and redundancy. It lowers the per-validator burden relative to full downloading, but it does not turn data availability into free throughput.
For businesses building on rollups, the practical implication is positive but measured: more blob supply should reduce pressure in the data market and make batch submission more predictable. Yet sequencers still compete for blob space, and user fees still depend on each rollup’s pricing policy, compression performance and willingness to pass savings through.
Where sampling can fail
The strongest way to understand PeerDAS is to examine its failure cases.
A proposer posts a commitment but withholds data
A malicious proposer could include a blob commitment but fail to make enough valid cells available to the network. In that case, honest validators and peers should fail to obtain required cells. The block may propagate poorly, receive insufficient support, or create an observable availability problem.
The defense is not that one validator can prove instantly that every byte is absent. The defense is that broad honest participation makes successful concealment difficult without detection or consensus disruption.
The attacker serves some validators but not others
Selective availability is more subtle. An attacker may serve cells to a small set of nodes while withholding them from others. This is where random sampling, custody distribution and diverse peer connections matter. If honest validators sample across different peers, selective service becomes harder to coordinate.
But network topology matters. A validator isolated behind poor peer connectivity has a weaker view than a validator with robust, diverse peers. PeerDAS does not eliminate the need for healthy networking. It makes healthy networking part of the security budget.
Enough cells exist, but users cannot decode the rollup
Ethereum may make the blob data retrievable while the rollup remains difficult for ordinary users to reconstruct. A batch could use proprietary compression, undocumented formats, unavailable source code or complex state dependencies. In that scenario, Ethereum has delivered data availability, but the rollup has not necessarily delivered user sovereignty.
This is the most underappreciated distinction in rollup marketing.
A credible escape hatch needs more than a posted batch. It needs public specifications, durable software, verifiable state roots, a path to reconstruct account state, and a mechanism for users to act without the sequencer’s cooperation.
Validity proofs obscure a data dependency
Zero-knowledge rollups can prove that a state transition was valid without requiring Ethereum to execute every transaction. That is powerful. It is not a substitute for data availability where users need the underlying data to recover their own state or generate withdrawals.
A proof can answer, “Was this transition valid?” It cannot automatically answer, “What exact transaction sequence and account data do I need to independently rebuild the state?”
Blob retention expires
Blobs are deliberately temporary. A rollup that relies only on Ethereum’s native blob retention period risks placing a deadline on independent recovery. Long-lived applications should ensure batch data is archived by multiple independent providers and that users know where to retrieve it.
For a consumer application, this may sound abstract. For a financial rollup holding user assets, it is a product requirement. The recovery path should remain operable when the sequencer is offline, the operator is uncooperative, or the original data provider has disappeared.
The due diligence checklist for a rollup
PeerDAS improves Ethereum’s base availability layer. It does not remove the need to evaluate a rollup as a complete system.
When assessing a rollup, users, investors and integrators should ask:
What exactly is posted in blobs? Full transaction inputs, compressed transactions, state diffs, proof inputs, or only a subset?
Can independent software decode the data? Is the format public, documented and implemented by more than one team?
Who runs the sequencer? Is sequencing centralized, and can users force transactions or exit when it is down?
What does the proof system guarantee? Does it prove correct execution, enable fraud challenges, or merely validate selected state commitments?
Is there a usable escape hatch? Can a user withdraw without the sequencer, and what data, proof and waiting period does that process require?
Who archives the data after blob expiry? Is the answer one company, several independent providers, or an open ecosystem of indexers and archival nodes?
Can the system withstand a data withholding event? The relevant question is not just whether Ethereum samples the blob. It is whether users can reconstruct the state they need before deadlines expire.
PeerDAS is a genuine protocol advance because it turns Ethereum into a more scalable data availability layer without forcing every validator to become a full mirror of every rollup batch. That shift is the foundation for higher blob capacity and potentially lower rollup fees. CoinDesk and The Block both characterized the BPO mechanism as a way to make these capacity increases more gradual and operationally flexible than waiting for infrequent all-purpose hard forks.
The more ambitious conclusion is not that Ethereum has solved every data problem. It is that Ethereum has separated them cleanly enough for the industry to solve each one on its merits.
The chain can provide a commitment. PeerDAS can provide high confidence that the committed data was broadly available. Erasure coding can make reconstruction possible from enough surviving pieces.
But only the rollup can ensure that a real user, under stress and without a cooperative operator, can turn those pieces into the exact inputs needed to recover their funds.