Skip to content
Financial Context Wiki

Blobspace

A verification-first guide to Ethereum blobspace, encoded and usable capacity, PeerDAS sampling and custody, temporary retention, rollup derivation and current fork-dependent limits.

Updated

For educational purposes only; not financial or security advice. Blob schedules, PeerDAS assumptions, client behavior, rollup derivation and archival access can change or fail.

Direct answer

Blobspace is Ethereum’s bounded, temporary data-availability capacity for blobs committed alongside blocks. It is not EVM execution blockspace, contract storage, a permanent filesystem or a token. A type-3 transaction contains versioned hashes; authenticated blob data travel through consensus-layer sidecars or PeerDAS data columns. The EVM can inspect a versioned hash and verify an opened point, but it cannot directly read the blob payload.

PeerDAS erasure-extends blobs, divides the extended matrix into 128 columns and lets nodes custody and sample subsets instead of requiring every node to download every full blob. This supports a probabilistic local availability judgment, not proof of rollup execution validity, Ethereum finality, bridge safety or permanent retrieval. Capacity changes by fork. As of 2026-08-13, Ethereum mainnet after Fusaka BPO2 targets 14 blobs per block and permits at most 21; each blob transaction is limited to 6 blobs.

How it works

  1. Pin the network, block or slot, active fork and Blob-Parameter-Only schedule, plus the rollup and derivation version. Historical 3/6, Pectra 6/9, current 14/21, testnet and future parameters are not interchangeable.
  2. Identify the publication object: type-3 transaction, versioned hashes, KZG commitments and proofs, blob indexes, L1 origin and whether the rollup actually used Ethereum blobs rather than calldata or alternative DA. A commitment binds data but does not alone prove that the bytes were available.
  3. Keep units separate. One blob has 4,096 field elements * 32 bytes = 131,072 encoded bytes; unrestricted payload generally uses 31 bytes per field element, or 126,976 usable bytes. Compression, framing, padding, blob gas, erasure-expanded cells and application bytes are different quantities.
  4. Verify schedule limits. The target guides the pricing feedback; it is not reserved capacity. The block maximum is a consensus ceiling, not expected throughput. PeerDAS’s 6 blobs per transaction is distinct from the current 21 blobs per block maximum.
  5. Verify the availability path. PeerDAS uses one-dimensional erasure extension, authenticated cells and columns, gossip and peer requests. A node samples at least 8 columns under current parameters and has custody duties; acquiring at least 64 of 128 columns permits reconstruction of the extended matrix.
  6. Track separate lifecycle states: commitment included, data columns obtained and verified, local DA check passed, L1 block safe or finalized, rollup batch decoded and derived, minimum serving window active, and independent archive tested. Availability does not make every later state true.
  7. Rehearse missing columns, eclipse or partition, delayed propagation, L1 reorganization, schedule or client mismatch, rollup-format upgrade and archive loss. Retrieve, reconstruct and preserve needed data before the protocol window expires, and use the separate blob-fee topic for batcher and user cost accounting.

Worked examples

  • One blob’s byte units. Encoded capacity is 4,096 * 32 = 131,072 bytes = 128 KiB. General arbitrary payload is 4,096 * 31 = 126,976 bytes = 124 KiB. The difference is 4,096 bytes, or 3.125% of encoded capacity; rollup compression and framing reduce application payload further.
  • Current per-block capacity. At target, 14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB and 14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB. At maximum, 21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB and 21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB. These are mainnet, date-specific, per-block limits before compression and framing.
  • Transaction and block limits. A transaction with 6 blobs carries 786,432 encoded bytes = 0.75 MiB and 761,856 usable bytes = 0.7265625 MiB. A maximum 21-blob block needs at least 4 transactions, for example 6 + 6 + 6 + 3; a target 14-blob block can be 6 + 6 + 2. Neither allocation is a per-rollup reservation.
  • Serving window and nominal volume. 4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days. At a nominal 7,200 slots per day and 14-blob target, encoded volume is 100,800 blobs per day = 12.3046875 GiB per day, while generally usable volume is 11.920166015625 GiB per day. Missed slots and actual inclusion change the realized total, and the serving window is not a permanent archive promise.

Risks

  • Applying a stale fork or Blob-Parameter-Only schedule.
  • Mixing mainnet, testnet or another network’s limits.
  • Treating the target as guaranteed or reserved capacity.
  • Treating the maximum as normal expected throughput.
  • Confusing the six-blob transaction limit with the block limit.
  • Mixing encoded, usable, compressed, framed and blob-gas units.
  • Omitting padding or rollup-format overhead.
  • Labeling calldata or alternative DA as Ethereum blobspace.
  • Accepting a versioned hash that does not match the blob commitment.
  • Treating a valid KZG opening as proof that bytes were available.
  • Treating sampling as a full local download of every blob.
  • Confusing data availability with state-transition validity.
  • Confusing a local DA check with L1 or rollup finality.
  • Losing columns through delay, eclipse, partition or correlated peers.
  • Failing reconstruction or peer request despite nominal capacity.
  • Losing or reordering the commitment in an L1 reorganization.
  • Letting the minimum serving window expire before derivation or challenge.
  • Depending on an unavailable, corrupt or incomplete archive or indexer.
  • Failing rollup derivation after a compression or protocol upgrade.
  • Assuming bridge or exit safety merely because blob data were available.

Common misconceptions

  • Blobspace is permanent storage that contracts can read like calldata.
  • Every byte of a 128 KiB blob is unrestricted application payload.
  • Every Ethereum node downloads and permanently stores every full blob under PeerDAS.
  • A KZG commitment, successful sample or finalized inclusion proves the rollup state is correct and users can exit.
  • Mainnet capacity is permanently fixed at 3/6, 6/9 or the current 14/21 schedule.

Sources

Navigation

Search the wiki...