Full Danksharding Block Structure at a Glance

Data Availability Sampling (DAS) is the core scaling mechanism. Validators verify data availability by sampling small, random chunks, enabling the network to securely scale data capacity beyond any single node's download limit.

Blob-Carrying Transactions introduce a new transaction type. Execution clients process only a small commitment to large data 'blobs', which are stored separately by consensus clients, decoupling execution cost from data storage cost.

KZG Commitments provide the cryptographic proof system. These polynomial commitments create succinct proofs that the blob data is available and correct, enabling efficient verification for protocols like EigenDA and Celestia.

Proto-Danksharding (EIP-4844) is the production precursor. It implements the blob transaction framework and fee market, providing immediate scaling relief for L2s like Arbitrum and Optimism while the full Danksharding infrastructure is built.

Blobs are the new data primitive. A full Danksharding block contains ~128 data blobs (16 MB each) alongside the standard execution payload. These blobs are cheap, ephemeral data packets for rollups like Arbitrum and Optimism, purged after ~18 days.

Builders compete for blob space. Proposer-Builder Separation (PBS) forces specialized block builders like Flashbots SUAVE to bid for the right to include blobs. This creates a fee market separate from gas, optimizing for data throughput.

Validators sample, not download. The Data Availability Sampling (DAS) protocol requires validators to randomly sample small chunks of each blob. This statistical guarantee proves data availability without any single node storing the full ~2 GB block.

Evidence: EIP-4844 is the prototype. The proto-danksharding upgrade introduced blobs with a 0.375 MB target, creating a ~90% cost reduction for L2 transaction data. Full Danksharding scales this model by 64x.

Data Availability Sampling (DAS) is the core innovation. It allows nodes to verify data availability without downloading entire blocks, a technique pioneered by Celestia. This separates data publication from execution, creating a distinct data availability layer within Ethereum.

Blobs are not execution payloads. They are large, cheap data packets attached to blocks, analogous to Celestia's data squares. The execution layer (e.g., Optimism, Arbitrum) only processes commitments, while blob data is verified separately by the consensus layer.

This creates a modular architecture on a monolithic chain. Ethereum L2s become execution-only clients, relying on Ethereum's consensus for data and security. This is the Celestia model, but with the security of Ethereum's validator set instead of a separate data availability committee.

Evidence: Post-Dencun, average blob count per block is ~3, with capacity for 6. This is a scalable data marketplace where L2s like Base and zkSync compete for blob space, directly mirroring rollup economics on Celestia.