Blob-Carrying Transaction

Overview

A blob-carrying transaction, introduced by EIP-4844, includes versioned hashes that commit to one or more large data blobs. The blobs travel with cryptographic commitments and proofs, while the execution-layer transaction body records references needed for validation and fee accounting. EVM contracts cannot read the blob contents directly, although they can access the corresponding commitment hashes. The data is retained for a limited protocol period, giving rollups enough time to reconstruct and verify their state without permanently storing every byte in Ethereum execution history.

Rollup infrastructure must publish complete sidecars, pay blob gas, and confirm canonical inclusion. Indexers should associate blobs, commitments, and the transaction hash correctly. A successful transaction envelope without retrievable blob data can create serious availability and recovery problems. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. Status labels should describe what is known without overstating settlement. Blob-Carrying Transaction should be represented as a sequence of observable states rather than one success flag. Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages.

Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available. Systems need idempotent processing keyed to stable transaction and business identifiers.

Settlement consideration: Blob-carrying transactions publish temporary rollup data with verifiable commitments while keeping that data outside permanent EVM storage.