Summary
Ethereum’s data availability (DA) roadmap has progressed from EIP-4844 (4 blobs/block, 0.125 MB each) through Fusaka’s PeerDAS (128 data column subnets, up to 21 blobs) toward full Danksharding. A 2026 proposal — Block-in-Blobs (BiB, EIP-8142) — takes this further by encoding execution transactions themselves as blobs, unifying the data gas market and enabling zkEVM-based light and full nodes.
Blob History
| Upgrade | Blob count | DA capacity | Key mechanism |
|---|---|---|---|
| Dencun (Mar 2024) | Target 3, max 6 | ~0.375 MB/block | EIP-4844; blob fee market |
| Fusaka (Dec 2025) | Target 14, max 21 | ~2.6 MB/block | PeerDAS; 128 data column subnets |
| Future (BPO3/4) | 64–128 | ~8–16 MB/block | Full DAS progress |
| Full Danksharding | ~1024 | ~128 MB/block | 2D erasure coding; full DAS |
PeerDAS (Fusaka, Dec 2025)
EIP-7594: Data Availability Sampling via peer-to-peer sampling.
Architecture
- Each blob is extended via erasure coding and split into 128 data columns
- Each node custodies a subset of columns (determined by node ID)
- Any node can sample any column from its peers to verify availability
- Supernodes (≥4,096 ETH or large operators) custody all 128 columns
- Original data can be reconstructed from any ≥50% of columns
Why This Matters
- Nodes no longer need to download all blob data — just their assigned columns
- Bandwidth requirements scale with custody fraction, not total data
- 128 columns × ~2MB each = 256 MB/block total; each node downloads ~1-2 MB
Geographic Requirements
- 128 data column subnets require globally distributed custody
- If validators in one region hold all custodied columns for a subnet, a regional outage eliminates multiple subnets
- PeerDAS’s sampling safety requires columns to be distributed across geographic regions
Block-in-Blobs (BiB, EIP-8142)
BiB proposes encoding Ethereum execution transactions as blobs, with the traditional execution payload becoming a ZK-provable structure derived from blob data.
Design
- Transaction data is encoded as RLP transactions packed into blobs
- The execution payload contains only state diffs + validity proof, not full transaction data
- Blob data undergoes DAS sampling just like L2 blob data
- A unified data gas market replaces the current split between calldata gas and blob gas
Unified Data Gas Formula
data_gas = calldata_size × calldata_weight + blob_count × blob_weight
data_base_fee = f(data_gas, target_data_gas, prev_data_base_fee)
EIP-1559-style adjustment; single base fee for all data. Eliminates the EIP-7623 calldata floor price complexity.
zkEVM Compatibility
BiB is designed for a world with real-time ZK proving (Strawmap’s “Gigagas L1” North Star):
- Execution transactions are publicly available (as blobs, sampled via DAS)
- Any zkEVM prover can prove execution from publicly available transaction data
- Light nodes (stateless + executionless): verify validity proof + sample a few data columns
- Full nodes: download all blob data, re-execute or verify proof
MEV Implications
Under BiB, the block body (transactions) is no longer exclusively in the execution payload — it’s in blobs. This changes the PBS information flow:
- Builders still assemble transactions, but submit them as blob data
- The “execution payload” is just the resulting state diff
- Block body availability = blob availability (sampled by DAS)
- Relay role: may shift from “escrow full block body” to “escrow validity proof + blob commitments”
Calldata vs. Blobs (Current Tradeoffs)
Calldata
- Permanent: stored in block history forever
- Gas price: EIP-1559-style, currently ~16 gas/byte (non-zero) or 4 gas/byte (zero)
- Accessible to EVM during execution (CALLDATALOAD opcode)
- Used by: older rollups, on-chain data feeds, transaction inputs
Blobs (EIP-4844)
- Temporary: pruned after ~18 days (not stored by all nodes permanently)
- Gas price: separate blob fee market (currently near-zero after Fusaka)
- Not accessible to EVM during execution (only the blob commitment hash is available)
- Used by: modern rollups, bulk data publication, future block-in-blobs
EIP-7623 (Calldata Floor Price)
Introduces a minimum gas price for calldata to prevent the calldata market from collapsing. BiB’s unified data gas would make EIP-7623 unnecessary by having a single market for both.
Implications for Block Building
As DA capacity increases and blob fees approach zero:
- L2 posting costs collapse: L2 sequencers’ biggest cost (L1 DA) approaches zero → users benefit from extremely cheap transactions
- L1 blockspace scarcity shifts: the constraint moves from DA to execution (compute gas)
- Builder revenue mix changes: MEV from L2 data posting becomes negligible; execution MEV remains
- Base fee collapse risk: addressed by the minimum base fee floor proposal (1 gwei floor)
Open Questions
- When does BiB shipping unify data gas? (Targeted for a post-Hegotá fork, ~2027)
- How does DAS interact with encrypted mempools? (Encrypted blobs are samplable but not readable — is this sufficient for security?)
- With BiB, can the execution payload be made very small (just state diff + proof), reducing block propagation time significantly?
Related Pages
- Block-Level Access Lists (BALs) and Parallel Execution (EIP-7928) — BALs enable faster execution of transactions published via BiB
- Ethereum Protocol Roadmap 2026 — PeerDAS (Fusaka, Dec 2025); BiB in future forks
- Fee Markets: EIP-1559, Multidimensional Pricing, and Minimum Base Fee — Unified data gas; base fee floor
- L2 Fee Vault: Pricing L1 Costs with Feedback Control — L2 sequencer costs impacted by blob fee collapse
Key Sources
- Blocks Are Dead. Long Live Blobs (EIP-8142 / BiB, 2026) — BiB design; unified data gas formula; zkEVM DA path
- Ethereum’s Geographic Blind Spot (Four Pillars, Mar 2026) — PeerDAS architecture; 128 column subnets; geographic distribution requirements