EIP-4844 Blob Transactions — How They Actually Work

# EIP-4844 Blob Transactions — How They Actually Work

EIP-4844, also known as "Proto-Danksharding", changed the economics of Layer 2 rollups overnight. Before blobs, rollups posted transaction data to Ethereum as expensive calldata. After blobs, they post to cheap temporary storage that gets pruned after 18 days.

This is how it works under the hood.

The Problem Blobs Solve

Rollups like Arbitrum and Optimism batch thousands of transactions off-chain, then post compressed data to Ethereum for verifiability. Until EIP-4844, this data was stored as calldata — permanent, replicated across all nodes, and priced accordingly.

For a 100 KB rollup batch:

• Calldata cost: ~16 gas per byte → 1.6M gas → $50-150 depending on gas price

• Blob cost: flat fee per blob → ~$0.50-5 per blob

That is a 100x reduction in data availability costs.

What is a Blob?

A blob is 4096 field elements, each 32 bytes, in the BLS12-381 scalar field. That is roughly 128 KB of data per blob.

Blobs are attached to transactions, but they are NOT part of the EVM execution environment. You cannot access blob data directly from a smart contract. Instead, rollups use blobs to store compressed transaction data off-chain, with only a cryptographic commitment posted on-chain.

KZG Commitments

Each blob has a KZG commitment — a short cryptographic proof that binds the blob data to a hash. The commitment is stored on-chain, but the blob data itself is only kept by consensus nodes for 18 days, then pruned.

This is perfect for rollups: the data is available long enough for fraud proofs or validity proofs, but does not bloat Ethereum state forever.

Blob Transactions (Type 3)

EIP-4844 introduces a new transaction type:

// Type 3 transaction structure
{
  chainId,
  nonce,
  maxPriorityFeePerGas,
  maxFeePerGas,
  gasLimit,
  to,
  value,
  data,
  accessList,
  maxFeePerBlobGas,      // NEW
  blobVersionedHashes,   // NEW
  blobs,                 // NOT included in transaction hash
  commitments,           // KZG commitments
  proofs                 // KZG proofs
}

The blobVersionedHashes field contains the hashes of the KZG commitments. The actual blobs are transmitted separately and validated by consensus nodes.

How Rollups Use Blobs

Here is the flow for Optimism posting a batch:

Optimism sequences 10,000 transactions off-chain

Compresses them into a single blob (~100 KB)

Generates a KZG commitment for the blob

Sends a type 3 transaction with:

- to: Optimism's batch inbox contract

- blobVersionedHashes: the commitment hash

- blobs: the actual compressed data

Ethereum consensus validates the KZG proof

The batch inbox contract records the commitment on-chain

Blob data is available for 18 days for fraud proofs

Arbitrum follows a similar pattern with its SequencerInbox contract.

Cost Savings Math

Let's compare costs for a 100 KB rollup batch:

Before EIP-4844 (calldata)

Cost = 100,000 bytes × 16 gas/byte = 1,600,000 gas
At 30 gwei: 0.048 ETH
At $3000/ETH: $144

After EIP-4844 (blobs)

Cost = 1 blob × ~0.01 ETH (blob base fee)
At $3000/ETH: ~$30

That is a 5x reduction at moderate blob demand. When blob demand is low, the cost can drop to under $1 per blob.

Blob Lifecycle

Blobs are temporary. After 18 days (~4096 epochs), consensus nodes are no longer required to keep blob data. This keeps disk usage bounded.

For rollups, this is fine: fraud proof windows are typically 7 days. Validity rollups (ZK rollups) verify proofs immediately, so they do not need blobs to persist at all.

Solidity Access to Blobs

Smart contracts cannot read blob data directly, but they can access blob metadata via two new opcodes:

BLOBHASH

Returns the versioned hash of a blob attached to the current transaction:

function getBlobHash(uint256 index) internal view returns (bytes32) {
    bytes32 hash;
    assembly {
        hash := blobhash(index)
    }
    return hash;
}

This lets a contract verify that a blob was included in the transaction.

BLOBBASEFEE

Returns the current blob gas base fee:

function getCurrentBlobBaseFee() internal view returns (uint256) {
    uint256 fee;
    assembly {
        fee := blobbasefee()
    }
    return fee;
}

Blob base fee adjusts dynamically based on demand, similar to EIP-1559 for gas.

Blob Pricing

Blob gas pricing is separate from execution gas. Each block targets 3 blobs, with a max of 6 blobs.

The base fee adjusts using an EIP-1559-style formula:

• If a block has more than 3 blobs, base fee increases by 12.5%

• If a block has fewer than 3 blobs, base fee decreases by 12.5%

This keeps blob usage predictable and prevents spam.

Practical Considerations

For Rollup Developers

• Each transaction can attach up to 6 blobs (~768 KB)

• Blob data is only accessible during transaction validation

• Blob fees are paid separately from execution gas

• Archive nodes may keep blobs longer than 18 days (optional)

For Smart Contract Developers

• You cannot read blob data from a contract

• You CAN verify blob commitments via BLOBHASH

• Blob fees do not affect smart contract execution costs

For Users

• Blob transactions reduce rollup fees by 10-100x

• Lower fees mean more users can afford on-chain activity

• Blobs are already live on Ethereum mainnet since March 2024

Summary

EIP-4844 blobs are temporary data storage optimized for rollups. They provide the data availability rollups need for security, without the cost or bloat of permanent calldata.

Key takeaways:

• Blobs are 128 KB chunks with KZG commitments

• Rollups post compressed transaction data to blobs

• Blobs are pruned after 18 days

• Cost savings: 10-100x vs calldata

• Solidity can access blob hashes via BLOBHASH and BLOBBASEFEE

If you are building on a rollup, you are already benefiting from blobs. If you are building a rollup, blobs are a game changer.