A blob crosses both Ethereum peer networks. The execution network relays the transaction and its pre-block data. The consensus network distributes the data that a beacon block commits to and keeps enough of it available for sampling and recovery.
The transaction, commitment, and blob have different identities:
- a type-3 transaction contains versioned hashes, not blob bytes;
- a KZG commitment binds one blob;
- the versioned hash is derived from that commitment;
- the execution network wrapper carries data needed before inclusion; and
- the consensus sidecar binds cells or a blob to an included beacon block.
1. Creation and execution relay
A sender creates a type-3 transaction with one or more blob versioned hashes. It also supplies the matching blobs, commitments, and proofs to the network path that accepts the transaction.
The pooled-transaction response wraps the transaction payload as:
rlp([tx_payload_body, blobs, commitments, blob_kzg_proofs])
The receiver checks equal list lengths, commitment-to-versioned-hash binding, and each blob KZG proof.
The pooled-transaction response uses wrapper_version = 1 and carries all cell
proofs for each extended blob:
rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])
There must be exactly 128 cell proofs per blob. The receiver extends each blob into cells and batch-checks every proof against the matching commitment.
Execution peers announce blob transactions before sending their large data. They do not automatically push the full wrapper to all peers. A peer requests announced transactions and applies local blob-pool policy only after the transaction and proof checks pass.
2. Payload construction
An execution client can build a payload only from valid transactions. The transaction body enters the execution payload. The blob bytes remain outside that payload.
The fork-choice and payloads page
defines the Dencun engine_getPayloadV3 call and its BlobsBundleV1. The
consensus client checks the bundle's equal-length blob, commitment, and proof
lists, with one proof per blob, before it uses the payload.
The fork-choice and payloads page
defines the Pectra engine_getPayloadV4 call. It carries BlobsBundleV1 and
execution requests; the consensus client checks equal-length blob, commitment,
and proof lists, with one proof per blob, before it uses the payload.
The fork-choice and payloads page
defines the Fusaka engine_getPayloadV5 call. It carries a BlobsBundleV2
with 128 cell proofs per blob; the consensus client checks the bundle against
the returned payload before it uses it.
The fork-choice and payloads page
defines the Glamsterdam engine_getPayloadV6 call. It carries
ExecutionPayloadV4 and a BlobsBundleV2; the consensus client applies the
same blob, commitment, and cell-proof checks before it uses the payload.
An external builder uses the same commitment relation. A bid or blinded block can hide the payload body, but it cannot change the versioned hashes, commitments, or blob data after the proposer commits to them.
3. Beacon commitment and publication
The beacon block body contains the blob commitment list. The
proposer publishes one BlobSidecar for each blob. Each sidecar carries the
blob, proof, signed block header, and commitment inclusion proof.
The beacon block body contains the commitment list. The proposer extends each
blob into 128 cells and creates 128 DataColumnSidecar objects. Each column
contains one cell and proof for every included blob, plus the commitment list,
signed block header, and inclusion proof.
The signed execution payload bid carries the commitment list. A data-column sidecar names its beacon block root and slot. Validation binds the sidecar to the bid in that block.
4. Local blob recovery
The consensus client asks the local execution client for blobs by versioned
hash through engine_getBlobsV1. The response keeps request order, carries one
proof per blob, and uses positional null for missing data. The
Engine blob access page owns the full
method contract.
engine_getBlobsV2 provides all-or-nothing retrieval, while
engine_getBlobsV3 keeps request order and uses positional null for missing
blobs. Both calls target a one-second timeout and support at least 128 hashes.
The Engine blob access page owns their
full null and error contracts. A client can use returned blobs and proofs to
build all columns, or to complete columns learned from consensus peers.
5. Gossip, sampling, and custody
Consensus gossip is the fast path. Req/Resp recovers a missed sidecar. A node accepts data only after it checks the block binding and KZG proofs.
A node samples at least eight deterministic custody groups per slot, or its full advertised custody count when that count is higher. It stores every verified column in its custody groups. A sample fails if any selected column remains missing or invalid.
When a node obtains at least half of all columns, it should reconstruct the full matrix. It then exposes reconstructed columns to the same gossip and serving paths as received columns. This cross-seeding repairs uneven distribution without weakening proof checks.
6. Import and fork choice
Blob transaction validity does not prove data availability. A consensus client must apply the fork's availability rule before it treats the block as fully available. An execution client can validate the payload while consensus still waits for sidecars or samples.
A reorganization can make a valid sidecar non-canonical. Implementations keep the sidecar's block root and do not key data only by slot. They retain enough branch data to follow fork choice, serve requests that still fall inside the required window, and attach the data to the new canonical view when roots match.
7. Retention and pruning
The transaction and commitment remain part of execution and consensus history. The large sidecar data has a shorter mandatory network window.
Blob sidecars remain required for 4,096 epochs after their creation, bounded
below by DENEB_FORK_EPOCH.
Data-column sidecars remain required for 4,096 epochs, bounded below by the data-column fork epoch. A node must retain every column in its advertised custody groups for that window. Blob-sidecar service continues only for the required transition window.
- After the window, the node may prune sidecars. Pruning does not remove the commitment or make an old block invalid.
Failure boundaries
- Reject a wrapper whose transaction hashes, blobs, commitments, and proofs do not describe the same data.
- Reject a sidecar whose block binding or KZG proof fails, even if the local execution client supplied the blob.
- Do not treat transaction relay as proof that all consensus peers can sample the data.
- Do not penalize a peer for a request outside its required and advertised serving range.
- Keep missing data distinct from invalid data. Missing data can trigger another peer request; invalid data is never merged into the local matrix.