7Block Labs
Blockchain Technology

ByAUJay

Designing Rollup SDKs Around Blobs: The New Default for Posting Data

Blobs are now the standard way rollups post data to Ethereum. This guide shows decision‑makers and engineering leaders how to design rollup SDKs that treat blobspace as the default, with concrete parameters, APIs, pricing logic, failover patterns, and migration steps you can ship today.

Summary: Since Ethereum’s Dencun (March 13, 2024) and Pectra (May 7, 2025) upgrades, blobspace provides cheap, ephemeral data slots tailored for rollups, doubling capacity to a 6/9 target/max per block—and more coming with PeerDAS in December 2025. Building your rollup SDK “blob‑first” cuts costs, hardens UX, and future‑proofs your chain. (ethereum.org)


Why “blob‑first” is the default in 2025

  • Dencun activated EIP‑4844 blobs, a new transaction type (0x03) whose data lives in the consensus layer for ~18 days, priced by a separate blob gas market. This decouples rollup DA from EVM gas and permanently lowers L2 posting costs. (eips.ethereum.org)
  • Pectra doubled blob throughput: target blobs per block 3 → 6 and max 6 → 9, further compressing posting costs and smoothing spikes. Etherscan exposes live blob counts, making operations observable. (blog.ethereum.org)
  • The next upgrade (Fusaka, scheduled Dec 3, 2025) ships PeerDAS, letting nodes sample instead of downloading all blob data, paving the way for much higher blob targets. Plan for more capacity, not less. (coindesk.com)

Bottom line: you should design your SDK to post to blobs by default, with intelligent fallbacks for rare congestion events.


The exact blob primitives your SDK must understand

  • Size and units
    • A blob is 4096 field elements × 32 bytes = 131,072 bytes. GAS_PER_BLOB = 2^17; the block limits are expressed in “blob gas.” (eips.ethereum.org)
  • Lifetime
    • Blobs are available ~18 days (4096 epochs), then pruned, while commitments stay forever. Your SDK must plan archival. (ethereum.org)
  • Type‑3 transactions
    • Fields add max_fee_per_blob_gas and blob_versioned_hashes (versioned KZG commitment hashes). (eips.ethereum.org)
  • New block header fields
    • blob_gas_used and excess_blob_gas allow you to compute the blob base fee and monitor congestion. Libraries (e.g., ethers v6) surface blobGasUsed on Block objects. (eips.ethereum.org)
  • EVM opcodes and precompile you can leverage
    • BLOBHASH (0x49) exposes versioned hashes to contracts.
    • BLOBBASEFEE (0x4a) returns the current blob base fee (per EIP‑7516).
    • Point‑evaluation precompile at 0x0A (50k gas) verifies KZG proofs against a versioned hash. (eips.ethereum.org)
  • Replacement rules
    • Mempools usually require a 1.1× bump on base fee per blob gas for transaction replacement. Budget for this in your fee escalators. (eips.ethereum.org)
  • RPCs you’ll actually call
    • JSON‑RPC eth_blobBaseFee (widely supported by providers) to read current blob base fee; Beacon REST eth/v1/beacon/blob_sidecars/{block_id} to fetch blobs for verification/archival. (quicknode.com)

The blob fee market and how to price posts

  • Independent fee market
    • Blob base fee adjusts EIP‑1559‑style around a per‑block target (6 after Pectra). If usage is below target, prices decay toward the minimum. (info.etherscan.com)
  • Concrete arithmetic you need in code
    • Total blob fee per tx = get_base_fee_per_blob_gas(header) × GAS_PER_BLOB × number_of_blobs. Read base fee from header (or eth_blobBaseFee). (eips.ethereum.org)
  • Calldata vs blobs
    • Calldata still costs 4/16 gas per byte (zero/non‑zero), with new EIPs raising floor costs for data‑heavy txs (EIP‑7623 live via Pectra; EIP‑7976 proposed). This nudges DA usage into blobs and makes “blob‑first” a safe default. (eips.ethereum.org)
  • Observed post‑Pectra market
    • After the 6/9 increase, blob usage has often been below target, making blobs “near minimum” most of the time and materially cutting L2 DA spend; daily capacity rose to ~8.1 GB at max. (panewslab.com)

Emerging proposals like EIP‑7762 and EIP‑7918 tweak blob pricing bounds; design your SDK to treat these as parameters, not constants. (eips.ethereum.org)


Posting policy: make “blobs” the default, with guardrails

Your batcher/sequencer should implement these five behaviors:

  1. Compression and packing
  • Use brotli at high levels (OP Stack exposes zlib/brotli flags; Nitroware uses brotli) and target >90% blob utilization. Average utilization across rollups is ~118.3 KB/131.1 KB—there’s room to optimize. (docs.optimism.io)
  • Pre‑pack batch chunks to exact blob boundaries (131,072 bytes) and simulate “add one more tx?” to avoid spilling into a second blob. Track utilization by chain and time of day. (eips.ethereum.org)
  1. Multi‑blob batching, but don’t overshoot
  • After Pectra, blocks can include up to nine blobs, but stuffing many blobs into one tx increases replacement risk and builder sensitivity. Prefer 1–3 blobs per tx and additional txs over “mega‑blob txs” unless you run private builder routes. (Engineering guidance; validate against your builders.)
  1. Fee caps and replacement logic
  • Always set both max_fee_per_gas and max_fee_per_blob_gas. Implement a replacement ladder that bumps both by ≥1.1×, with backoff timers; Arbitrum’s batch‑poster includes practical RBF schedules you can mirror. (docs.arbitrum.io)
  1. Smart fallback when blob prices spike
  • OP Stack supports data-availability-type=auto to switch between blobs and calldata. Arbitrum lets you ignore blob price or enforce protection windows that reduce thrashing. Implement a policy engine:
    • Default: blobs
    • If predicted blob fee > calldata (including EIP‑7623 impact) for N consecutive polls → temporary switch
    • Hysteresis: require M blocks at favorable blob price before switching back. (docs.optimism.io)
  1. Beacon‑aware posting windows
  • Schedule around the target of 6 blobs per block to minimize base‑fee nudges. During bursts, spread bundles across multiple blocks to avoid precipitating rapid fee hikes. (Your pricing model can use current excess_blob_gas to anticipate the next block’s base fee.) (eips.ethereum.org)

Read path, fraud/validity proofs, and blob archival

  • Retrieval: fetch blob sidecars from a Beacon node via eth/v1/beacon/blob_sidecars/{block_id} by head/slot/root; cache locally. Multiple RPC providers (Ankr, Blockdaemon, others) expose Beacon APIs. (quicknode.com)
  • On‑chain verification: rollup inbox contracts use the point‑evaluation precompile (0x0A) to check KZG proofs against versioned hashes that your L2 emitted. ZK rollups like zkSync already chunk batches into multiple blobs and verify per‑blob proofs in their L1 contracts. (eips.ethereum.org)
  • Archival strategy: blobs expire ~18 days; your SDK must operate an “archiver” service to store raw sidecars (e.g., S3/IPFS/Arweave). Providers note you—not Ethereum—are responsible for long‑term DA beyond the protocol window. (docs.chainstack.com)
  • Observability: expose blob counts and fees in your ops dashboards; Etherscan’s /txsBlobs and block pages make reconciliation easy. Integrate alerts when utilization falls <80% or when base fee rises >X% block‑over‑block. (info.etherscan.com)

API surface: what your SDK should expose

  • Pricing
    • getBlobBaseFee(): reads eth_blobBaseFee; fall back to computing from excess_blob_gas if provider lacks the method. (quicknode.com)
  • Packing
    • packToBlobs(batch, compressor=‘brotli‑11’): returns N × 131,072‑byte segments + versioned hashes.
  • Posting
    • submitBlobTx(blobs[], maxFeePerBlobGas, gasCaps): sends 0x03 tx; supports RBF with ≥1.1× bumps. (eips.ethereum.org)
  • Fallback
    • chooseDA({calldataFloorRules, blobBaseFee}): returns 'blobs'|'calldata' based on thresholds (include Pectra’s calldata repricing behavior). (ethereum.org)
  • Retrieval & proof
    • getBlobByBlockId(blockId): Beacon fetch; verify with KZG proofs via precompile address 0x0A. (quicknode.com)
  • Archival
    • archiveBlobs(blobs, policy): pluggable backends (S3, IPFS, Arweave) with TTL aligned to dispute windows. (Arweave SDKs/gateways can help when you want durable, public storage.) (docs.arweavekit.com)

Calldata is the escape valve—not your default

  • Cost reality: calldata is priced per byte (4/16 gas), and post‑Pectra rules increase costs for data‑heavy txs to keep the p2p layer healthy. Your SDK should only fall back to calldata under explicit policy or emergency conditions. (eips.ethereum.org)
  • Operational reality: OP and Arbitrum both recommend blob posting when available; they expose switches and flags to force or auto‑select blobs. Mirror these in your SDK to provide predictable behavior across stacks. (docs.optimism.io)

Multi‑DA abstractions: Celestia, EigenDA, Avail—without giving up blob defaults

Your customers may want optional DA modes for further cost control. Build DA as a pluggable interface:

  • Ethereum Blobs (default)
    • Strongest L1 alignment and simplest trust model; use for settlement‑critical data and to minimize bridge complexity.
  • Celestia via Blobstream (SP1)
    • Celestia’s on‑chain light client on Ethereum verifies Celestia headers with ZK proofs; your L1 contracts can verify Celestia data root commitments for inclusion proofs. Build a “CelestiaDA” driver that writes to Celestia and relays commitments to L1 via Blobstream contracts. (docs.celestia.org)
  • EigenDA (EigenLayer AVS)
    • Use the EigenDA Proxy sidecar within your rollup node cluster for dispersal and reads; verify DA certificates on L1 (EigenDAServiceManager). Proxy includes failover signals (HTTP 503) so your batcher can automatically revert to L1 blobs if EigenDA stalls. (docs.eigencloud.xyz)
  • Avail DA
    • Mainnet DA live since July 2024; integrate via their light clients and attestation bridge. Keep Ethereum blobs as the “safety floor” for settlement‑critical frames. (theblock.co)
  • NEAR DA
    • Available in Polygon CDK; treat as an optional driver in your SDK for ZK rollups built on CDK, with a clear security/composability disclosure in your UI. (pages.near.org)

Implementation example: Orbit + EigenDA
Arbitrum Nitro exposes flags to enable the EigenDA Proxy; your SDK can auto‑detect and write the correct node config, then post the certified header to the rollup inbox. (docs.eigencloud.xyz)


Contract‑level changes you should ship

  • Store versioned hashes; don’t store blobs
    • Contracts should store blob versioned hashes and verify KZG proofs via the point‑evaluation precompile when needed. (L1 cannot access blob data directly.) (eips.ethereum.org)
  • Fee‑aware accounting
    • If you meter prover/sequencer fees on‑chain, use the BLOBBASEFEE opcode to price blob consumption trustlessly. (eips.ethereum.org)
  • Eventing for off‑chain retrieval
    • Emit the mapping between batch IDs and blob versioned hashes; your off‑chain archiver can subscribe and fetch sidecars from Beacon nodes.

Practical configuration examples (copy/paste into runbooks)

  • OP Stack batcher
    • Set compression-algo=brotli‑10/11 in high‑volume periods; data-availability-type=auto; alert when utilization < 80%. (docs.optimism.io)
  • Arbitrum batch poster
    • Enable EIP‑4844 posting and monitor numBlobs in logs; set ignore-blob-price=false (default) and provide “force blobs” switches for emergencies. Configure RBF timings using the provided defaults. (docs.arbitrum.io)
  • zkSync-style chunking
    • Chunk pubdata into up to six blobs per batch; verify per‑blob with point‑evaluation in Executor.sol; emit six system logs (one per commitment). Use this as a template for ZK chains integrating blobs. (docs.zksync.io)

Monitoring and SRE guardrails

  • Price and capacity
    • Poll eth_blobBaseFee; compute prospective fee one block ahead using excess_blob_gas; alert on >25% block‑over‑block jumps. Expose target vs actual blobs per block in Grafana. (quicknode.com)
  • Health
    • Watch Beacon endpoints for blob_sidecars availability; multi‑home across providers. Fall back to calldata if Beacon reads fail for >N minutes. (ankr.com)
  • Forensics
    • Reconcile your posted blobs with Etherscan’s blob views; surface utilization metrics per blob (bytes used / 131,072). (info.etherscan.com)
  • Archival
    • Enforce retention beyond 18 days with a policy engine (e.g., 30–180 days on S3 or permanent on Arweave); checksum data against KZG commitments for integrity. (docs.chainstack.com)

Roadmap: design for 2026‑grade scale now

  • Pectra already doubled blob throughput (6 target / 9 max). Your SDK should make these parameters configurable. (info.etherscan.com)
  • Fusaka introduces PeerDAS (December 3, 2025), enabling much higher blob targets without overwhelming nodes. Expect additional “blob‑param‑only” forks to raise caps; keep your limiters and packers flexible. (coindesk.com)

A crisp checklist for leaders

  • Product
    • Make “blobs” the default DA setting; expose a clearly labeled fallback.
  • Engineering
    • Implement packing to 131,072‑byte boundaries, brotli‑11 for high throughput, and a dual‑cap RBF escalator (gas + blob gas).
  • Security
    • Verify KZG proofs on‑chain; archive raw sidecars beyond 18 days; test reorg and retrieval failures.
  • Ops
    • Monitor eth_blobBaseFee, blob_gas_used, excess_blob_gas; schedule around blob targets; reconcile with Etherscan’s blob views. (quicknode.com)

How 7Block Labs can help

We’ve migrated OP Stack and Nitro deployments to blob‑first posting, built DA‑pluggable SDKs (Ethereum Blobs/Celestia/EigenDA/Avail), and tuned compressors and posting policies to hit >95% blob utilization with clean failover. If you want a blob‑first SDK that’s future‑proof for PeerDAS, we’ll ship it with your observability and SLOs in weeks—not quarters.


Sources and specs worth bookmarking

  • EIP‑4844 spec: constants, header fields, fee math, BLOBHASH/point‑evaluation, and the 1.1× replacement suggestion. (eips.ethereum.org)
  • Cancun‑Deneb (Dencun) and Pectra upgrade pages: activation dates, blob lifetime, and 6/9 throughput. (ethereum.org)
  • eth_blobBaseFee RPC and ethers v6 fields for blobGasUsed. (quicknode.com)
  • Beacon API blob_sidecars endpoints (for retrieval/archival). (quicknode.com)
  • OP Stack batcher and Arbitrum post‑4844 configuration guides. (docs.optimism.io)
  • zkSync post‑4844 pubdata handling (multi‑blob batch design). (docs.zksync.io)
  • Celestia Blobstream (SP1) and EigenDA integration docs. (docs.celestia.org)

Design for blobs first. Your users will feel it in fees and reliability; your ops will feel it in predictability; and your roadmap will be ready for the blobspace of 2026.

Like what you're reading? Let's build together.

Get a free 30‑minute consultation with our engineering team.

Related Posts

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2025 7BlockLabs. All rights reserved.