Full Danksharding

What Is Full Danksharding?

Full danksharding is Ethereum's planned data availability scaling upgrade, named after Ethereum researcher Dankrad Feist who proposed it in late 2021. Rather than splitting the network into parallel execution chains (the original sharding design), danksharding takes a different approach: it massively expands the amount of blob data that each block can carry, making Ethereum a powerful data availability layer for rollups and other Layer 2 systems.

The first step toward this goal shipped in March 2024 with proto-danksharding (EIP-4844), which introduced the blob transaction format and a separate blob fee market. Proto-danksharding intentionally deferred several consensus-layer components: data availability sampling, 2D erasure coding, and proposer-builder separation. Full danksharding completes this vision by adding those missing pieces.

Full danksharding sits within Ethereum's "Surge" roadmap phase and represents the endpoint of the protocol's data scaling strategy. Its core insight is that Ethereum does not need to execute more transactions on L1: it needs to provide more space for rollups to post their data cheaply and verifiably.

How It Works

Full danksharding combines three cryptographic building blocks to scale blob capacity without requiring every validator to download all the data.

KZG Commitments

Each blob is committed to using a KZG (Kate-Zaverucha-Goldberg) polynomial commitment scheme. A blob of 4,096 field elements is treated as the evaluation of a polynomial, and the KZG commitment reduces it to a single, constant-size cryptographic proof. This allows anyone to verify that a small sample of a blob is consistent with the full dataset without downloading the entire blob.

KZG commitments are homomorphic: commitments and proofs can be linearly combined, which is critical for extending samples across the 2D erasure coding grid. The tradeoff is that KZG requires a trusted setup ceremony. Ethereum's KZG ceremony received over 140,000 contributions, making it the largest of its kind.

2D Erasure Coding

The blob data is arranged into a matrix (256 rows by 4,096 columns in the full design) and then extended using 2D Reed-Solomon erasure coding. This expands the matrix to 512 rows by 8,192 columns, quadrupling the total data. The key property: the original data can be reconstructed from any 50% of the elements in any given row or column, meaning an attacker must hide at least 25% of the entire expanded matrix to successfully withhold data.

Reconstruction uses a greedy algorithm that iteratively recovers incomplete rows and columns. When a row or column has at least 50% of its elements available, univariate polynomial interpolation fills in the missing pieces. Recovered elements then help complete other rows and columns, cascading until the full matrix is restored.

Data Availability Sampling (DAS)

Data availability sampling is what makes the scaling leap possible. Instead of every validator downloading every blob, each validator randomly samples a small number of cells from the erasure-coded matrix and verifies them against the KZG commitments.

The probability that a validator falsely accepts unavailable data drops exponentially with each additional sample. With Q random queries, the false acceptance probability is approximately (3/4)^Q. Across the network of roughly 10,000 sampling nodes, the probability of deceiving even 200 nodes simultaneously approaches 10^-20, making data withholding practically impossible.

Peer-to-Peer Distribution (PeerDAS)

EIP-7594 (PeerDAS) defines the networking layer that distributes blob data across the validator set. Data is organized into 128 column subnets. Regular full nodes subscribe to only 4 of these 128 subnets, reducing bandwidth requirements by roughly 8x compared to downloading all data.

Nodes are deterministically assigned custody of specific columns. When a node acquires 50% or more of a row or column, it can reconstruct the missing pieces via erasure decoding and then share them with peers on other subnets. This self-healing property ensures data remains available even when individual nodes go offline. PeerDAS shipped in Ethereum's Fusaka hard fork in December 2025, establishing the foundation for full danksharding.

Proto-Danksharding vs Full Danksharding

Understanding the differences between the two stages clarifies what full danksharding actually adds:

Blob data is not accessible to the EVM in either version. Both use KZG commitments. The fundamental shift in full danksharding is that DAS removes the requirement for every node to download every blob, which is what makes the 40x capacity increase feasible without raising hardware requirements.

Use Cases

Full danksharding is built specifically to serve the rollup-centric scaling roadmap. Its primary use cases center on making Layer 2 data posting radically cheaper.

• Rollup data posting: optimistic rollups and ZK-rollups compress user transactions and post them to Ethereum L1 as blobs for data availability. Full danksharding makes this 40-100x cheaper than current levels by massively expanding blob space.
• High-throughput applications: with an estimated 1.3 MB/s of data throughput, the L2 ecosystem can collectively support 100,000+ transactions per second, enabling use cases like real-time payments, gaming, and social applications that need low-cost data availability.
• Cross-chain data: modular blockchain architectures that separate execution from data availability can use Ethereum as a shared data availability layer, benefiting from its validator set and economic security.

For a deeper analysis of how blob economics affect rollup costs, see the research article on EIP-4844 blob fee markets and the comparison of L2 rollup fee dynamics.

Why It Matters

Ethereum's base layer processes around 15 transactions per second. To serve billions of users, the network needs orders-of-magnitude more throughput. Full danksharding addresses this not by making L1 faster, but by making it a more efficient data anchor for Layer 2 networks that handle execution.

The early results from PeerDAS (which shipped in Fusaka) demonstrate the scaling trajectory: L2 transaction costs fell 40-60% immediately, and networks like Arbitrum, Optimism, and Base began processing 3.5x more transaction data. Full danksharding extends this by another order of magnitude.

For Bitcoin Layer 2 networks like Spark, Ethereum's approach to data availability scaling offers a useful comparison point. While Bitcoin L2s like Spark use different mechanisms (statechains, cooperative signing), the underlying challenge of scaling data availability without overburdening validators is a shared concern across blockchain ecosystems.

Risks and Considerations

Timeline Uncertainty

Full danksharding remains several years away. The Ethereum Foundation's roadmap places it in the 2028-2030 timeframe. Key prerequisites include enshrined proposer-builder separation (ePBS, targeting the Glamsterdam upgrade in late 2026), full 2D DAS implementation, and proof of custody mechanisms. Each component requires extensive research, implementation, and testing.

Trusted Setup Dependency

KZG commitments require a trusted setup ceremony. While Ethereum's ceremony had over 140,000 participants (only one needs to be honest for security), the dependency on a one-time ceremony is a philosophical concern for some in the community. Post-quantum alternatives like STARKs avoid trusted setups but produce larger proofs.

Network Bandwidth Requirements

Even with DAS reducing per-node download requirements, the aggregate network bandwidth needed to distribute 16-32 MB of blob data every 12 seconds is substantial. Block builders must handle the full data load, which centralizes the builder role. Enshrined PBS is designed to manage this centralization by separating the builder role from validators.

Data Retention and Long-Term Storage

Blob data is pruned after approximately 18 days (4,096 epochs). Full danksharding does not change this: it provides temporary data availability, not permanent storage. Rollups and applications that need long-term data access must rely on external solutions such as archival nodes, the Portal Network, or decentralized storage protocols.

Complexity and Attack Surface

The combination of 2D erasure coding, KZG polynomial commitments, DAS sampling logic, and a new peer-to-peer distribution layer introduces significant protocol complexity. Each component must be implemented correctly across multiple client teams. Bugs in erasure coding or commitment verification could compromise data availability guarantees that rollups depend on for security.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.