Proto-Danksharding

What Is Proto-Danksharding?

Proto-Danksharding is an Ethereum protocol upgrade defined in EIP-4844 that introduces a new transaction type: blob-carrying transactions. These transactions attach large, temporary data payloads (called "blobs") to Ethereum blocks, giving rollups a cheaper way to post data to the base layer without competing for regular gas space.

The name combines "proto" (indicating a preliminary version) with "Danksharding," the full data sharding design proposed by Ethereum researcher Dankrad Feist. Proto-Danksharding implements the transaction format, fee market, and cryptographic verification scheme that full Danksharding will use, but without the most complex component: data availability sampling. This makes it a practical stepping stone that delivers immediate cost savings while building toward the complete scaling solution.

EIP-4844 was authored by Vitalik Buterin, Dankrad Feist, Diederik Loerakker, George Kadianakis, Matt Garnett, Mofi Taiwo, and Ansgar Dietrichs. It activated on Ethereum mainnet on March 13, 2024 as part of the Dencun (Cancun-Deneb) hard fork.

How It Works

Proto-Danksharding modifies Ethereum at three levels: it introduces a new transaction type, a separate fee market for blob data, and a cryptographic commitment scheme for verifying blobs without downloading them entirely.

Blob Transactions (Type 3)

EIP-4844 defines a new transaction type (type 0x03) that can carry up to six blobs. Each blob consists of 4,096 field elements of 32 bytes each, totaling approximately 128 KB per blob. A blob transaction looks like a regular Ethereum transaction but includes additional fields:

// Simplified blob transaction structure (Type 0x03)
{
  // Standard transaction fields
  chainId, nonce, maxPriorityFeePerGas, maxFeePerGas,
  gasLimit, to, value, data,

  // New blob-specific fields
  maxFeePerBlobGas,    // Max fee per unit of blob gas
  blobVersionedHashes, // Commitments to each blob
  blobs,               // The actual blob data (128 KB each)
  kzgCommitments,      // KZG commitments for each blob
  kzgProofs            // KZG proofs for verification
}

Blobs are not accessible to the EVM. Smart contracts can only see the blobVersionedHashes via the BLOBHASH opcode (added as part of EIP-4844). This separation keeps execution costs unchanged while creating a dedicated data channel for rollups.

Ephemeral Storage

Unlike regular transaction data (calldata), blobs are not stored permanently on Ethereum. Consensus layer clients retain blob data for approximately 18 days (4,096 epochs), after which it is pruned. This ephemeral model works because rollups only need data to be available long enough for fraud proofs or validity proofs to settle. The temporary nature of blobs is what makes them dramatically cheaper than calldata.

Blob Fee Market

Blobs have their own fee market, completely separate from Ethereum's regular gas market. Blob fees use an EIP-1559-style mechanism with a target and maximum number of blobs per block:

When blob usage is below the target, the base blob fee decreases. When above, it increases. After the Pectra upgrade (EIP-7691, activated May 7, 2025), the target doubled from 3 to 6 blobs per block and the maximum rose from 6 to 9. The fee adjustment curve also changed: prices rise approximately 8.2% when blocks are full and fall approximately 14.5% when blobs are scarce.

KZG Polynomial Commitments

At the cryptographic core of Proto-Danksharding is the KZG (Kate-Zaverucha-Goldberg) polynomial commitment scheme. Each blob is interpreted as a polynomial of degree 4,095. KZG compresses that polynomial into a single 48-byte commitment on an elliptic curve, and produces a 48-byte proof that any specific value belongs to the polynomial.

This matters for two reasons. First, it lets validators verify that blob data matches its commitment without downloading the full blob. Second, it is the same commitment scheme that full Danksharding will use for data availability sampling: validators will be able to verify the availability of large datasets by sampling random portions and checking KZG proofs against the commitments.

KZG requires a trusted setup: a one-time ceremony to generate public parameters. Ethereum ran the KZG Summoning Ceremony throughout 2023, attracting over 140,000 participants who each contributed randomness. The security guarantee is that if even a single participant honestly destroyed their contribution, the parameters are secure.

Impact on Rollup Costs

The most immediate effect of Proto-Danksharding was a dramatic reduction in Layer 2 transaction costs. Before Dencun, rollups posted data to Ethereum using calldata, which competes for gas with all other transactions. After Dencun, rollups switched to blob transactions, where data lives in a separate, cheaper lane.

The results were immediate. Within the first week after the Dencun upgrade:

• Median transaction fees on Arbitrum, Optimism, and Base dropped from $0.20 to $1.00 ranges to under $0.10
• A Uniswap swap on Base fell to approximately $0.03 (a 98% reduction from pre-Dencun costs)
• Arbitrum saw a 280% increase in daily transactions and a 310% increase in daily active users as cheaper fees attracted new activity
• Base experienced a 420% increase in daily transactions, driven by fees dropping 94% on average

This cost reduction was possible because blob data does not permanently consume Ethereum storage. Rollups pay only for temporary data availability, not permanent on-chain state.

The Path to Full Danksharding

Proto-Danksharding is explicitly an intermediate step. Full Danksharding will scale Ethereum further by introducing two key components that EIP-4844 deliberately deferred:

Data Availability Sampling (DAS)

In Proto-Danksharding, all validators must download complete blobs to verify availability. This limits how many blobs can fit in a block without overwhelming validator bandwidth. Full Danksharding introduces data availability sampling: validators randomly sample small portions of blob data and use KZG proofs to confirm the full dataset is available. This is why EIP-4844 adopted KZG commitments rather than simpler alternatives: they enable this future sampling mechanism.

The intermediate step toward DAS is PeerDAS (Peer Data Availability Sampling, EIP-7594), planned for the Fusaka upgrade. PeerDAS distributes blob custody across the validator set so that each node stores only a fraction of the total blob data, while the network collectively guarantees full availability. This will enable the blob count per block to increase significantly beyond the current maximum of 9.

Proposer-Builder Separation (PBS)

Full Danksharding assumes formal proposer-builder separation, where specialized block builders handle the computationally expensive task of assembling blocks with many blobs, while proposers only need to verify that the data is available. This architectural change allows Ethereum to support 64 or more blobs per block without requiring every validator to process all blob data.

Ethereum vs. Bitcoin: Scaling Philosophy

Proto-Danksharding reflects Ethereum's approach to scaling: modify the base layer to better serve Layer 2s. Ethereum adds new transaction types, fee markets, and cryptographic primitives at L1 to reduce costs for rollups.

Bitcoin takes a fundamentally different approach. Rather than adding data structures to the base layer, Bitcoin's scaling strategy keeps the block size constrained and pushes scaling entirely to Layer 2 protocols. The Bitcoin second-layer landscape includes the Lightning Network for payment channels, protocols like Spark for statechain-based scaling, and sidechains like Liquid: all of which operate without modifying Bitcoin's consensus rules.

This philosophical difference has practical implications. Rollups on Ethereum inherit L1 security guarantees because blob data is verified by Ethereum validators. Bitcoin Layer 2s achieve scaling through different trust models: Lightning uses bilateral payment channels, Spark uses statechains with threshold signatures, and sidechains use federated consensus. Each model makes distinct tradeoffs between decentralization, throughput, and security assumptions.

Use Cases

Proto-Danksharding primarily benefits rollup operators, but its effects cascade to all Ethereum Layer 2 users:

• Optimistic rollups (Arbitrum, Optimism, Base) post transaction batches as blobs instead of calldata, reducing their largest operational cost
• ZK-rollups post both transaction data and zero-knowledge proofs using blobs, making validity proof verification cheaper
• Layer 2 applications in DeFi, gaming, and social networks benefit from sub-cent transaction fees, enabling use cases that were uneconomical when fees were higher
• Data availability layers and alternative DA solutions benchmark against Ethereum's blob pricing, creating competitive pressure that benefits all users

Risks and Considerations

Trusted Setup Dependency

KZG commitments depend on the parameters generated in the 2023 ceremony. If the ceremony were somehow compromised (all 140,000+ participants colluding or failing to destroy their secrets), it would be possible to forge proofs. While this is considered extremely unlikely, it represents a cryptographic assumption that simpler schemes like Merkle trees do not require.

Ephemeral Data Risks

Blobs are pruned after approximately 18 days. Any system that needs historical blob data beyond this window must rely on third-party archival services. If a rollup's fraud proof window extends beyond the blob retention period, or if archival services fail, data could become unavailable when needed.

Blob Fee Volatility

The separate blob fee market can experience spikes during high demand. When many rollups compete for blob space simultaneously, blob fees can rise sharply. This has led some rollups to investigate alternative data availability layers as backup options during fee spikes.

Centralization Pressure

Even with the current modest blob counts, validator bandwidth requirements increase. As blob capacity grows toward full Danksharding, there is concern that smaller validators may struggle with the data processing demands. PeerDAS is specifically designed to mitigate this by distributing the storage burden, but the effectiveness of this approach at scale remains to be proven in production.

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.