EIP-4844 introduces blobs. This new transaction type creates a dedicated, low-cost data channel separate from calldata, directly addressing the primary cost driver for Layer 2s like Arbitrum and Optimism.
Proto Danksharding Resource Limits Explained Clearly
A first-principles breakdown of EIP-4844's core constraints: blob gas markets, target vs. max blobs, and the hard fork that redefined Ethereum's data economics.
Introduction
Proto-Danksharding redefines Ethereum's resource limits to scale data availability, not execution.
The limit is 3 blobs per block. This is a soft, consensus-level target that provides a predictable, scalable data budget for rollups, unlike the variable and congested calldata market.
Blobs are ephemeral. Data persists for ~18 days, sufficient for fraud proofs and data availability sampling, which reduces long-term storage burdens compared to permanent calldata.
Evidence: Current calldata can consume over 90% of a block's gas. EIP-4844 is projected to reduce L2 transaction fees by 10-100x by decoupling data costs from EVM execution gas.
Executive Summary: The Three Hard Limits
Proto-Danksharding (EIP-4844) doesn't magically scale Ethereum. It strategically removes three concrete hardware bottlenecks that currently cap rollup throughput and cost.
The Problem: Node Storage Bloat
Full nodes must store all transaction data forever, creating a ~1 TB+ chain history that limits participation and inflates hardware costs. This is the primary constraint on data availability for rollups like Arbitrum and Optimism.
- Bottleneck: Historical data growth rate
- Impact: Higher node requirements → fewer nodes → centralization risk
The Solution: Blob-Carrying Transactions
Introduces a new transaction type that carries large ~128 KB data blobs. These blobs are stored separately from main execution and are automatically pruned after ~18 days (≈ 4096 epochs).
- Mechanism: Decouples data availability from permanent storage
- Result: Nodes only need to store blobs temporarily, slashing long-term storage needs by >90% for rollup data
The Problem: Consensus & P2P Overhead
Broadcasting and agreeing on large data chunks today consumes the same scarce bandwidth and consensus resources as execution. This creates a hard cap on total block data (~1-2 MB today) shared by all L2s.
- Bottleneck: Gossip network and consensus layer bandwidth
- Impact: Data becomes a zero-sum resource; rollups compete and drive up calldata costs
The Solution: Separate Blob Fee Market
Creates a dedicated EIP-1559-style fee market for blob space, independent from execution gas. Targets ~3 blobs/block initially, scaling to 16+ with full Danksharding.
- Mechanism: Isolates data demand from execution demand
- Result: Predictable, low-cost data for rollups; prevents L1 congestion from spiking L2 fees
The Problem: Synchronization Latency
New nodes and validators must download and verify the entire history, a process taking hours to days. This slow sync time is a security and liveness risk, discouraging new participants.
- Bottleneck: Initial Block Download (IBD) speed
- Impact: Weakens network resilience and increases time-to-finality for new observers
The Solution: Prunable Historical Data
By making blob data ephemeral, the steady-state storage requirement for nodes becomes fixed. A node can sync from a recent checkpoint by downloading only execution data, not years of blob history.
- Mechanism: Bounds the mandatory dataset for node operation
- Result: Enables <1 hour sync times for consensus nodes, strengthening decentralization
The Calldata Problem and the Blob Solution
Proto-Danksharding introduces a dedicated data channel, blobs, to decouple execution from data availability, solving Ethereum's unsustainable calldata cost model.
Calldata was a subsidy. Ethereum historically used execution-layer calldata for rollup data, creating a massive, mispriced state growth subsidy that threatened long-term security and fee predictability for chains like Arbitrum and Optimism.
Blobs are a separate resource. EIP-4844 introduces blob-carrying transactions with a dedicated fee market, isolating rollup data costs from EVM execution. This prevents congestion from an NFT mint on Ethereum from spiking fees for an Arbitrum user.
The target is 3 blobs per block. This initial limit, a precursor to full Danksharding's 64, provides ~0.375 MB of dedicated data space per slot, establishing a predictable base for rollup scaling without overloading consensus clients.
Evidence: Post-EIP-4844, L2 transaction fees on Arbitrum and Base are now dominated by execution costs, not data posting costs, which fell by over 90%. The blob fee market operates independently, proven during the recent EIP-4844 gas spike event.
Resource Limit Comparison: Pre vs. Post Dencun
A quantitative breakdown of how EIP-4844 (Proto-Danksharding) fundamentally changes the resource economics for Layer 2 rollups by introducing blob-carrying transactions.
| Resource / Metric | Pre-Dencun (Calldata) | Post-Dencun (Blobs) | Change Implication |
|---|---|---|---|
Primary Data Carrier | Transaction Calldata | Blob (Binary Large Object) | Decouples settlement data from execution data. |
Pricing Model | Gas Auction (volatile) | Separate Blob Fee Market (EIP-4844) | Stable, predictable data costs for rollups. |
Target Cost per Byte | ~16 gas/byte (expensive) | ~0.125 gas/byte (target) | ~99% cost reduction for L2 data. |
Data Persistence on L1 | Permanent (full history) | ~18 days (then pruned) | Nodes only need blob data for finality window. |
Throughput per Block | ~90 KB (practical limit) | ~1.8 MB (theoretical max) | 20x increase in data availability capacity. |
Blobs per Block (Target) | N/A | 3 (initial), scaling to 16+ | Enables parallel data submission for multiple rollups. |
Impact on L1 Gas Price | Direct competition with users | Minimal competition | Decouples L1 congestion from L2 data costs. |
Key Beneficiaries | None (status quo) | Optimism, Arbitrum, zkSync, Base | All rollups see lower costs, higher throughput. |
First Principles: How Blob Gas Actually Works
Proto-Danksharding introduces a separate gas market for data, decoupling execution costs from data availability pricing.
Blob gas is separate. It exists on a distinct fee market from standard execution gas, preventing L2 data posting from congesting user transactions. This separation is the core mechanism for predictable L2 costs.
Blobs are ephemeral. Data blobs persist for ~18 days, not forever. This temporary storage enables the 1 MB per block target while keeping node storage requirements manageable for clients like Nethermind and Erigon.
Targets enforce scarcity. The system uses a target blob count and a maximum blob count per block. Fees adjust exponentially based on deviation from the target, creating a self-regulating market for block space.
Evidence: Post-EIP-4844, the average blob gas price has remained near 1 wei, while execution gas spiked during memecoin frenzies, proving the markets are decoupled. L2s like Arbitrum and Optimism now have stable data costs.
FAQ: Builder Questions, Answered
Common questions about Proto Danksharding Resource Limits Explained Clearly.
The main goal is to reduce L2 transaction fees by introducing blob-carrying transactions, a precursor to full Danksharding. Blobs are large data packets stored temporarily by consensus nodes, decoupling data availability from expensive calldata. This directly lowers costs for rollups like Arbitrum and Optimism.
Beyond Proto-Danksharding: The Path to Full Danksharding
Proto-danksharding is a critical but incomplete step; full danksharding requires solving data availability sampling and cross-shard execution.
Proto-danksharding is a data availability layer. It introduces blob-carrying transactions and EIP-4844 to provide cheap, temporary data storage for rollups like Arbitrum and Optimism, decoupling data costs from execution gas.
Full danksharding requires data availability sampling. Clients will verify data availability by randomly sampling small chunks of the blob data, enabling secure scaling without downloading the entire dataset, a concept pioneered by Celestia.
The final bottleneck is execution. Even with infinite data bandwidth, a single execution thread remains limited. The endgame is a multi-threaded EVM or native cross-shard execution, moving beyond the current rollup-centric model.
Evidence: Current Ethereum processes ~50 TPS; full danksharding targets 100,000+ TPS for data, but execution scaling via zkEVM parallelism or Ethereum sharding is the unresolved challenge.
Takeaways: The New Rules of the Game
EIP-4844 fundamentally changes the scaling economics by introducing a new transaction type with ephemeral data blobs.
The Problem: The $1 Million Calldata Tax
Storing permanent data on-chain via calldata is the primary cost driver for L2s. Every byte is a permanent, expensive commitment.
- Cost: L2s spend ~90% of their transaction fees on this data availability.
- Inefficiency: Paying for eternal storage for data needed only for a ~2 week fraud/validity proof window.
The Solution: Ephemeral Data Blobs
EIP-4844 introduces blob-carrying transactions with data that is automatically pruned after ~18 days.
- Mechanism: Data is stored in the Beacon Chain consensus layer, not execution
calldata. - Result: L2s get ~100KB per block of cheap, temporary data availability, slashing fees.
- Ecosystem: Enables true scaling for Arbitrum, Optimism, zkSync, and other rollups.
The New Constraint: Blob Gas Market
Blob space is a separate, scarce resource with its own EIP-1559-style fee market, decoupled from execution gas.
- Dynamic Pricing: Blob gas price adjusts based on demand for this dedicated data lane.
- Throughput Limit: Initial target of ~0.375 MB/s, scaling to ~1.5 MB/s in future upgrades.
- Architectural Shift: Forces L2 sequencers and users to optimize for blob data efficiency.
The Endgame: Full Danksharding
Proto-Danksharding is the minimum viable scaffolding for the final design. It establishes the blob paradigm without requiring consensus changes.
- Pathway: Paves the way for data availability sampling (DAS) and ~16 MB per slot capacity.
- Modular Future: Solidifies Ethereum's role as a settlement & data availability layer for rollups like Starknet, Polygon zkEVM.
- Timeline: Enables scaling today while the PBS (Proposer-Builder Separation) and DAS infrastructure is built.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.