EIP-4844, also known as proto-danksharding, introduces a new 'blob-carrying' transaction type that significantly reduces data availability costs for rollups. It’s a key step toward danksharding, Ethereum’s planned long-term scaling architecture.
EIP-4844 is an Ethereum Improvement Proposal that introduces a new blob-carrying transaction format that changes how rollups post data. It is the foundation that Ethereum’s future scaling architecture (danksharding) will build on.
Blobs are large binary data packets that contain compressed batches of rollup transactions.
Each blob is linked to a cryptographic commitment referenced in the transaction receipt. This allows the network to verify the blob’s existence and availability when a transaction is submitted, without the need to store the data (blob) permanently.
Blobs are automatically deleted after 4096 epochs (~18 days). This temporary availability gives honest nodes enough time to reconstruct the rollup state if necessary, while easing long-term storage demands on Ethereum.
EIP-4844 solves three key challenges:
Historically, rollups compressed, bundled, and submitted transaction data to Ethereum as calldata. Where calldata bytes are stored permanently on‑chain as part of the transaction record, even though they are only needed temporarily. This structure incurs gas and storage fees at the same rate as execution-relevant data, making rollup transactions more expensive than necessary.
Before EIP-4844, Ethereum treated all transaction data the same way, whether it’s meant for smart contract execution or simply for verification. Meaning: rollups were forced to store large amounts of transaction data using the same infrastructure and pricing model as execution logic. The lack of a separate, low-cost data availability layer created an inefficient tradeoff between scale and cost.
Rollups couldn't post large batches of verifiable data without storing them permanently, limiting how much data Ethereum could handle without long-term bloat.
EIP-4844 introduced blob-carrying transactions that could be stored on-chain temporarily, distinct from transaction receipts. This enabled rollups to post large volumes of transactions to the network at significantly lower cost than if they were posted as calldata.
The EIP creates an independent fee market for blob data with a unique gas type (blob gas). This uses the EIP-1559-style pricing mechanism to automatically adjust based on demand, allowing blob transactions to have lower, more predictable costs.
With EIP-4844, blobs are automatically pruned after an ~18-day retention period. Balancing the need for data availability with long-term storage costs. And, providing nodes enough time to verify transactions and update their state while eliminating unnecessary data (and cost) when the data is no longer needed.
EIP-4844 is an intermediate step toward long-term scalability, allowing Ethereum to test the danksharding approach before full implementation.
Before EIP-4844, both optimistic and zero-knowledge (ZK) rollups published transaction data as calldata in the execution layer.Calldata was used because it was the only mechanism to make off-chain data verifiable on-chain. To verify rollup transactions, full nodes were required to download and retain all of this data.
With EIP-4844, rollups send transaction batches as blobs (~125KB each) to be settled on-chain and later deleted.
The diagram below shows a high-level overview of how rollup transactions work:
Now, let’s explore how each rollup type handles blob-carrying transactions.
Users submit transactions to a Layer 2 (L2) network, where a sequencer (the block production manager) executes them off-chain and provides immediate confirmation.
The sequencer then aggregates multiple transactions into batches, creates blobs for each batch, and submits them to Ethereum, along with state root commitments.
These batches are accepted optimistically and assumed valid, with a 7-day challenge period where validators can dispute incorrect state transitions through fraud proofs.
Blob data is only used if there’s a dispute and a fraud proof is submitted. When a fraud proof is submitted, it verifies the state change incrementally by reading specific values from the blob through calldata.
For each accessed value, the fraud proof provides a KZG commitment and uses a point evaluation precompile (a special function that verifies a proof) to confirm that the value being read from the blob matches the earlier versioned hash before executing the fraud proof verification. Below is a visual representation.
If no challenges arise during the challenge window, the state becomes final, and users whose transactions were included in the blob can safely withdraw funds to L1. Successful disputes, however, trigger interactive fraud proofs (multiple rounds of back-and-forth proof submission between the prover and the challenger) to revert invalid states.
This process enables fast L2 transactions while preserving L1 security.
ZK rollups use the same transaction submission and batching process as optimistic rollups. The difference is that a ZK-proof engine generates cryptographic proofs that confirm all transactions in each batch are valid.
The sequencer submits each batch to the Ethereum Layer 1 as blob data and includes validity proofs. This submission generates two commitments: a KZG blob commitment that proves the data is available, and a cryptographic proof from the rollup’s internal system that guarantees transaction correctness.
The system uses a proof of equivalence check with the point evaluation precompile to show that the KZG blob commitment and the rollup’s proof system commitment refer to the same transaction data.
L1 smart contracts verify the proof instantly because the ZK proof engine has already verified all transactions. This design achieves faster finality than optimistic rollups and retains full security.
The newly introduced blob-carrying transaction structure handles blob data efficiently.
The introduced BLOB_TX_TYPE transaction type includes the following fields in the payload:
[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]
Most fields (chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, value, data, and access_list) follow the same semantics defined in EIP-1559 and maintain compatibility with existing transaction models.
However, the to field differs from standard transactions. It must always contain a 20-byte address and cannot be nil. This restriction means blob transactions cannot be used for contract creation, only to call existing contracts.
EIP-4844 also introduces blob-specific fields:
max_fee_per_blob_gas: A uint256 value that sets the maximum fee the sender is willing to pay per unit of blob gas, similar to how max_fee_per_gas works for regular gas.blob_versioned_hashes: A list of hash outputs generated by the kzg_to_versioned_hash function. These hashes serve as commitments to the actual blob data and enable verification without requiring the full blob content on-chain.A typical blob-carrying transaction is a type 3 transaction and looks like this:
tx = {
"type": 3,
"chainId": 31337,
"from": acct.address,
"to": "0x0000000000000000000000000000000000000000",
"value": 0,
"maxFeePerGas": 10**12,
"maxPriorityFeePerGas": 10**12,
"maxFeePerBlobGas": to_hex(10**12),
"nonce": w3.eth.get_transaction_count(acct.address),
}
Below is a screenshot of a recent blob-carrying transaction showing the transaction type and number of blobs.
EIP-4844’s dual pricing mechanism extends Ethereum's block header to track blob gas consumption separately from regular gas.
The block header includes two new 64-bit fields:
blob_gas_used: Total blob gas consumed by transactions in the current block.excess_blob_gas: Running total of blob gas consumed above the target from previous blocks.Fee calculation: Each blob consumes a fixed amount of blob gas, defined by GAS_PER_BLOB (131,072 gas). The total blob fee is calculated as:
blob_fee = (GAS_PER_BLOB × number_of_blobs) × base_fee_per_blob_gas
Base fee update rule: The base fee adjusts automatically based on demand, similar to EIP-1559:
base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS × e^(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)The system self-corrects based on demand:
TARGET_BLOB_GAS_PER_BLOCK, excess_blob_gas increases, driving up fees exponentially.excess_blob_gas decreases (but not below 0), reducing fees exponentially.BLOB_BASE_FEE_UPDATE_FRACTION limits fee changes to ~12.5% per block, the same rate used for base fee changes in EIP-1559 gas fees.Blob fees are deducted from the sender's balance before transaction execution and are completely burned (not paid to validators). Unlike regular gas, blob fees are non-refundable, even when a transaction fails, ensuring users always pay for data availability.
This dual market structure allows blob pricing to respond to rollup demand while maintaining the existing gas market for regular execution.
EIP-4844 reduces data availability costs for rollups by 10–100x, making trading, gaming, and decentralized finance (DeFi) interactions more affordable.
This EIP allows Ethereum to run the infrastructure required for full danksharding. It enables rollups to scale, while Ethereum gradually transitions toward full danksharding.
EIP-4844 demonstrates that Ethereum can scale through danksharding while preserving L1's security model. It significantly lowers rollup costs by providing cheaper data availability, while maintaining Ethereum L1 as the authoritative layer for rollup state commitments and data availability guarantees.
