EIP-4844 (Proto-Danksharding)

EIP-4844 introduces a new transaction type that carries blobs—large, temporary data packets. These blobs are attached to transactions but are not accessible to the Ethereum Virtual Machine (EVM). Their primary purpose is to provide cheap, temporary data availability for Layer 2 rollups like Optimism and Arbitrum, allowing them to post transaction data at a fraction of the previous cost.

• Key Innovation: Separates data availability from execution.
• Temporary Storage: Blobs are stored by consensus nodes for approximately 18 days before being pruned.

To manage network demand for blob space, EIP-4844 creates a separate fee market and gas type for blobs. Blob gas is priced independently from standard execution gas, preventing competition between rollup data posting and regular user transactions.

• Target & Limit: The protocol targets 3 blobs per block with a maximum limit of 6.
• Dynamic Pricing: Uses an EIP-1559-style mechanism where blob gas fees adjust based on demand for the dedicated blob space.

Blobs are committed to using KZG (Kate-Zaverucha-Goldberg) polynomial commitments. This cryptographic scheme allows for small, constant-sized proofs that verify the integrity and availability of the large blob data.

• Efficiency: A single, small KZG commitment in a block can represent 128 KB of data.
• Data Availability Sampling (DAS): Enables light clients and future validators to efficiently verify that blob data is available without downloading it entirely, a critical component for full Danksharding.

Blobs are integrated into Ethereum's consensus layer. Validators on the Beacon Chain construct blocks that include an execution payload (from the execution client) and a new blob sidecar. The sidecar contains the actual blob data and its KZG commitments.

• Architectural Separation: The sidecar design keeps large blob data separate from the core block body, optimizing network propagation.
• Consensus Critical: Validators must attest to the availability of blob data referenced in the block.

Blob data is not stored permanently on the Ethereum execution layer. After the blob data availability window (approximately 4096 epochs, or ~18 days), nodes can safely delete the blob data. Only the small KZG commitments remain in the blockchain history.

• Scalability Benefit: This temporary storage model is essential for scaling data capacity without imposing unbounded storage requirements on all nodes.
• Historical Access: Services like blob explorers and archival nodes may store the data longer for user accessibility.

Proto-Danksharding is a stepping stone to the full Danksharding vision. It implements core components—blob transactions, a separate fee market, and KZG commitments—in a simplified, scalable form.

• Foundation: Establishes the necessary client and network infrastructure for handling blob data.
• Next Steps: Full Danksharding will expand this system to ~64 blobs per block and enable Data Availability Sampling (DAS) across a committee of validators for exponential scalability.

EIP-4844 introduces a new transaction type that carries large data packets called blobs. These blobs are stored temporarily (for ~18 days) by consensus nodes but are not permanently accessible to the Ethereum Virtual Machine (EVM). This separation is key:

• Cost Efficiency: Blob data is priced separately from regular calldata, making it orders of magnitude cheaper for rollups.
• Temporary Storage: Nodes prune blob data after a short period, preventing indefinite state bloat while providing sufficient time for fraud/validity proofs.

Blob transactions use a fee market mechanism inspired by EIP-1559, but operate independently from the main gas market.

• Blob Gas: A new resource type with its own base fee, which adjusts per block based on network demand for blob space.
• Target & Limit: The protocol targets 3 blobs per block (0.375 MB) but can temporarily handle up to 6 blobs (0.75 MB).
• Fee Burning: The base fee for blob gas is burned, extending Ethereum's deflationary burn mechanism to this new resource.

The primary beneficiaries of Proto-Danksharding are Optimistic Rollups (like Arbitrum, Optimism) and ZK-Rollups (like zkSync, StarkNet).

• Cost Reduction: By posting transaction data as cheap blobs instead of expensive calldata, L2s can reduce fees for end-users by 10-100x.
• Throughput Enabler: Cheaper data availability is the foundation for scaling L2 transaction capacity, moving Ethereum closer to its rollup-centric roadmap.
• Interim Solution: Serves as a production-ready stepping stone to full Danksharding, which will further increase blob capacity.

Blobs are committed to using KZG polynomial commitments (also called Kate commitments). This cryptographic primitive is essential for verification:

• Efficient Proofs: Allows nodes to verify that a blob's data is available and correct with a small, constant-sized proof.
• Data Availability Sampling (DAS) Foundation: In full Danksharding, light clients will use these commitments to sample small pieces of blobs, securely confirming data is available without downloading it all.
• Trusted Setup: The protocol required a one-time KZG ceremony (the Ethereum KZG Ceremony) to generate secure public parameters.

EIP-4844 changes the requirements for running an Ethereum node, particularly in handling the new blob data.

• Consensus Clients: Must validate blob signatures, KZG commitments, and proofs.
• Execution Clients: Must process blob-carrying transactions and make blob data available to the consensus layer.
• Storage: Nodes must provision additional storage (hundreds of MBs to GBs per day) for the temporary blob data, increasing hardware requirements modestly.

Proto-Danksharding is not the final goal but a crucial prerequisite for the full Danksharding vision.

• Architecture Alignment: It introduces the core blob transaction framework and KZG commitments that full sharding will expand upon.
• Increased Capacity: Full Danksharding aims to scale blob capacity to ~16 MB per slot (64 blobs) by distributing data across a committee of validators.
• Ecosystem Preparation: Allows rollups, tooling, and infrastructure to adapt to the blob model before the larger-scale upgrade.

The core data structure introduced by EIP-4844. These are special transactions that carry large binary data objects called blobs, which are stored separately from the main Ethereum execution state for about 18 days. This separation allows data to be posted to Ethereum for Layer 2 security at a much lower cost than calldata.

• Purpose: Provide cheap, temporary data availability for rollups.
• Key Property: Blobs are not accessible to the EVM, only their commitments (KZG commitments) are, making them pure data vessels.

A critical technique for scaling blockchains where light nodes can verify data availability by randomly sampling small pieces of a block. Proto-Danksharding lays the groundwork for full Danksharding by introducing the blob format that will eventually be sharded and sampled.

• How it works: Nodes download a few random chunks of data to probabilistically guarantee the entire dataset is available.
• Goal: Enables secure block validation without downloading the full block, a prerequisite for high-throughput sharding.

Cryptographic commitments (using Kate-Zaverucha-Goldberg polynomial commitments) used to create a short proof that a blob of data exists and is available. In EIP-4844, each blob is accompanied by a KZG commitment and a KZG proof, which the consensus layer verifies.

• Function: Allows the network to trust that blob data is available and consistent without every node storing it permanently.
• Efficiency: Provides small, constant-sized proofs regardless of blob size, enabling efficient verification.

Ethereum's proof-of-stake consensus layer. EIP-4844 integrates blob-carrying transactions directly into the Beacon Chain's block structure. The consensus layer is responsible for propagating, verifying KZG commitments, and pruning blob data after its retention period.

• Role: Manages the consensus and data availability layer for blobs, separate from execution.
• Integration: This marks a key step in the Merge's vision of the Beacon Chain as the central coordinator for all Ethereum data.

The end-state scaling vision that Proto-Danksharding precedes. Full Danksharding aims to scale Ethereum's data availability to ~1.3 MB per slot per shard, with many shards operating in parallel.

• Contrast with Proto-Danksharding: While EIP-4844 introduces the blob format, full Danksharding will shard the blobs across a committee of validators and implement full Data Availability Sampling.
• Progression: Proto-Danksharding is a "MVP" that delivers ~80% of the benefits with a much simpler initial implementation.

EIP-4844 modifies Ethereum's existing fee market (EIP-1559) to create a separate one for blobs. Blob transactions have their own base fee that adjusts independently based on blob gas demand, preventing competition with regular EVM execution.

• Two Markets: Creates parallel gas markets: one for execution (EVM gas) and one for data (blob gas).
• Fee Burning: The base fee for blobs is also burned (like EIP-1559), applying deflationary pressure to ETH.