An Ethereum Blob Commitment Is Not an Archive

A commitment is not a copy

This is retrospective coverage of EIP-4844, the Ethereum specification created on February 25, 2022. That is the EIP’s recorded creation date, not an approval date, activation date, or date for every later change. The article explains the design described in that specification; it does not report a new 2026 release. Its central distinction remains practical: a blob’s contents, a commitment to those contents, their availability to protocol participants, their accessibility to EVM execution, and their long-term retrieval are different things.

Imagine a rollup operator reviewing an old batch. The operator finds a transaction record containing a blob versioned hash, but the batch data themselves are missing from the operator’s retained records. The hash can help identify the expected commitment. It cannot be expanded into the original bytes. To reconstruct or inspect the batch, the operator needs to locate the data from a source that retained them, and then check that the supplied data match the relevant commitment. Without the data, that check cannot even be performed.

That is the difference between a commitment and an archive. A commitment is a compact cryptographic reference. An archive is a service or system that keeps content retrievable over time. One may help check the integrity of the other, but the reference alone does not perform the storage or retrieval job.

What EIP-4844 puts on each layer

EIP-4844 introduces a blob-carrying transaction format. Its abstract says the transaction contains a large amount of data that EVM execution cannot directly access, while the commitment can be accessed. The execution layer therefore has a reference it can use without treating the blob as ordinary EVM-readable transaction input. The specification describes an opcode for reading versioned hashes from a blob transaction and a point-evaluation precompile that checks a supplied proof about a committed polynomial evaluation.

The blob contents travel separately from the execution-layer transaction payload in the design. At the consensus layer, a beacon block body references blobs, while the blobs themselves are propagated in separate sidecars. The EIP assigns persistence of blobs for data availability to the consensus layer, rather than the execution layer. This split is important: seeing a transaction or block commitment through an execution interface is not the same as receiving or retaining the associated blob bytes.

The EIP also describes sidecar serving and a minimum period for sidecar requests in its original design. Those are protocol design parameters, not evidence that every node keeps every blob indefinitely, nor proof that all nodes delete data at one universal instant. They should not be read as a promise of archival service. This article does not infer a current 2026 retention window or sampling architecture from historical EIP text. Operational requirements may differ by software version, network rules, and the role a participant performs; a reader should verify current primary specifications before relying on a particular window or procedure.

What a versioned hash can and cannot do

The EIP defines a versioned hash from a KZG commitment by taking a SHA-256 digest of the commitment, dropping its first byte, and prefixing a version byte. A blob transaction carries a list of these versioned hashes. This gives the protocol and applications a compact value associated with a blob commitment, while the full content follows the separate sidecar path.

The point-evaluation precompile described in the EIP accepts a versioned hash, a point, a value, a commitment, and a proof. It checks that the commitment corresponds to the versioned hash and that the proof verifies the claimed evaluation. This supports a specific verification task. It does not turn the versioned hash into a download address, promise that any particular server will answer a request, or establish that the entire rollup batch was executed correctly. Those conclusions require additional data and checks beyond this commitment mechanism.

A useful rule is: verification needs an input. If someone supplies blob data, a commitment can be checked against them using the relevant protocol procedure. If nobody has the data, there is nothing to compare or reconstruct from the commitment alone. A commitment may reveal that two supplied datasets do not match the expected reference, but it cannot tell a missing dataset’s contents. This is the familiar one-way character of a hash-like reference, applied here as part of a structured commitment design.

Availability and archival retrieval answer different questions

Data availability asks whether the data can be obtained by the participants who need it during the protocol’s required period or process. Archival retrieval asks whether someone can still provide the data later, perhaps long after that protocol need has passed. A network’s consensus rules can specify duties and request behavior for participants. They do not automatically create a permanent archive with a service-level commitment to future users.

For the hypothetical operator, the audit has two distinct steps. First, determine what data the batch requires and locate a retained copy, perhaps from the operator’s own storage or another service whose retention policy is known. Second, use the applicable verification procedure to check that the recovered data correspond to the recorded commitment. The exact reconstruction path depends on the rollup and its tooling. EIP-4844 does not imply that every rollup has the same indexing, backup, or recovery process.

If a team needs old batches for dispute handling, accounting, reproducibility, or migration, it should treat retention as an explicit operational requirement. That means identifying who stores the bytes, for how long, how copies are monitored, what retrieval formats and identifiers are needed, and how recovered data are checked. Those are system-design choices. A blockchain commitment can make integrity checks useful, but it does not answer who is responsible for preserving the underlying material.

Blob gas is a separate accounting mechanism

EIP-4844 also describes blob gas, a fee-accounting mechanism separate from ordinary execution gas. It tracks blob data capacity under its own target and base-fee calculation. That historical specification detail helps explain why a blob transaction has fields related to blob gas and versioned hashes. It does not establish what users currently pay, how a rollup passes costs through, or whether a particular end-user transaction is cheaper. Actual fees depend on current network conditions and application behavior, and are outside the archival question addressed here.

The educational point is narrower and more durable than any fee comparison: the protocol can refer to and validate relationships involving blob data without putting all blob bytes into ordinary EVM execution. That architecture makes a clear boundary between execution and data availability. It also means that anyone who needs the contents later must plan for retrieval beyond merely recording the commitment.

The practical takeaway

When an operator sees a blob commitment, the right question is not “Can I decode the blob from this value?” The right questions are “Where are the bytes?”, “Are they available for the protocol task at hand?”, “Can I retrieve them in the form this rollup needs?”, and “Can I verify that the recovered data match the expected commitment?” Each question has a different answer and potentially a different responsible system.

EIP-4844’s design separates the blob from its commitment, makes the commitment available to execution, and describes sidecars and consensus-layer persistence for data availability. These pieces can support protocol operation and integrity checks. They do not make a commitment a permanent content archive. For long-term audits, preserve the data or arrange a dependable archival source, document the retention assumptions, and verify recovered content against the commitment when it is available. The hash is a reference point. The bytes still have to come from somewhere.