Case Study 2: EIP-4844 and Proto-Danksharding — How Ethereum Made Rollups 10x Cheaper Overnight

The Day the Fees Dropped

On March 13, 2024, at Ethereum block 19,426,587, the Dencun upgrade activated on mainnet. Among its many changes, one stood out for its immediate, dramatic impact: EIP-4844, also known as Proto-Danksharding. Within hours, the cost of transacting on Ethereum's Layer 2 rollups plummeted. Fees on Arbitrum, Optimism, and Base fell by 90% or more. A simple token transfer that had cost $0.25 on an L2 the day before now cost less than a penny.

For the hundreds of thousands of users transacting on L2s daily, the effect was transformative. For the Ethereum ecosystem as a whole, it validated a years-long bet that the right way to scale Ethereum was not to make L1 faster, but to make L1 a better foundation for L2s. This is the story of how that upgrade came together, what it changed, and what it foreshadowed.

The Problem: Data Costs Dominated L2 Fees

To understand why EIP-4844 mattered so much, you need to understand the anatomy of an L2 transaction fee.

When you submit a transaction on an optimistic or ZK-rollup, you pay for two things:

1. L2 execution cost: The computational cost of executing your transaction on the rollup. This is cheap — rollups are fast, and their block space is not as contested as L1.

2. L1 data posting cost: The cost of including your transaction's data in a batch that gets posted to Ethereum L1. This is expensive — because it uses L1 block space, which is in high demand.

Before EIP-4844, rollups posted their transaction data as calldata — the input data field of a regular Ethereum transaction. Calldata is priced at 16 gas per byte (for non-zero bytes) and competes directly with every other Ethereum transaction for the same block space.

The result was a stark cost breakdown. On a typical optimistic rollup before EIP-4844:

Read that again: 80-95% of the cost of an L2 transaction was the cost of posting data to L1. The rollup's own execution was nearly free. The bottleneck was not computation — it was data.

This meant that L2 fee optimization was almost entirely a question of data compression and L1 data pricing. Rollup teams invested heavily in compression algorithms (using techniques like run-length encoding, shared address tables, and signature aggregation) to minimize the bytes they posted to L1. But there was only so much compression could achieve. The fundamental problem was that calldata was expensive because it competed for the same scarce resource as everything else on Ethereum.

The Insight: Separate Fee Markets

The key insight behind EIP-4844 was simple but profound: rollup data and execution data have fundamentally different requirements, and they should be priced in separate markets.

Consider what rollup data actually needs from Ethereum:

• Availability: The data must be downloadable by anyone for long enough to allow fraud proofs (optimistic rollups) or state reconstruction (either type). This period is roughly 2-3 weeks.
• Ordering: The data must be included in the Ethereum block sequence so its ordering is guaranteed.
• Not execution access: Smart contracts on L1 do not need to read rollup transaction data. The data is consumed by off-chain actors (rollup nodes, verifiers, challengers), not by the EVM.

Now consider what execution data (the calldata of regular L1 transactions) needs:

• Availability: Forever — contract state depends on historical transactions.
• EVM access: Smart contracts need to read calldata to execute logic.
• Immediate processing: The EVM must process the calldata during block execution.

These are completely different requirements. But before EIP-4844, both types of data competed for the same calldata space and were priced identically. It was as if a city charged the same rate for parking spaces in the financial district and in a suburban park — the scarce downtown spaces drove up prices for everyone.

The Technical Design

EIP-4844 introduced a new transaction type — Type 3 transactions — that can carry large data attachments called blobs (Binary Large Objects). Here is how blobs work:

Blob Properties

• Size: Each blob is approximately 128 KB (131,072 bytes, technically 4,096 field elements of the BLS12-381 elliptic curve)
• Limit: Initially, the target is 3 blobs per block (with a maximum of 6), providing roughly 384 KB to 768 KB of blob space per block
• Separate fee market: Blobs have their own base fee that adjusts independently of the regular gas base fee, using the same EIP-1559 mechanism (price increases when demand exceeds the target, decreases when demand is below)
• Temporary storage: Blob data is guaranteed to be available for approximately 18 days (~4,096 epochs), after which nodes may prune it. The blob commitment (a KZG polynomial commitment) remains on-chain permanently
• No EVM access: Smart contracts cannot read blob data. They can only verify the KZG commitment, which proves that the blob data was available at the time the block was produced

KZG Commitments

Each blob is accompanied by a KZG (Kate-Zaverucha-Goldberg) commitment — a type of polynomial commitment scheme. Without going deep into the cryptography, a KZG commitment is a compact (48-byte) proof that:

1. A specific blob of data was submitted
2. The data matches the commitment (tamper-evident)
3. The data can be sampled — individual elements of the blob can be verified without downloading the entire blob

This last property is critical for the future: it enables Data Availability Sampling (DAS), where light nodes can verify that blob data is available by downloading only a small random sample. DAS is not implemented in EIP-4844 (hence "Proto-Danksharding"), but the KZG commitment scheme was chosen specifically to be forward-compatible with DAS.

The Trusted Setup Ceremony

KZG commitments require a structured reference string (a set of cryptographic parameters) generated through a trusted setup ceremony. Ethereum conducted this ceremony — called the KZG Ceremony or the Powers of Tau ceremony — from December 2022 to April 2023. Over 141,000 participants contributed entropy, making it the largest trusted setup ceremony in cryptographic history. The security assumption is that at least one participant was honest and properly destroyed their secret contribution — a "1-of-141,000" trust assumption that is practically unbreakable.

The Implementation Path

EIP-4844 did not appear overnight. Its development spanned several years and involved extensive community debate.

2020-2021: The danksharding vision. Ethereum researcher Dankrad Feist proposed "danksharding" — a data sharding scheme that would massively increase Ethereum's data throughput using a combination of erasure coding, KZG commitments, and DAS. The proposal envisioned 32 MB of data per block.

2022: The "proto" compromise. Full danksharding was recognized as a multi-year engineering effort. Vitalik Buterin and Protolambda proposed EIP-4844 as a stepping stone — it would introduce the blob transaction type, the separate fee market, and the KZG commitment scheme, but without DAS and with a much smaller data target (3 blobs per block instead of hundreds). This gave rollups immediate relief while laying the groundwork for future scaling.

2023: Testing and auditing. EIP-4844 went through extensive testing on Ethereum's devnets and testnets (Goerli, Sepolia, Holesky). Multiple client teams (Geth, Prysm, Lighthouse, Teku, Lodestar, Nethermind, Besu, Erigon) all needed to implement the same specification correctly. The KZG ceremony was conducted and verified.

March 13, 2024: Dencun activation. The Dencun upgrade (named after Deneb, the consensus layer upgrade, and Cancun, the execution layer upgrade) went live on mainnet at slot 8,626,176. EIP-4844 was one of several EIPs included, but it was the one that dominated the conversation.

The Immediate Impact

The effects were visible within hours.

Fee Reduction

The fee drops were most dramatic on optimistic rollups (Arbitrum, Optimism, Base), which had been paying the most for calldata. ZK-rollups saw slightly smaller reductions because a portion of their L1 cost is proof verification (which still uses regular gas), not data posting.

Transaction Volume

Lower fees immediately unlocked new activity:

• Base saw its daily transaction count increase from approximately 1 million to over 3 million within a week of the upgrade
• Arbitrum experienced a surge in DeFi activity, particularly in protocols that relied on frequent, small transactions (like perpetual futures and yield farming)
• New applications that had been uneconomical at $0.25 per transaction became viable at $0.01 — including social media tipping, on-chain gaming, and micropayment streaming

Blob Fee Market Dynamics

In the initial weeks after launch, the blob fee market operated at or near its minimum price because demand was below the target of 3 blobs per block. This meant blob space was essentially free (base fee of 1 wei). As more rollups adopted blobs and demand increased, the base fee began to fluctuate, but it remained far below the calldata price.

The fee market design included an important feature: if blob demand exceeds the target (3 blobs per block) for an extended period, the blob base fee rises exponentially — just like the regular EIP-1559 gas mechanism. This creates economic pressure to develop full danksharding (which increases the blob target from 3 to many more) before the blob market becomes congested.

The Deeper Implications

Validation of the Rollup-Centric Roadmap

EIP-4844 was the most tangible validation of Ethereum's strategic shift toward a rollup-centric roadmap. Rather than trying to make L1 handle all the world's transactions directly, Ethereum optimized L1 to be the best possible foundation for L2s. The message was clear: Ethereum's L1 is the settlement and data availability layer; execution happens on L2.

This had been the stated strategy since Vitalik Buterin's October 2020 blog post "A rollup-centric Ethereum roadmap," but EIP-4844 was the first major protocol change that embodied it. The fact that it worked — dramatically reducing L2 costs while maintaining L1 security — vindicated the approach.

The Compression Arms Race Continues

Ironically, the blob fee market created new incentives for rollup teams to optimize data further. When calldata was expensive and undifferentiated from other gas costs, rollup teams optimized compression to save money. With blobs, the marginal cost of additional data dropped sharply, but the total cost per blob was still nonzero. This incentivized rollups to:

• Batch more transactions per blob (improving amortization)
• Develop better compression to fit more transactions per blob
• Explore shared blob posting (multiple rollups sharing a single blob)

Blob Data Pruning and the Archive Problem

EIP-4844's temporary storage model — blob data is available for ~18 days and then pruned — created a new challenge. After pruning, the blob data is no longer available from the consensus layer. If a rollup needs to reconstruct its state from scratch (e.g., for a new full node to sync from genesis), it needs access to historical blob data.

Several solutions have emerged:

• Archival services: Third-party services (like BlobScan, EthStorage) that persist blob data beyond the pruning window
• Rollup-specific archives: Rollup teams maintaining their own historical data stores
• DA layer redundancy: Some rollups post data to both Ethereum blobs and an alternative DA layer (like Celestia) for redundancy

This is an area of active development and debate. The Ethereum community generally considers the 18-day availability window sufficient for security purposes (fraud proofs for optimistic rollups must be submitted within 7 days), but long-term archival is a separate concern.

The Path to Full Danksharding

EIP-4844 is explicitly designed as a stepping stone. The full danksharding roadmap includes:

1. Proto-Danksharding (EIP-4844): Done. 3-6 blobs per block, no DAS. (Completed March 2024)
2. Increasing the blob count: The next step is to increase the target from 3 blobs to 6 or more (EIP-7594 proposes peer DAS to enable this safely). This could happen in the Pectra or subsequent upgrade.
3. Data Availability Sampling: Implementing DAS so that nodes do not need to download every blob — they only sample random pieces and use erasure coding to verify availability. This dramatically reduces per-node bandwidth requirements and enables many more blobs per block.
4. Full Danksharding: The end state — potentially 64 or more blobs per block, providing 8-16 MB of data per block. At this scale, DA costs for rollups approach zero, and Ethereum can support hundreds of high-throughput rollups simultaneously.

The timeline for full danksharding is uncertain — it depends on complex engineering challenges in DAS implementation, peer-to-peer networking, and client optimization — but the incremental path through EIP-4844 means that each step delivers tangible value.

The Broader Lesson

The EIP-4844 story illustrates several principles that extend beyond blockchain engineering:

Separate markets for separate goods. When resources with different characteristics are forced into a single market, the most demand-intensive use case drives up prices for everyone. Creating separate markets — with separate pricing mechanisms — can dramatically improve efficiency for all participants. This principle applies to cloud computing (spot instances vs. reserved instances), electricity (time-of-use pricing), and transportation (HOV lanes, congestion pricing).

Stepping stones beat moonshots. Full danksharding was the vision, but Proto-Danksharding delivered 90% of the immediate value with a fraction of the implementation complexity. By choosing the "proto" path, Ethereum got rollups meaningful cost relief years earlier than full danksharding could have been implemented.

Infrastructure improvements unlock application innovation. Nobody predicted exactly which applications would flourish once L2 fees dropped to sub-penny levels. The surge in on-chain social (Friend.tech, Farcaster's on-chain actions), gaming (on-chain game engines), and micropayment applications happened because the infrastructure made them economically viable — not because they were planned in advance.

Coordination across competing teams is possible. EIP-4844 required coordinated implementation across all Ethereum execution and consensus clients — over a dozen separate software teams with different codebases, languages, and organizational structures. The fact that they achieved this coordination, through a combination of specification documents, interoperability testing, and devnet iterations, is itself a significant organizational achievement.

Discussion Questions

1. EIP-4844 reduced L2 fees by 90%. Is this enough, or will further cost reductions be needed for blockchain to achieve mainstream adoption? What types of applications are still uneconomical at $0.01 per transaction?

2. The temporary nature of blob storage (18 days) creates a dependency on archival services for long-term data. Is this an acceptable tradeoff? How does it compare to the permanent data availability of calldata?

3. Some critics argue that EIP-4844 benefits L2s at the expense of Ethereum L1 validators, because blob fees are much lower than the calldata fees they replace. Evaluate this argument. Is there a way to structure blob pricing that benefits both L2 users and L1 validators?

4. The blob fee market is currently uncongested (demand below target). What happens when demand exceeds target and blob fees start rising significantly? Which rollups will be priced out first, and what alternatives do they have?

5. Celestia launched its mainnet in October 2023, and EIP-4844 activated in March 2024. How do these two events relate? Has EIP-4844 reduced the need for alternative DA layers, or do they serve complementary purposes?