EIP-4844

EIP-4844, known as Proto-Danksharding or ‘Shard Blob Transactions’, is an Ethereum Improvement Proposal activated on the Ethereum mainnet in March 2024 that introduces a new transaction type carrying temporary binary large objects (blobs) of data. Each blob is approximately 128 KB, persists for a short window (roughly two weeks) rather than being stored permanently in Ethereum state, and is made accessible to smart contracts only via a cryptographic commitment. The proposal dramatically reduces the data posting costs for Layer-2 rollups by creating a dedicated, cheap data-availability lane, providing a foundation for full Danksharding without requiring immediate shard implementation.

Overview

• EIP-4844 was authored by Vitalik Buterin, Dankrad Feist, Diederik Loerakker, George Kadianakis, Matt Garnett, Mofi Taiwo, and Ansgar Dietrichs. It reached finality in the Ethereum Cancun–Deneb upgrade (also called Dencun), activated on 13 March 2024.
• The central motivation is the cost bottleneck faced by rollup operators who must post transaction data back to Ethereum as proof of validity or fraud. Prior to EIP-4844, this data was submitted via Calldata, which persists indefinitely in Ethereum’s history and is priced by the general-purpose Gas Fee Mechanism.
• EIP-4844 creates a separate blob-carrying transaction format (type 0x03). Blobs are kept by Beacon Chain consensus nodes for a pruning window (approximately 18 days), after which they are discarded. This temporary availability is sufficient for rollup fraud-proof and validity-proof windows while avoiding long-term storage bloat.
• The Beacon Chain gossips and stores blobs independently from the execution layer, preserving execution-layer simplicity.
• A blob-specific fee market, modelled on EIP-1559’s EIP-1559 base fee adjustment, governs blob pricing: if the number of blobs per block exceeds a target, the blob base fee rises exponentially, and vice versa.

Key Mechanisms

• Blob Transactions (Type 0x03)
  • A new Ethereum transaction type carrying up to six blobs per transaction (with an initial target of three per block and a maximum of six).
  • Blob data is NOT available to the Ethereum Virtual Machine (EVM) directly; only a KZG Commitment to the blob is accessible on-chain via a precompile (BLOBHASH opcode).
  • This prevents execution-layer storage inflation while still allowing rollup contracts to verify that posted commitments match blob contents.
• KZG Polynomial Commitments
  • EIP-4844 relies on KZG Commitment (Kate–Zaverucha–Goldberg) schemes over the BLS12-381 Elliptic Curve Cryptography pairing. These are a form of Polynomial Commitment that allows succinct proofs of evaluation.
  • The trusted setup for the BLS12-381 KZG scheme used by EIP-4844 was generated during the Ethereum KZG Ceremony (Powers of Tau), a multi-party computation that required a single honest participant to ensure soundness.
• Blob Fee Market
  • Blob gas is priced separately from execution gas using an independent EIP-1559-style mechanism.
  • The excess_blob_gas field in block headers tracks cumulative blob demand; blob_base_fee adjusts accordingly.
  • Rollup operators pay blob_base_fee × blob_gas_used on top of the normal execution transaction fee.
• Beacon Chain Blob Propagation
  • Blobs are broadcast and stored by Beacon Chain nodes on the consensus layer, separate from the execution-layer block body.
  • This separation means blob availability is enforced by the Proof of Stake consensus network without burdening execution clients.
• BLOBHASH Opcode
  • A new EVM opcode (BLOBHASH, opcode 0x49) allows smart contracts to read the versioned hash of each blob commitment, enabling rollup contracts to verify that the rollup operator committed to specific blob data.
• Data Availability vs Permanent Storage
  • Blobs are available for the pruning window only. For long-term archival, rollup operators and third parties rely on Decentralised Storage networks (e.g., IPFS, Celestia, EigenDA) or node-level archival.
  • This is a deliberate design choice: Data Availability (not permanent storage) is what rollups need within their challenge/proof window.

Applications and Use Cases

• Layer-2 Rollup Cost Reduction
  • Optimistic Rollup protocols (Optimism, Arbitrum) and ZK Rollup protocols (zkSync Era, Starknet, Polygon zkEVM, Scroll) all adopted blob posting after Dencun, substantially reducing per-transaction fees for end users.
• Data Availability for Modular Blockchains
  • EIP-4844 positions Ethereum as a Data Availability layer for modular blockchain stacks, enabling rollups to use Ethereum for DA while executing independently.
• Foundation for Full Danksharding
  • Proto-danksharding deliberately mirrors Danksharding’s data model (blob commitments, KZG, beacon-layer storage). Full Danksharding will add Data Availability Sampling (DAS), sharding blob committees, and dramatically increase blob throughput, but the cryptographic plumbing is already in place.
• Decentralised Application Cost Improvements
  • End-user transaction fees on L2 networks built on Ethereum dropped materially after Dencun, broadening access to decentralised finance (DeFi) and NFT applications.
• Cross-Rollup Interoperability Research
  • Cheaper data availability on Ethereum encourages rollup proliferation, making Cross-Chain Communication and shared sequencing a more pressing research area.

Standards & Context

• EIP-4844 is an Ethereum Improvement Proposal governed by the Ethereum Magicians forum and the AllCoreDevs process, which coordinates client teams (Geth, Nethermind, Besu, Erigon, Reth on the execution side; Prysm, Lighthouse, Teku, Nimbus, Lodestar on the consensus side).
• It was formally specified in the Ethereum Execution Layer Specification and the consensus-layer beacon-chain spec, both maintained by the Ethereum Foundation.
• The KZG trusted setup involved over 140,000 participants in the Ethereum KZG Powers of Tau ceremony, one of the largest multi-party computation ceremonies in public blockchain history.
• EIP-4844 supersedes earlier data-availability proposals such as EIP-4488 (calldata cost reduction) and EIP-4490, which were considered simpler but less aligned with the long-term Danksharding roadmap.
• Blob data format and the versioned hash scheme (0x01 || KZG_commitment_hash) are defined in the EIP-4844 specification document available at eips.ethereum.org.
• The Ethereum Virtual Machine (EVM) is extended with the BLOBHASH opcode and a point_evaluation precompile (address 0x0A) to support KZG proof verification on-chain.
• Related Ethereum standards: EIP-1559 (fee market), EIP-3675 (Proof of Stake transition), EIP-4895 (withdrawals), forming the broader post-Merge upgrade series.

Semantic Classification

Provenance