Data availability: blobs, sampling and DA layers

The data availability problem

A block producer can publish a header and withhold the body. A light client sees a valid looking header; a full node that asks for the body gets nothing. "Was this data published, so that anyone who wants it can get it?" is the data availability problem, and it is harder than it sounds because withholding is not attributable. If you claim the data is missing and the producer then publishes it, nobody else can tell which of you was lying, so there is nothing to slash.

Validity proofs do not solve it. A proof shows that a new state root follows correctly from some data; it does not show that anyone else can see that data. A validity rollup whose data is withheld has a correct state that nobody can use: users cannot compute the Merkle proofs they need to withdraw, and nobody but the operator can produce the next block. For an optimistic rollup it is worse. Challengers need the data to build a fraud proof, so withheld data can let an invalid state root finalize.

Two principles follow. Availability is about publication, not permanent storage: the data only has to be retrievable long enough for anyone who cares to fetch it. And checking availability without downloading everything needs a trick, which turns out to be erasure coding plus random sampling.

EIP-4844 blobs: Ethereum’s unit of data

Dencun, on March 13, 2024, introduced blob carrying transactions (type 0x03). A blob travels alongside a block, is committed to with KZG, is priced in its own fee market and is pruned after a few weeks. The EVM never sees its contents, only a versioned hash of its commitment. The specification is EIP-4844.

The retention window is deliberate. It is long enough for any honest party to fetch the data and for a week long fraud proof window to close with a wide margin, and short enough that the storage it implies stays bounded however many blobs the chain carries. Rollups, indexers and archive services keep the history.

KZG commitments: why blobs are polynomials

The 4,096 field elements of a blob are treated as evaluations of a polynomial p(x) of degree below 4,096. The KZG commitment is a single elliptic curve point, [p(τ)]₁, computed with a secret τ that nobody knows. It comes from a public trusted setup ceremony that stays sound as long as one participant destroyed their contribution. Given the commitment, anyone can verify a short proof that p(z) = y for any point z without seeing the rest of the blob:

This is what lets contracts use data they cannot read. An optimistic rollup’s fault proof can load exactly the blob bytes a disputed step needs. A validity rollup can prove inside its circuit that the transactions it executed are the ones committed in the blob, by evaluating both at the same random point. And, as the PeerDAS section shows, polynomial commitments make erasure coding self verifying.

The blob fee market

Blobs have their own EIP-1559 style market. The protocol tracks excess blob gas, the running total of blob gas used above target, and prices blob gas as an exponential of it:

# From EIP-4844, with the EIP-7918 reserve price added in Fusaka.
# target, max and the update fraction come from the active blob schedule.
GAS_PER_BLOB = 2**17        # 131,072
BLOB_BASE_COST = 2**13      # 8,192

def fake_exponential(factor, numerator, denominator):
    i = 1
    output = 0
    numerator_accum = factor * denominator
    while numerator_accum > 0:
        output += numerator_accum
        numerator_accum = (numerator_accum * numerator) // (denominator * i)
        i += 1
    return output // denominator      # approximates factor * e**(numerator/denominator)

def calc_excess_blob_gas(parent, target, max_blobs):
    target_blob_gas = GAS_PER_BLOB * target
    if parent.excess_blob_gas + parent.blob_gas_used < target_blob_gas:
        return 0
    # Reserve price: if blobs are cheaper than 8,192 units of execution gas,
    # excess stops falling, so the blob fee cannot sink any further.
    if BLOB_BASE_COST * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent):
        return parent.excess_blob_gas + parent.blob_gas_used * (max_blobs - target) // max_blobs
    return parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas

The update fraction is set so that a completely full block raises the fee by about 8.2% and an empty block lowers it by about 14.5%. That asymmetry dates from Pectra, when the target to maximum ratio moved from 1:2 to 2:3, and the blob parameter only forks preserved it by scaling the fraction with capacity: 5,007,716 at 6/9 blobs, 8,346,193 at 10/15 and 11,684,671 at 14/21. Sustained demand at the maximum multiplies the price by ten in about 29 blocks, just under six minutes.

The reserve price

For long stretches after Dencun, demand sat below target and the blob fee sat at or near its 1 wei minimum, so it carried almost no price signal. Fusaka added EIP-7918: while 8,192 times the execution base fee exceeds 131,072 times the blob base fee, excess blob gas stops falling. In effect a blob can no longer cost less than about 8,192 units of execution gas, one sixteenth of the execution base fee per unit of blob gas.

Even at the reserve price a blob byte is 256 times cheaper than a nonzero calldata byte, and since Pectra (EIP-7623) data heavy transactions pay a calldata floor of 40 gas per nonzero byte, which widens the gap to 640 times. That is why rollups post to blobs and keep calldata only as a fallback.

Capacity: from 3 blobs to 14

At the BPO2 target Ethereum carries 1.75 MiB of blob data per 12 second slot, about 12.3 GiB a day, and up to 2.625 MiB per slot at the maximum. These were the mainnet values as of September 2026.

The BPO forks are a mechanism in their own right. EIP-7892 lets clients ship a schedule of blob parameters (target, maximum and update fraction) in advance and activate each step as a small fork that changes nothing else. Capacity can then rise in stages as the network shows it can carry the load, without waiting for a full upgrade. Further increases are expected to come the same way, so check the current schedule before relying on a number.

PeerDAS: sampling instead of downloading

Before Fusaka every consensus node downloaded every blob, so capacity was capped by the bandwidth of a home staker. PeerDAS (EIP-7594), live since December 3, 2025, breaks that link. The data flow:

1. Extend

   Each blob’s 4,096 field elements are erasure coded to 8,192 with a Reed Solomon code. Because the blob is a polynomial, the extension is simply more evaluations of the same polynomial, and any half of the extended data recovers the whole.

2. Cut into cells and columns

   The extended blob is split into 128 cells of 64 field elements, 2,048 bytes each. Cell i of every blob in the block forms column i, so a block has 128 columns however many blobs it carries.

3. Prove every cell

   Each cell has its own KZG proof, checkable against the blob commitment alone. Since Fusaka the blob sender computes them: blob transactions carry proofs for all 128 cells of each blob, including the extension, so block producers do not have to generate them under time pressure.

4. Custody and sample

   Columns are gossiped on 128 subnets, and which columns a node handles is derived from its node id. Every node custodies at least 4 columns and samples at least 8 per slot. A node with validators custodies one column per 32 ETH of attached effective balance, with a minimum of 8 and all 128 from 4,096 ETH up. Any node holding at least half the columns can reconstruct the full matrix and serve it again.

The security argument is short. To make data unrecoverable, an adversary must withhold more than half of the columns. A node that samples 8 random columns and receives all of them is fooled only if every sample landed in the available minority:

A single node can be fooled rarely; a majority of independently sampling nodes practically never. The residual risk is targeted: an adversary who serves columns to some nodes and not others can mislead a few of them, which is why assignments are spread across the network and why reconstruction by well connected nodes matters.

Per node load falls accordingly. A node pulling 8 columns receives 16,384 bytes per blob, one eighth of the blob, which is what made BPO1 and BPO2 possible within weeks of Fusaka. PeerDAS codes each blob in one dimension only; full danksharding, the long term design, would add a second dimension across blobs so that sampling can shrink to individual cells. Fusaka ships custody sampling over column subnets; sampling single cells directly from peers was left out of its scope. The Fulu consensus specs hold the parameters.

Alternative DA layers and what you trust

A rollup can post its data somewhere other than Ethereum, usually at a lower price per byte. The question to ask is always the same: what can the Ethereum contract that holds users’ funds verify about that data?

Celestia

Celestia is a proof of stake chain that orders blobs and does no execution. Block data is laid out as a k × k square of shares, extended with Reed Solomon codes to 2k × 2k, and committed with namespaced Merkle trees, one root per row and per column, so each rollup can fetch and prove only its own namespace. Light nodes sample random shares. Merkle roots cannot show that the extension was computed correctly, so Celestia relies on fraud proofs of bad encoding: a full node that finds an inconsistent row or column can prove it to light nodes. As of September 2026, after its v9 upgrade in July, the governance set maximum block size was 32 MiB, an original square of 256 by 256 shares, and light nodes sample within a 7 day window (CIP-36), with older data kept by archival nodes.

The catch for an Ethereum rollup is that sampling protects Celestia light nodes, not Ethereum contracts. A contract on Ethereum learns about Celestia data through Blobstream, which carries commitments backed by Celestia’s validator set, whether its signatures are relayed directly or checked inside a ZK light client proof. The contract is trusting a two thirds stake majority of Celestia’s validators.

EigenDA

EigenDA is an actively validated service on EigenLayer rather than a chain. A disperser erasure codes each blob, commits to it with KZG and sends chunks to operators in proportion to their restaked stake. Operators sign that they hold their chunks, and the aggregated BLS signature forms a certificate that an Ethereum contract can verify. Throughput scales horizontally because each operator stores only its share. Security is a stake threshold: each quorum’s attestation holds as long as the stake that would have to collude stays below its safety threshold. There is no sampling by end users, so you are trusting that threshold and the penalties behind it; the restaking guide covers how those are enforced.

Avail

Avail is a standalone chain secured by nominated proof of stake. Like Ethereum’s design it commits to each row of block data with KZG and extends each column with Reed Solomon codes, doubling the rows, and because KZG is linear the extended rows’ commitments follow from the originals, so its light clients can check each sampled cell against the header without fraud proofs. As with Celestia, what an Ethereum contract can check is an attestation from Avail’s validators, not the sampling.

DA committees and the validium spectrum

The simplest alternative is a committee. Arbitrum’s AnyTrust design is the clearest example. A committee of N members stores each batch and signs a certificate; the protocol requires N − 1 signatures and assumes at least two members are honest, so at least one honest signer can always serve the data. If the sequencer cannot collect enough signatures within a few minutes, it falls back to posting the full data on L1. That fallback is the important part: a committee can make a chain cheaper, but it should never be able to make it unusable.

The direction of travel is worth noting. Arbitrum Nova, the flagship AnyTrust chain, stopped using its committee on August 31, 2026 and now posts every batch to Ethereum as blobs, which moved it from optimium to rollup in L2BEAT’s classification. Plentiful blob space makes the committee trade harder to justify for a general purpose chain.

Comparing DA costs sensibly

Quoted DA prices are hard to compare because they price different things. A fair comparison asks four questions:

• Cost per usable byte after compression, not per raw byte. Rollups compress batches heavily before posting, and blob packing overhead varies by encoding.
• Price stability. Blob fees are an auction with a floor tied to the execution base fee; other layers may offer fixed or reserved pricing. A rollup that must post on schedule cares about the expensive tail, not the average.
• What the price buys. A cheaper byte that the settlement contract cannot verify buys a weaker assurance. Compare cost at equal security, or put an explicit price on the extra trust assumption.
• Retention and retrieval. Every layer prunes eventually: about 18 days on Ethereum, a 7 day light node sampling window on Celestia. Archival is part of the bill either way.

What comes next

As of September 2026, Ethereum’s DA roadmap runs through further blob parameter only forks and, longer term, two dimensional sampling in full danksharding. The next network upgrade, Glamsterdam, was in final testing with a Sepolia fork scheduled for October 6, 2026; its headline changes, enshrined proposer builder separation (EIP-7732) and block level access lists (EIP-7928), are covered in the PBS guide and the EVM guide. For external layers the useful habit does not change: read what the settlement contract verifies, not what the DA layer’s own light clients verify.

Common questions

Where to go next