EIP-4844 introduces blob transactions with a separate fee market and a fixed retention window. What blobs are, how KZG verification works, and what L2 teams must change.
EIP-4844 introduces a dedicated data channel on Ethereum called a blob, letting rollups publish batch data through a separate transaction type and a separate fee market instead of embedding it in execution layer calldata. Blob data is held by consensus clients for a fixed window and then pruned, so the execution layer never stores it permanently and only ever handles a cryptographic commitment to it.
The design has direct consequences for sequencer implementation, inbox contract logic, proof systems, and capacity planning. The sections below cover what a blob is, how verification works without the data itself, how the blob fee market behaves as an independent resource lane, how capacity has scaled since activation, and which parts of a rollup stack have to change.
Before EIP-4844, rollups published compressed batches as calldata to an inbox contract on L1. That approach worked but carried two structural problems.
The first was permanence. Calldata becomes part of execution layer history and every full node retains it indefinitely, even though rollup batch data only needs to be available long enough for anyone to reconstruct L2 state or challenge a fraud proof. The network paid for indefinite storage of data with a bounded useful life.
The second was resource coupling. Calldata competes for the same block gas as every other transaction, so demand from unrelated L1 activity propagated directly into rollup data publication. Rollup operating conditions moved with L1 congestion regardless of what was happening on the rollup itself.
Blobs address both. Blob data lives on the consensus layer with an explicit retention window, and it is metered by a fee market that adjusts independently of execution gas. For teams evaluating where a rollup should anchor its data, this separation is the foundational change, and everything downstream follows from it. The full specification is published as EIP-4844.
A blob is a fixed size container of 4096 field elements, each 32 bytes, giving 128 KiB of data per blob. The size is fixed, not variable: a partially filled blob occupies the same slot as a full one, which makes packing efficiency a real engineering concern rather than a micro optimization.
Blobs travel in a dedicated transaction type, 0x03, known as a blob carrying transaction. The transaction itself contains not the blob data but a versioned hash for each blob it references. The version byte is currently 0x01, which identifies the commitment scheme in use and leaves room for future schemes without changing the transaction format.
The separation matters for how data moves through the network. Blob contents propagate on the consensus layer and are made available to peers, while the execution layer sees only versioned hashes. An EVM contract can never read blob contents directly, which is a hard architectural constraint and the reason inbox contracts must be rewritten rather than adjusted.
Retention is bounded. Consensus clients keep blob data for roughly 4096 epochs, approximately 18 days, then prune it. That window defines the availability guarantee the protocol makes: anyone who needs the data has that period to download and verify it. Fraud proof and validity proof systems must be designed so that any challenge or reconstruction path resolves inside it. Teams that need longer retention run their own archival infrastructure, because the protocol makes no promise beyond the window.
Blob data is bound to the chain through KZG polynomial commitments, which allow a contract to verify claims about blob contents without the contents being present in the EVM.
A blob is interpreted as a polynomial over its 4096 field elements. The KZG scheme produces a short commitment to that polynomial, and the versioned hash carried in the transaction is derived from that commitment. The commitment is constant size regardless of blob size, which is what makes on-chain reference practical.
Verification runs through the point evaluation precompile at address 0x0A. It accepts a versioned hash, an evaluation point, a claimed value, and a proof, and confirms that the polynomial committed to under that hash really does evaluate to the claimed value at that point. A proof system can therefore challenge or confirm a specific portion of blob data on-chain without anyone submitting the blob itself. For optimistic rollups this is the mechanism that makes blob backed fraud proofs work, and for validity proof systems it provides the link between the proven state transition and the published data.
The scheme depends on a trusted setup. Ethereum ran a public ceremony with over 140,000 contributions, and the security assumption is that at least one participant behaved honestly and discarded their secret. This is a real assumption rather than a formality, and it is worth understanding before building a system whose safety rests on it.
Blob space is metered by its own fee mechanism, independent of execution gas. Blob gas is consumed by blob carrying transactions and adjusts according to blob demand alone, which is what decouples rollup data publication from unrelated L1 activity.
The adjustment follows the same style of mechanism used for execution gas: a per block target, a maximum above it, and a base fee that moves up or down depending on whether recent blocks ran above or below target. Sustained demand above target compounds the base fee upward block over block, and sustained demand below it lets the base fee decay. Blob gas is burned rather than paid to proposers.
Two properties matter for sequencer design. First, the movement is bounded per block but compounds, so a sustained demand surge produces a sharper rise than a single busy block suggests. Second, because the blob base fee and the execution base fee move independently, the relationship between them is not stable and cannot be assumed in fee estimation logic. Any component that budgets for data publication needs to read the blob base fee directly rather than deriving it from execution gas.
Capacity at activation was modest by design: the protocol shipped the blob format and commitment scheme while deferring the sampling techniques that would allow capacity to grow safely.
Those techniques arrived with PeerDAS, which lets nodes verify blob availability by sampling portions of the data rather than downloading every blob in full. That removes the constraint that previously capped capacity, since the per node bandwidth burden no longer scales linearly with total blob throughput. Details are documented on the PeerDAS roadmap page.
Alongside it came a mechanism that changes how capacity planning works: Blob Parameter Only forks, specified in EIP-7892. A BPO fork adjusts blob target, maximum, and the base fee update fraction without bundling other protocol changes, so capacity can be raised in scheduled increments rather than waiting for the next named upgrade. Two such forks have already run, taking the per block target to 14 and the maximum to 21.
The planning implication is significant. Blob capacity is no longer a fixed parameter that changes once a year. Anything in a rollup stack that hardcodes a blob limit, from batcher configuration to monitoring thresholds to capacity models, needs to treat those values as configuration rather than constants. Full danksharding remains the longer term direction, with sampling extended further, but the practical near term reality is incremental capacity increases on a known mechanism.
Adopting blob based data posting touches both on-chain and off-chain components.
On-chain, the inbox contract must accept versioned hashes rather than raw calldata and validate them against the transaction that carried them. Where proof systems previously read published data directly, they now route through the point evaluation precompile. This is a new trust boundary and belongs in audit scope, which is one reason it is worth reviewing alongside upgradeability and proxy patterns before the migration rather than after.
Off-chain, the sequencer must construct type 0x03 transactions, which changes transaction building, signing, and fee estimation. Batching logic needs rework around blob boundaries: because a blob is charged whole, compression and batch sizing should aim to fill blobs rather than to hit an arbitrary batch size. Fallback behavior deserves explicit design, with a defined policy for what happens when blob conditions make posting unattractive and a documented path back to calldata publication.
Monitoring changes too. Blob base fee, blob fill rate, and time since last successful post are the signals that indicate whether data publication is healthy, and none of them appear in standard L1 monitoring. Because blob data is pruned, any requirement to serve historical batch data beyond the retention window means running archival infrastructure.
Failure modes are blob specific and should be exercised before mainnet: a blob that fails to propagate, a fee environment that makes posting uneconomic for an extended period, and a versioned hash mismatch between what the sequencer posted and what the inbox expects. Teams working through a migration of this kind often bring in outside review at the inbox and proof boundary, and DESH Group's Web3 engineering practice covers exactly that scope.
What is EIP-4844?
EIP-4844 is the Ethereum upgrade that introduced blob transactions, a dedicated data channel that lets rollups publish batch data outside execution layer calldata, metered by an independent fee market and retained for a fixed window rather than permanently.
What is a blob?
A blob is a fixed size data container of 4096 field elements totaling 128 KiB, referenced in a transaction by a versioned hash. The EVM cannot read blob contents directly and works only with the commitment.
How long is blob data retained?
Roughly 4096 epochs, approximately 18 days, after which consensus clients prune it. Any system that needs the data beyond that window must archive it independently.
How many blobs fit in a block?
The per block target and maximum are adjustable parameters rather than fixed constants. Following the BPO forks that shipped after PeerDAS, the target stands at 14 and the maximum at 21, and further increases are expected on the same mechanism.
What must an L2 team change to adopt blobs?
Inbox contracts must handle versioned hashes, proof systems must route verification through the point evaluation precompile, sequencers must build type 0x03 transactions and pack batches to blob boundaries, and monitoring must cover blob specific signals including fill rate and blob base fee.
