EIP-4844 Shard Blob Transactions
Final · Scaling & data · EIP status Final · created 2022-02-25
Introduces a new transaction format that places large data for rollups in a dedicated space called a "blob". Blobs have their own fee market separate from regular fees and can be deleted after a set period, so the storage burden is small.
Why it is needed
Fees on Ethereum's base layer (L1) have been high for a long time, so rollups, which batch and process transactions off-chain, have become effectively the only trustless scaling option. Optimism and Arbitrum offer fees about 3 to 8 times cheaper than L1, and ZK rollups about 40 to 100 times cheaper, but even this is expensive for many users. The fundamental solution, data sharding, adds about 16MB of dedicated data space per block, but implementing and deploying it will take considerable time. This EIP is a stepping stone until then: it introduces the transaction format that sharding will use, without doing the actual sharding. Every consensus node on the beacon chain downloads all of the data, but it can be deleted after a relatively short period. The amount is limited to a target of about 0.375MB and a cap of about 0.75MB per block. It is designed so that rollups change how they handle data only once, and the change carries over to sharding unchanged.
What changes
Today
- Rollups put data in the calldata of regular transactions and pay L1 gas fees as is
- Calldata is part of the execution payload, so nodes keep it permanently
- When L1 fees rise, rollup fees rise with them
After EIP-4844
- Rollup data goes in a dedicated space called a blob, and its price is set in a separate fee market apart from regular gas
- Consensus nodes only need to keep blobs for about 18 days, after which they can be deleted
- This creates new data space of about 0.375MB per block as a target (3 blobs) and about 0.75MB at most (6 blobs)
Who is affected
- Users: Rollups use the cheaper blob space, so fees can stay very low when usage is low.
- Rollup (L2) teams: They must upgrade once to submit data in blobs instead of calldata. Fraud proofs and proofs of equivalence use the point evaluation precompile.
- Client teams: They must implement the new transaction type (0x03), two header fields, the BLOBHASH opcode, the point evaluation precompile, blob gas validation and sidecar propagation.
- Node operators and validators: Up to about 0.75MB of additional bandwidth is added per beacon block, and consensus nodes must keep blob sidecars for about 18 days.
In depth
Blob transactions: a new transaction format of type 0x03
Adds a new EIP-2718 transaction type, BLOB_TX_TYPE (0x03). The payload body is the RLP serialization of [chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s]. The to field cannot be nil, so a blob transaction cannot create a contract. One blob is BYTES_PER_FIELD_ELEMENT (32) × FIELD_ELEMENTS_PER_BLOB (4096) bytes, and a transaction must have at least one blob. blob_versioned_hashes is a list of outputs of kzg_to_versioned_hash, and the first byte of each hash must be VERSIONED_HASH_VERSION_KZG (0x01). The signature is made over the keccak256 digest of BLOB_TX_TYPE concatenated with the RLP of the fields excluding the signature.
Blob gas: an independent EIP-1559-style fee market
Blobs are priced in "blob gas", which is separate from regular gas. One blob uses GAS_PER_BLOB (2**17) blob gas, the per-block target is TARGET_BLOB_GAS_PER_BLOCK (393216, 3 blobs), and the cap is MAX_BLOB_GAS_PER_BLOCK (786432, 6 blobs). Two 64-bit fields, blob_gas_used and excess_blob_gas, are added to the header, and the blob base fee is computed by approximating MIN_BASE_FEE_PER_BLOB_GAS × e^(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) with fake_exponential. BLOB_BASE_FEE_UPDATE_FRACTION (3338477) limits the maximum change per block to about 1.125x. The blob fee is deducted from the sender's balance and burned before execution, and it is not refunded if the transaction fails. The source explains that the fee responds the same way to the same total regardless of how usage is distributed, which makes it more stable than the existing EIP-1559.
BLOBHASH opcode
Adds a new opcode, BLOBHASH (opcode HASH_OPCODE_BYTE = 0x49). It reads index from the top of the stack as a big-endian uint256 and replaces it with tx.blob_versioned_hashes[index] if index is less than the number of blobs, or with a zero-filled bytes32 otherwise. The gas cost is HASH_OPCODE_GAS (3). The blob contents cannot be accessed from EVM execution and only this versioned hash can be read, so a contract uses this value as an anchor to verify a KZG proof submitted later.
Point evaluation precompile
Adds a KZG proof verification precompile at the address POINT_EVALUATION_PRECOMPILE_ADDRESS (0x0A). The cost is POINT_EVALUATION_PRECOMPILE_GAS (50000). The input is exactly 192 bytes in the order versioned_hash (32) | z (32) | y (32) | commitment (48) | proof (48). It first checks that kzg_to_versioned_hash(commitment) equals versioned_hash, then uses verify_kzg_proof to verify that p(z) = y for the polynomial p the commitment points to. The input field elements must be strictly less than BLS_MODULUS, and on success the precompile returns FIELD_ELEMENTS_PER_BLOB (4096) and BLS_MODULUS, each as 32 bytes big-endian, concatenated. The modulus is returned so that, even if new commitment versions such as Merkle trees and STARKs appear for quantum safety, contracts can use the new format without an upgrade.
Consensus layer: sidecars and 18-day retention
Blobs are not included whole in the beacon block body. They are propagated separately as "sidecars", and the block only references them. The design treats the is_data_available() check as a black box, so when full sharding replaces it with data availability sampling (DAS), beacon nodes will no longer need to download every blob in full. Blob retention is the consensus layer's responsibility, not the execution layer's. Sidecars must be kept for MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS (4096 epochs, about 18 days), which is much shorter than the one-year rotation proposed (not yet implemented) for execution payload history. Bandwidth grows by up to about 0.75MB per beacon block. Compared with today's theoretical maximum block size (30M gas ÷ 16 gas per calldata byte = 1.875MB), the source judges that the worst case does not greatly increase bandwidth, and that since block time is fixed after the Merge, large blocks are guaranteed time to propagate.
Networking: two representations and mempool DoS defense
Blob transactions have two network representations. In mempool propagation (PooledTransactions), the payload is wrapped as rlp([tx_payload_body, blobs, commitments, proofs]) so blobs, commitments and proofs are sent together. The receiving node must verify that blob_versioned_hashes, blobs, commitments and proofs all have the same length, that kzg_to_versioned_hash(commitments[i]) matches the corresponding versioned hash, and that the commitments match the blobs and proofs (this can be batch-verified with verify_blob_kzg_proof_batch). In block body responses (BlockBodies), only the standard payload is used. Because the data is large and poses a mempool DoS risk, nodes must not rebroadcast blob transactions automatically. They announce them with NewPooledTransactionHashes and send them only when a GetPooledTransactions request arrives. For transaction replacement rules, the EIP recommends requiring a 1.1x increase in the blob gas base fee, and EIP-5793 adds the type and size to announcements to give finer control.
The design toward full sharding and how rollups use it
This EIP introduces in advance the same transaction format that full sharding will use, so rollups only need to change how they handle data once. What is already done: the new transaction type, all of the execution layer logic needed for full sharding, all of the cross-verification logic between execution and consensus, the layer separation of BeaconBlock verification and sampling, and the self-adjusting blob base fee. What remains: low-degree extension of the commitments for two-dimensional sampling, the implementation of data availability sampling, PBS (proposer-builder separation), per-validator proof of custody, and more. It also describes how rollups can use it. Optimistic rollups load a few blob values through calldata only for a fraud proof and verify them with a KZG proof and the point evaluation precompile, while ZK rollups use a proof of equivalence showing that the blob commitment and the commitment of their own proof system point to the same data. This EIP has its specification finalized with Final status.