Danksharding

The core mechanism enabling secure scaling. Validators download only small, random samples of the large data block, allowing them to probabilistically verify its availability without downloading it entirely. This enables blocks to be orders of magnitude larger while keeping node hardware requirements low.

• Key Innovation: Breaks the linear relationship between block size and node workload.
• Security Guarantee: With enough samples, validators can detect data withholding attacks with near-certainty.

A prerequisite architectural separation where block builders (specialized entities) construct full blocks, and block proposers (validators) simply choose the most profitable header. This is critical for Danksharding's security model.

• Builder Role: Competes to create the most valuable block, including ordering transactions and committing to a large data blob.
• Proposer Role: Selects the header with the highest bid, without needing to process the full block data.

The new transaction type that carries large data 'blobs' (e.g., for Layer 2 rollups). These blobs are stored separately from the main execution payload and are subject to different gas pricing and retention rules.

• Purpose: Dedicated, low-cost data space for rollup proofs and calldata.
• Ephemeral Storage: Blobs are pruned after ~18 days, as their primary purpose is short-term data availability for Layer 2 state verification.

Separates the pricing of execution (computation) from data availability (blob space). This prevents congestion in one resource from spilling over and inflating costs for the other.

• Execution Gas: Pays for EVM computation and storage, as in Ethereum today.
• Blob Gas: A new fee market specifically for the data blobs in blob-carrying transactions, with its own base fee and priority fee.

Uses KZG polynomial commitments (or potentially other schemes) to create a compact cryptographic proof that a large data blob is available and consistent. This allows the data to be verified as 'available' once the commitment is posted, enabling efficient sampling.

• Function: Creates a short 'fingerprint' (commitment) of the entire data blob.
• Sampling Foundation: Validators use this commitment to verify their random data samples are correct.

Danksharding is the full realization of a multi-phase roadmap. Proto-Danksharding (EIP-4844) was the first major step, introducing the core architecture—blob-carrying transactions and a separate fee market—without yet implementing data availability sampling.

• Phase 1 (EIP-4844): Lay the groundwork with blobs and a new transaction type.
• Full Danksharding: Later phases will increase blob count and implement DAS, enabling the full scaling vision.

The core innovation enabling full Danksharding. Light nodes and validators can probabilistically verify that all data in a large block is available by sampling small, random pieces. This allows the network to safely scale block size to ~16 MB per slot (or more) because no single participant needs to download the entire block to trust its contents.

The final stage, building upon Proto-Danksharding and DAS. It fully implements the Danksharding design, characterized by:

• Massive Data Capacity: Target of 16 MB per slot per blob, with potential for 64 blobs, enabling ~1 GB of data per slot.
• Decoupled Validation & Builder Roles: The Proposer-Builder Separation (PBS) model is essential, separating the entity that proposes a block from the one that builds it, ensuring efficient block construction.
• Universal Scalability: Aims to provide abundant, cheap data availability for all Layer 2 rollups.

Danksharding changes the responsibilities of Ethereum's client software. The consensus client (e.g., Prysm, Lighthouse) becomes responsible for propagating and validating blob data and KZG commitments. The execution client (e.g., Geth, Nethermind) only receives a small reference to the blob data, keeping its resource requirements manageable. This separation is key to maintaining node decentralization.

The primary beneficiary of Danksharding is the Layer 2 rollup ecosystem. By providing orders of magnitude more dedicated data bandwidth at lower cost, it directly reduces the largest cost component for optimistic and ZK rollups. This translates to significantly lower transaction fees for end-users and enables new high-throughput decentralized applications (dApps) that were previously cost-prohibitive on Ethereum.

By separating data (blobs) from execution, Danksharding decouples the cost of data availability from the cost of EVM computation. This makes posting transaction data from Optimistic Rollups and ZK-Rollups orders of magnitude cheaper.

• Direct Impact: Significantly lowers the fixed cost for Layer 2 sequencers, enabling cheaper transaction fees for end-users.
• Economic Shift: Transforms Ethereum's primary scaling model to a rollup-centric roadmap, where execution happens off-chain and settlement/data availability happen on-chain.

Danksharding is built on a proposer-builder separation (PBS) model, where block builders (specialized actors) assemble complex blocks with blobs, and block proposers (validators) simply choose the most profitable one. This simplifies the validator role and prevents centralization pressures.

• Validator Role: Validators no longer need powerful hardware to construct data-heavy blocks; they only propose and attest.
• crList Mechanism: Ensures censorship resistance by allowing proposers to force inclusion of certain transactions.

The cheap, abundant data provided by Danksharding is the critical input for ZK-proof verification. High-performance ZK-Rollups can post massive batches of proven transactions as compact blob data, making Ethereum a ultra-efficient settlement layer.

• Synergy with ZK Tech: Blobs are the perfect vehicle for calldata in ZK-proof systems, enabling scalable, private applications.
• Future-Proofing: Lays the groundwork for advanced applications like fully on-chain games and complex DeFi primitives that require cheap state diffs.

Danksharding is implemented in phases, starting with Proto-Danksharding (EIP-4844). This introduced the core blob transaction type and a separate fee market for data, delivering ~80% of the benefits without requiring full DAS or increased block sizes.

• Incremental Upgrade: EIP-4844 established the architectural framework and immediate fee reductions.
• Foundation for Full Danksharding: The blob market and transaction format are now live, allowing the network to later upgrade to full data sampling and larger blobs seamlessly.

By specializing as a secure settlement and data availability layer, Danksharding reinforces Ethereum's position as the base layer for a multi-chain ecosystem. It enhances security and decentralization while enabling scalable user experiences.

• Security Inheritance: Rollups leveraging Ethereum's data availability inherit its strong security guarantees.
• Ecosystem Cohesion: Prevents fragmentation by keeping critical data on Ethereum, ensuring composability and a unified liquidity layer.

The core security mechanism where light clients and validators randomly sample small, redundant pieces of blob data to probabilistically verify its availability without downloading the entire dataset. This prevents data withholding attacks by ensuring that if any data is missing, a sample will fail with high probability.

• Enables secure scaling by allowing nodes to trust the network, not just a single block producer.
• Relies on erasure coding to guarantee data can be reconstructed even if some samples are unavailable.

Danksharding integrates a single, auction-based block builder role for the entire sharded data layer, separating it from the block proposer. This design mitigates centralization risks and MEV (Maximal Extractable Value) exploitation by creating a competitive market for block construction.

• The proposer (validator) selects the highest-value block from builders.
• The builder assembles transactions and blob data, committing to make it available.
• This separation is enforced cryptoeconomically, reducing the power of any single entity.

Rollup data is posted as large data blobs that are separate from main execution block data. These blobs are ephemeral, with a fixed expiry period (e.g., 18 days in EIP-4844/proto-danksharding). This creates a clear security and cost model:

• Security: Data must be available long enough for fraud or validity proofs to be challenged.
• Cost: Expiry reduces the perpetual storage burden on consensus nodes, lowering fees.
• After expiry, data availability responsibility shifts entirely to rollups and third-party services.

The system is secured by slashing conditions and attestation penalties that target data availability failures. Validators are required to attest to the availability of blob data.

• A builder who withholds data or publishes an invalid blob can be slashed.
• Validators who incorrectly attest to data availability face inactivity penalties.
• This creates strong economic disincentives against malicious behavior, aligning security with Ethereum's existing proof-of-stake model.

Danksharding's use of KZG polynomial commitments for blob verification requires a one-time trusted setup ceremony. This cryptographic primitive allows for efficient proof of correct erasure coding.

• Security Assumption: The ceremony must be performed honestly by a decentralized set of participants to generate secure parameters.
• If compromised, an attacker could create fake proofs for unavailable data, breaking the sampling security.
• The Ethereum community conducted the KZG Ceremony (EIP-4844) to mitigate this risk.

Danksharding differs from earlier execution sharding plans, focusing security efforts on a single, robust data layer rather than multiple execution environments.

• Legacy Sharding: Multiple chains with separate proposers and consensus, complex cross-shard communication.
• Danksharding: Single data availability layer for all rollups, simpler security model.
• This consolidation reduces consensus overhead and attack surface, making the security properties easier to analyze and enforce for the primary goal of scaling data availability.