EIP-4844 Proto-Danksharding Explained
Understand blob transactions, ephemeral data, KZG commitments, and how EIP-4844 reduced L2 fees by 95% in the Dencun upgrade (March 2024). Learn the path toward full Danksharding and future Ethereum scaling.
What is EIP-4844?
EIP-4844 (Ethereum Improvement Proposal 4844), activated March 13, 2024, introduced Proto-Danksharding to Ethereum. It adds a new transaction type (Type-3) that carries temporary data blobs (128KB each) separate from standard calldata. Blobs are stored by the consensus layer for ~18 days, then pruned. This creates a cheaper data layer for L2 rollups, reducing fees by 86-95% while maintaining Ethereum security.
This is one of those topics where surface-level understanding is dangerous. We've seen traders lose significant capital from misconceptions covered in this guide.
Proto-Danksharding is named after Protolambda and Dankrad Feist, core researchers who designed the mechanism. It's a stepping stone toward full Danksharding (planned 2027+), which will scale data throughput to 16MB per block via 64+ shards. For now, EIP-4844 provides immediate relief for L2 users while maintaining consensus-layer simplicity.
Blob Transactions Explained
What is a Blob?
A blob is a 128KB chunk of data carried by a Type-3 transaction. Instead of posting L2 data to Ethereum calldata (expensive, permanent), L2 rollups post to blobs (cheap, ephemeral). Blobs are: (1) included in blocks, (2) verified by consensus, (3) stored for 18 days, (4) pruned from validator storage after 18 days. Blobs are data, not execution—they don't affect Ethereum state directly.
Blob Field Elements & Encoding
Internally, blobs are encoded as 4,096 field elements (a specific finite field). Each element is ~32 bytes, totaling 128KB. This encoding enables polynomial commitments (KZG) to prove blob data availability without storing full blobs. Field elements allow efficient cryptographic operations—proving chunks of data were committed without verifying the entire blob.
Per-Blob Gas & Inclusion
Each blob uses "blob gas" (separate from normal execution gas). Blob gas price is determined by a dynamic market: base_blob_gas increases if avg block blob usage > 3 blobs, decreases if < 3. Max 6 blobs per block. Cost: ~$0.001-0.01 per blob during low congestion, up to $0.10+ during high demand (rare). L2s post multiple blobs per block to amortize costs.
Transient vs Permanent Data
Blobs are transient: nodes delete them after 18 days to save disk space (100+ GB per year avoided). Calldata is permanent: stored in transaction history forever. For L2s, transient is fine—L2 sequencers must download blobs within 18 days to reconstruct L2 state. After 18 days, L2 nodes have L2 state locally; they don't need original blobs. Blobs enable "data availability without data permanence."
Dencun Upgrade Impact on L2 Fees
Arbitrum One: 95% Fee Reduction
Arbitrum integrated blob posting in April 2024 (post-Dencun). Fees dropped from ~$0.50-1.00 per tx to ~$0.01-0.05. A 100-transaction batch that cost $50-100 now costs $1-5. Arbitrum's AnyTrust model (7 sequencers, 2 honest assumption) benefited most because it already reduced DA costs; blobs further compressed them.
Optimism: 86% Fee Reduction
Optimism rolled out blobs June 2024 (after internal testing). Fees dropped from ~$0.20-0.30 to ~$0.02-0.05. Optimism's Bedrock architecture posts state diffs (variable size) to blobs. Dynamic blob gas pricing means fees fluctuate based on blob congestion, but still 80%+ cheaper than pre-Dencun.
Other L2s: Similar Savings
Base (Coinbase's Optimism fork) saw ~85% fee drops. Polygon, zkSync, StarkNet integrated or plan blob support. Even Solana (non-EVM) benefits indirectly as cross-chain bridges use cheaper Ethereum DA. Blob economics have reshaped L2 competitive landscape—rollups with efficient blob usage have inherent cost advantages.
Financial Impact
Total DA costs per day: Arbitrum saves ~$1M+ daily (50k txs * $0.05 saved per tx). Across all L2s, EIP-4844 saves users ~$2-3M daily. Annualized: $730M-$1.1B in user cost savings. This is a massive unlock for DeFi, gaming, social apps that were prohibitively expensive at $0.50-1.00 per tx.
Before & After EIP-4844 Comparison
| Metric | Pre-Dencun (Calldata) | Post-Dencun (Blobs) | Improvement |
|---|---|---|---|
| Arbitrum TX Cost | $0.50-1.00 | $0.01-0.05 | 95% |
| Optimism TX Cost | $0.20-0.30 | $0.02-0.05 | 86% |
| Data Per Block | ~130KB (1 block) | ~768KB (6 blobs) | 5.9x |
| Node Storage (annual) | No pruning (full history) | 18-day pruning (270GB saved/yr) | Archive optional |
| Gas Per KB | 16 gas/byte = 16k gas/KB | 0.125 gas/byte = 125 gas/KB | 128x cheaper |
| L1 Overhead | Dominant (>90% of L2 cost) | Reduced to 10-40% | Computation now matters |
KZG Commitments & Cryptography
What is KZG?
KZG (Kate-Zaverucha-Goldberg) is a polynomial commitment scheme allowing a prover to commit to a polynomial (blob data) with a small commitment (48 bytes), then prove specific evaluations (data availability proofs) without revealing the entire polynomial. Used since 2010, proven secure under elliptic curve assumptions. Ethereum uses BLS12-381 curve for KZG verification.
The Ceremony & Trusted Setup
KZG requires a "trusted setup" ceremony: 140,000+ participants generated cryptographic randomness to create public parameters. If any participant saves their randomness ("toxic waste"), they could forge proofs. Ethereum's KZG ceremony (Nov 2022 - April 2023) was the largest cryptographic ceremony ever—distributed, transparent, impossible to fully corrupt. Public parameters are now frozen on-chain.
Blob Commitment Verification
When a blob is included, consensus nodes verify the KZG commitment against the blob. Verification is fast (~10ms) because commitments are small. Light clients can verify blobs existed using commitments alone, without downloading full blob data. This enables rollup lightclients and bridging—proving blobs were committed without needing full data.
Future: Quantum-Resistant Commitments
KZG is secure against classical computers but vulnerable to quantum attacks (distant future concern). Ethereum research explores lattice-based commitments (MLWE, LWE) as quantum-resistant alternatives. Full Danksharding may migrate to lattice commitments, but today's KZG is considered secure.
Blob Gas Market Dynamics
Base Blob Fee Mechanism
Blob gas has a dynamic base fee (EIP-1559-like) set by validators. If avg block blob usage > 3 (out of 6 max), base fee increases. If < 3, it decreases. Starting base fee: 1 wei per blob. With high adoption, base blob gas can reach 1000-10000+ wei per blob, but still cheaper than calldata (16 gas/byte).
L2 Sequencer Strategies
Sequencers batch transactions and post data via blobs. During low congestion, they post frequently (1 blob per block or every 12 sec). During high congestion, they batch larger amounts (multiple blobs). Some sequencers use batching algorithms to optimize blob usage—waiting 2-3 blocks to fill 1 blob vs posting half-full blob. Trade-off: higher throughput vs longer finality delay.
Blob Availability Sampling (BAS)
Today, full nodes store blobs for 18 days. Blob Availability Sampling (future feature) will enable light clients to verify blob availability by downloading small random samples (1-2KB) instead of full 128KB blobs. This reduces light client bandwidth to ~1-5% of blob size, enabling mobile clients and ultra-light verification.
Data Availability Committees (DAC)
Some L2s (Arbitrum) also use off-chain DACs: committees attest to data availability without posting to Ethereum. EIP-4844 blobs are on-chain DA (decentralized, trustless). DACs are trade-off: faster/cheaper but require trusting committee. Future roadmap: hybrid DA—use blobs for main settlement, DACs for optional faster finality.
Full Danksharding Roadmap
Proto-Danksharding Today (Single Dimension)
EIP-4844 provides one "dimension" of data: 6 blobs per block = 768KB per block = 6.5 MB per slot (average 12-second blocks). Full nodes store all data. This is "proto" (temporary step) toward scaling to multiple dimensions.
2D Danksharding (Phase 1: 2025-2026)
2D Danksharding introduces second dimension: instead of all validators storing all blobs, blobs are divided into "rows" and "columns." Each validator stores only their assigned row/column (~1/32 of data). KZG 2D polynomial commitments enable cross-column recovery—if 50% of columns are available, full blob is recoverable. This enables:
- More blobs per block: 32x or 64x more data throughput
- Lower bandwidth per validator: ~1/32 of full blob load
- Decentralized DA: more validators can participate despite high bandwidth
64-Shard Danksharding (Phase 2: 2027+)
Full Danksharding distributes data across 64 shards. Each shard has separate committees. Per-shard throughput: 16MB/shard * 64 shards = 1GB per 12-second block (theoretical max). In practice, bottleneck is L1 execution capacity, not data capacity. Danksharding unlocks ~1000x data scalability, but execution becomes bottleneck.
Layer 3s & Recursive Rollups
Even after Danksharding, if data becomes cheap, L2s may spawn L3s (rollups on top of rollups). L3 = settlement on L2 = DA from L1 blobs (multi-layer). Ethereum becomes DA + settlement layer, not execution. This is Vitalik's "endgame" vision: cheap data supports unlimited scaling via recursion.
FAQ
Why 128KB blob size specifically?
128KB = 4,096 field elements (each ~32 bytes). This size optimizes KZG verification (polynomial degree matching), network bandwidth (fits in single TCP packet), and consensus overhead. Too small (64KB) = more txs, more overhead. Too large (256KB) = slower verification, harder for full nodes. 128KB is the Goldilocks zone for today's hardware.
What if L2 doesn't download blobs within 18 days?
Catastrophic: L2 state becomes unrecoverable. In practice, this won't happen because: (1) Ethereum incentivizes blob storage (validators earn fees). (2) L2 nodes download blobs immediately, don't wait. (3) Archive nodes keep blobs indefinitely (voluntary). (4) Early warning systems would alert L2 teams to validator attrition. 18 days is conservative; practically, blobs are retained longer.
Can I see blob data in a block explorer?
Yes, most block explorers (Etherscan, Beaconcha.in) display blob transactions and link to blob data. Blob data is accessible via Ethereum JSON-RPC (beacon_getBlobSidecar API). You can decode blob data manually (raw hex) but it's mostly L2-specific encoding (rlp, snappy compression). User-friendly explorers will show decoded L2 transactions once blob parsing is standard.
Does EIP-4844 affect Ethereum gas for smart contracts?
No. EIP-4844 only introduces blob gas, a separate gas pool. Regular transaction execution gas (for storage, computation) is unchanged. Calldata still costs 16 gas/byte. Blobs don't affect Ethereum state directly—they're data-only, validated but not executed. Smart contracts can't read blob contents (blobs aren't in state, only KZG commitments are).
What about MEV in blob transactions?
Blobs are not execution transactions, so MEV is minimal. MEV occurs when a sequencer/validator observes pending txs, reorders them, and profits. Blobs are opaque to Ethereum consensus—only L2 sequencers can read blob contents. This gives L2 sequencers MEV advantage (they see user txs before posting to blobs). Future designs (encrypted mempools, threshold encryption) may minimize L2 sequencer MEV.
Can private/dark pools use blobs?
Technically yes, but blobs are public on-chain. No data privacy. Dark pools operating on Ethereum would need separate confidentiality layer (encrypted mempool, threshold encryption). Some proposals (MPC blobs, zero-knowledge blobs) aim to add privacy, but today's EIP-4844 blobs are fully transparent.
Educational disclaimer: This guide is for informational purposes only and does not constitute financial advice. Crypto involves significant risk — do your own research before making any decisions. Learn more about our team.
Educational disclaimer: This guide is for informational purposes only and does not constitute financial advice. Crypto involves significant risk — do your own research before making any decisions. Learn more about our team.