EIP-7691 Ethereum Blob Capacity and Blob Throughput Increase: What It Means for Rollup Proof Throughput

EIP-7691 doubled Ethereum’s target blob capacity from 3→6 and raised the max from 6→9 in the May 7, 2025 Pectra upgrade; since then, PeerDAS-enabled “BPO” bumps have lifted the limit further to a 14/21 target/max (Jan 7, 2026). This post explains exactly what changed, why blob fees behave differently now, and how L2 teams should tune batchers, provers, and budgets to raise rollup proof throughput safely. (blog.ethereum.org)

TL;DR for decision‑makers

What changed: EIP‑7691 raised blob capacity to 6/9 in Pectra; after PeerDAS shipped in December 2025, Ethereum executed two small “BPO” blob‑only forks to 10/15 and then 14/21 blobs per block (today, Jan 7, 2026). (blog.ethereum.org)
Why you care: More L1 data availability (DA) headroom lowers L2 posting costs and lets you post more batches/proofs per unit time, shrinking finality delays; but calldata for proofs didn’t get cheaper, and fee responsiveness changed, so batchers and budget guards must be retuned. (eips.ethereum.org)

1) What EIP‑7691 actually changed

Pectra (Prague × Electra) activated on May 7, 2025 at epoch 364032, bringing EIP‑7691 live on mainnet. It updated Ethereum’s blob market parameters, moving the target/max from 3/6 to 6/9 and retuning the “base fee update fraction” so price movements are asymmetric. Concretely: (ethereum.org)

Target blobs per block: 6 (was 3)
Max blobs per block: 9 (was 6)
TARGET_BLOB_GAS_PER_BLOCK: 786,432; MAX_BLOB_GAS_PER_BLOCK: 1,179,648; GAS_PER_BLOB: 131,072. (eips.ethereum.org)

The new 2:3 target:max ratio intentionally breaks the old symmetry (1:2). With 6/9, a “full” blob section raises the blob base fee ≈8.2% per block, while an “empty” section drops it ≈14.5%, smoothing spikes and accelerating price declines after quiet periods. (eips.ethereum.org)

In December 2025, PeerDAS (EIP‑7594) enabled sampling‑based availability checks, and Ethereum introduced “Blob Parameter Only” (BPO) mini‑forks to raise blob limits without a full protocol release: BPO1 to 10/15 (Dec 9, 2025) and BPO2 to 14/21 (Jan 7, 2026). (blog.ethereum.org)

2) Blob capacity in real numbers (and why it matters to proof throughput)

Blobs are fixed‑size chunks of 131,072 bytes (128 KiB), priced in a separate EIP‑1559‑style market (“blob gas”), with one blob consuming exactly GAS_PER_BLOB=2^17 blob‑gas units. The EVM can’t read blob contents; contracts only see commitments and use the KZG point‑evaluation precompile to verify availability. (eips.ethereum.org)

Because Ethereum produces one block every 12 seconds (≈7,200/day), the daily DA headroom from blobs is straightforward to plan for:

Pectra (6/9):
- Target/day ≈ 6 × 128 KiB × 7,200 ≈ 5.27 GiB
- Max/day ≈ 9 × 128 KiB × 7,200 ≈ 7.91 GiB
BPO1 (10/15):
- Target/day ≈ 8.79 GiB; Max/day ≈ 13.18 GiB
BPO2 live today (14/21):
- Target/day ≈ 12.30 GiB; Max/day ≈ 18.46 GiB

That is a 2.3× increase in daily target capacity vs pre‑Pectra and 3.5× vs Dencun’s original target, meaning more batches/proofs can clear L1 per unit time, even if your average blob fill rate remains in the 80–90% range seen on mainnet. (eips.ethereum.org)

Post‑Pectra market data showed DA costs collapsing: Galaxy tracked daily blob purchases rising ~21k→~25.6k with average blobs/block still below the new target, making “blob objects” effectively free for stretches and pushing consensus‑node retention (≈18 days) to ~44.6 GiB in the first week after Pectra. For platform teams, that meant room to increase posting cadence without cost blowups. (galaxy.com)

3) Fees: blobs vs calldata after Pectra

Blob cost: charged in “blob gas” at base_fee_per_blob_gas, with price changes computed via the same exponential mechanism as execution gas (but using the blob schedule’s update fraction). You can read the current blob base fee inside EVM via the BLOBBASEFEE (0x4a) opcode (EIP‑7516). (eips.ethereum.org)
Calldata cost: Pectra also raised calldata floor prices for data‑heavy txs via EIP‑7623 to reduce worst‑case block size variance; the effective floor is 10/40 gas per zero/non‑zero byte when the tx is predominantly DA, making fallback from blobs to calldata less attractive except during extreme blob congestion. (eips.ethereum.org)

Rule of thumb for your batcher’s “fallback to calldata” guardrail:

Let S be your compressed batch payload size in bytes (what you would otherwise put in a blob).
Blob fee per batch ≈ 131,072 × blob_base_fee (wei per blob‑gas).
Calldata floor fee per batch ≈ 10×zeros + 40×nonzeros (gas), then multiply by execution base fee (wei/gas).
Break even when 131,072 × blob_base_fee ≈ (calldata_gas) × base_fee_per_gas. Because EIP‑7623 raises the floor for DA‑heavy txs, the break‑even blob_base_fee can be materially higher than before, so your previous thresholds likely under‑post to blobs and over‑use calldata under stress. (eips.ethereum.org)

4) “Proof throughput” defined — and why more blobs help

For validity rollups, “proof throughput” is how frequently you can finalize new L2 state on L1 with a validity proof, while for optimistic rollups it’s the frequency and timeliness of commitments and (rare) fraud proofs. Blob capacity primarily governs how often you can publish batch data (state inputs) at your desired latency; proofs themselves are small for SNARK‑based systems but can be very large for on‑chain STARK verification. (eips.ethereum.org)

SNARK verification (e.g., Groth16) is typically ~200–300k gas with ~256–900 bytes of calldata. This part didn’t get cheaper from EIP‑7691—but it’s already small. (medium.com)
Raw STARK verification can cost millions of gas and 100–200 kB of calldata; most teams wrap STARKs in a small SNARK to reduce on‑chain verification cost. EIP‑7691 helps indirectly here by making DA cheaper for the batch data, but proof calldata is still priced as calldata and sees the EIP‑7623 floor. (community.starknet.io)

Net effect: with a 14‑blob target, you can post more batches per block and shorten your “batch→proof→finalize” loop, raising proof throughput even if your on‑chain verification cost per proof is unchanged.

Example: If your compressed batch is ~300 KiB, then under today’s 14‑blob target you have ≈1.75 MiB of target DA per block; you can fit five such batches per block under target versus three under the old 6‑blob target. If your prover latency is the bottleneck, this headroom lets you (a) parallelize provers against smaller, more frequent batches, or (b) keep batch size stable and reduce time‑to‑finality. (eips.ethereum.org)

5) Operational consequences you should plan for

Retune fee guards and posting cadence

Update blob scheduling constants in your fee estimators and analytics to track per‑fork target/max and sensitivity. EIP‑7840 standardized a “blobSchedule” in EL config so tooling can read correct per‑fork values (Cancun/Dencun → Prague/Pectra → BPOs). (eips.ethereum.org)
Recalibrate max_fee_per_blob_gas and your “don’t post above X” rules to the 6/9→14/21 world. Because the 2:3 ratio makes prices drop faster below target and rise slower above target, you can safely increase posting cadence without as many refuse‑to‑post events. (eips.ethereum.org)

Size and fill your blobs better

A blob is always 131,072 bytes; you pay for the whole blob, so target ≥95% fill. Galaxy observed average fill rates around mid‑80s%; raising fill improves effective $/byte and overall throughput. (eips.ethereum.org)
If your average batch is much smaller than a blob, implement packing across streams (e.g., multi‑queue coalescing) to reduce fragmentation.

Proof pipeline specifics

SNARK paths: with Groth16‑style proofs ≈220–300k gas, proof verification remains a rounding error next to DA; prioritize batch DA scheduling first. (medium.com)
STARK paths: if you verify raw STARKs on L1, expect millions of gas and 100–200kB calldata per proof; wrapping to a small SNARK or verifying off‑chain (then attesting) is still the default for Ethereum L1 economics. (community.starknet.io)

Fallback to calldata: narrow and explicit

With EIP‑7623’s floor (10/40 gas per byte) for DA‑heavy calldata, treat calldata as a surge valve, not a default. Compute per‑batch break‑evens at runtime; prefer blobs unless blob_base_fee spikes well above historical percentiles. (eips.ethereum.org)

Monitoring and SLOs

Track blob_gas_used, excess_blob_gas, and BLOBBASEFEE on every head block. Switch to “fast posting” when below target (cheap) and apply back‑pressure when excess_blob_gas jumps. The EVM opcode BLOBBASEFEE (0x4a) makes on‑chain accounting feasible. (eips.ethereum.org)
Watch P2P sidecar availability and hit‑rates; research showed only ~70% of blocks included blob txs in sampled windows pre‑PeerDAS—patterns change post‑PeerDAS, but instrumentation still matters. (ethresear.ch)

6) Hard numbers you can use in planning

Blob size, units, and retention
- 128 KiB exactly (4096 × 32 bytes); GAS_PER_BLOB = 131,072 blob‑gas. Pruned after ~4096 epochs (~18 days); commitments stay. (eips.ethereum.org)
Throughput headroom by era (target per day, binary GiB)
- Dencun (3): ~2.64 GiB
- Pectra (6): ~5.27 GiB
- BPO1 (10): ~8.79 GiB
- BPO2 live (14): ~12.30 GiB
  Use max numbers for peak‑load safety margins (e.g., 21 max ≈18.46 GiB/day today). (blog.ethereum.org)
Price responsiveness (approximate)
- With 6/9 and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE, full blob sections raise price ≈8.2%/block; empty sections drop ≈14.5%/block. That asymmetry is by design to speed recovery. (eips.ethereum.org)
Post‑Pectra market snapshot
- Daily blobs purchased rose ~21,200→~25,600; average usage below target made blobs “virtually free” for days; CL node DA retention peaked ~44.6 GiB in the first week. (galaxy.com)

7) Example: re‑tuning a rollup for higher proof throughput

Assume your rollup today:

Average compressed batch: 280–320 KiB (call it 300 KiB).
Prover generates one Groth16 proof per batch in ~90 seconds; on‑chain verification ~250k gas plus ~300–600 bytes of calldata. (medium.com)

Under Pectra (6‑blob target):

Per block target DA ≈ 768 KiB, so you can fit 2 full batches under target; the 3rd batch often pushes above target, nudging blob_base_fee up.

Under BPO2 live (14‑blob target):

Per block target DA ≈ 1.75 MiB, so you can fit 5×300 KiB batches under target. Strategy:
1. Post every 24 seconds (2 slots) to reduce L2 finality without piling demand in a single slot.
2. Keep max_fee_per_blob_gas at the 95th percentile of the last 7 days, and a soft cap at the 80th percentile; with the 2:3 target:max responsiveness, you will see faster reversion after lulls. (eips.ethereum.org)
3. Maintain a 2‑blob reserve for spikes to avoid falling back to calldata under EIP‑7623’s floor pricing. (eips.ethereum.org)

Result: proof throughput rises from ~1 proof every 90s to ~1 proof every 24–36s (assuming prover parallelism and sufficient capacity), with blob costs staying near minimum most of the time. Monitor excess_blob_gas and scale cadence adaptively.

8) Emerging best practices we see working

Blob‑first, calldata‑last: Make blobs your default DA path; re‑price calldata fallbacks using the EIP‑7623 floor and only trigger them on rare spikes or when latency SLOs force it. (eips.ethereum.org)
Aim for ≥95% blob fill: implement packing across streams and time‑boxing so your average fill approaches 120–126 KiB; it directly improves $/byte. Galaxy’s post‑Pectra fill rate observations (~86%) show there’s headroom. (galaxy.com)
Use BLOBBASEFEE on‑chain: Expose BLOBBASEFEE in your settlement contracts for transparent cost accounting or futures/hedging mechanisms around blob gas. (eips.ethereum.org)
Separate posting cadence from proving cadence: If provers are the bottleneck, decouple batch posting (to lock in DA cheaply and frequently) from proof generation and verification, then aggregate proofs if helpful. Modern SNARK aggregation keeps verification ≲300k gas plus small per‑proof overhead. (medium.com)
Watch sidecar availability and networking: PeerDAS changes the distribution of load, but validators and builders still rely on healthy blob gossip; keep observability on sidecar hit‑rates to catch pathologies early. (ethresear.ch)

9) What’s next on the roadmap

PeerDAS is active (Dec 3, 2025 Fusaka); the network now uses “BPO” bumps to raise blob limits with low coordination overhead. BPO2 to 14/21 landed today (Jan 7, 2026). Teams should expect further parameterization as demand grows, managed via the standardized blob schedule config introduced by EIP‑7840. (blog.ethereum.org)
Proposals like EIP‑7918 (bounding blob base fee by execution cost) are being discussed; keep an eye on fee‑coupling changes that could alter break‑even thresholds between blobs and calldata. (eips.ethereum.org)

10) Action checklist for startup and enterprise leaders

Confirm your infra is Pectra/PeerDAS/BPO‑ready: clients on current versions and monitoring of blob_gas_used/excess_blob_gas/BLOBBASEFEE in place. (blog.ethereum.org)
Re‑baseline budgets: shift DA cost models to a 14/21 target/max world; assume blobs remain near minimum much of the time, but test spikes. Use EIP‑7840’s blobSchedule to drive estimators. (eips.ethereum.org)
Raise posting cadence to hit latency SLOs: take advantage of the higher per‑block target to post smaller, more frequent batches without crowding under target.
Keep proofs small: prefer SNARK verification on L1 where possible; if you’re STARK‑native, consider wrapping to keep calldata and gas manageable. (medium.com)
Document your fallback policy: explicitly define when to switch from blobs to calldata using the EIP‑7623 floor math, and test it in staging. (eips.ethereum.org)

Appendix: quick reference

Pectra mainnet activation: May 7, 2025, 10:05 UTC (epoch 364032). (ethereum.org)
EIP‑7691 parameters: target 6, max 9; asymmetric fee sensitivity (≈+8.2% full, ≈−14.5% empty). (eips.ethereum.org)
Blob basics: 131,072 bytes per blob; GAS_PER_BLOB=131,072; blobs pruned after ~4096 epochs (~18 days). (eips.ethereum.org)
Calldata floor (EIP‑7623): DA‑heavy txs pay at least 10/40 gas per zero/non‑zero byte. (eips.ethereum.org)
PeerDAS + BPOs: Fusaka Dec 3, 2025; BPO1 to 10/15 (Dec 9, 2025), BPO2 to 14/21 (Jan 7, 2026). (blog.ethereum.org)

If you want hands‑on help, 7Block Labs can benchmark your circuits, right‑size your GPU fleet, and implement a blob‑first batcher with safe fallback and live cost guards in a few weeks. We’ll bring dashboards for blob gas, calldata floors, and proof KPIs so you can raise throughput without surprises.