EIP-4844 and Blob Fees: How Ethereum's Danksharding Reshapes L2 Economics

Before March 2024, every Ethereum rollup competed for the same block space as token swaps, NFT mints, and DeFi liquidations. Rollups posted their transaction data as calldata, paying execution gas fees that fluctuated wildly with L1 demand. A single NFT frenzy could double costs for an Optimism user who just wanted to send stablecoins.

EIP-4844 (proto-danksharding) changed that by introducing a new transaction type carrying "blobs" of data with a completely separate fee market. The Dencun upgrade went live on March 13, 2024, and within days, L2 transaction costs dropped by over 95%. This article breaks down the mechanics of blob transactions, the economics of the blob fee market, and what comes next on the road to full danksharding.

What EIP-4844 Actually Changed

EIP-4844 introduced Type 3 transactions: a new transaction format that carries large binary data objects called blobs. Each blob is exactly 131,072 bytes (128 KB), structured as 4,096 field elements of 32 bytes each. Unlike calldata, blobs are not accessible to the EVM. Smart contracts can only read a blob's KZG commitment hash via the BLOBHASH opcode and verify proofs via a precompile at address 0x0A.

The critical design decision: blobs are ephemeral. Consensus-layer clients store them for approximately 18 days (4,096 epochs), then prune them automatically. Rollups only need this data to be available long enough for fraud proofs or validity proofs to be verified. After that window, the data can be sourced from archival services or reconstructed from L2 state. This temporary storage is what makes blobs dramatically cheaper than permanent calldata.

Why KZG commitments matter: Each blob is accompanied by a KZG polynomial commitment that lets anyone verify the blob's contents without downloading it entirely. The trusted setup ceremony for these commitments ran from January to March 2023 with over 141,000 contributors, operating under a 1-of-N trust assumption: the parameters are secure as long as at least one participant was honest.

The Pre-EIP-4844 Problem

Rollups previously posted compressed transaction batches as calldata in regular Ethereum transactions. Calldata costs 16 gas per non-zero byte and 4 gas per zero byte, and these costs compete directly with all other execution gas demand. During periods of high L1 activity, a simple L2 swap could cost several dollars just in data posting fees, undermining the cost advantage that rollups were supposed to provide.

The problem was architectural: Ethereum had a single resource market for fundamentally different types of demand. Computation (smart contract execution) and data availability (proving that transaction data was published) were priced identically, even though they impose different costs on the network.

How the Blob Fee Market Works

The blob fee market operates as a parallel EIP-1559-style mechanism, completely independent from execution gas pricing. This separation means that a spike in DeFi activity on L1 no longer affects what rollups pay to post data.

Target and Maximum Blob Counts

At launch, each Ethereum block targeted 3 blobs (393,216 blob gas) with a maximum of 6 blobs (786,432 blob gas). When blocks consistently carry more than the target, the blob base fee increases. When they carry fewer, it decreases. This elastic pricing mechanism naturally adjusts to demand.

The Base Fee Formula

The blob base fee uses an exponential adjustment function rather than the linear approach of execution gas:

blob_base_fee = MIN_FEE × e^(excess_blob_gas / UPDATE_FRACTION)

The excess_blob_gas accumulates when blocks include more blobs than the target and drains when they include fewer:

excess_blob_gas = max(0, parent_excess + parent_used - TARGET_GAS)

The BLOB_BASE_FEE_UPDATE_FRACTION (originally 3,338,477) limits fee changes to approximately 12.5% per block, matching the execution gas adjustment rate from EIP-1559. This means fees can rise rapidly during sustained demand but cannot spike instantly from a single block.

Separate markets, separate burns: Blob fees are burned just like execution base fees under EIP-1559, contributing to ETH deflation. However, because blobs spent most of 2024 near the 1-wei floor price, blob fee burns were negligible until sustained demand emerged in late 2024.

Fee Floor Mechanics

EIP-4844 originally set the minimum blob base fee at 1 wei, effectively zero cost. This proved problematic: when blob space was underutilized (which it was for most of 2024), rollups posted data for essentially nothing, creating no economic signal for the network. The Fusaka upgrade in December 2025 addressed this with EIP-7918, which replaced the static 1-wei floor with a dynamic minimum tied to L1 execution costs. The new formula sets the blob floor at 1/16 of the execution base fee, ensuring blobs always reflect the actual computational cost of verifying KZG proofs.

Impact on L2 Costs: Before and After

The cost reduction from EIP-4844 was immediate and dramatic. Optimistic rollups and ZK rollups alike saw transaction fees plummet within hours of the Dencun activation. The following table shows median transaction costs for major L2s before and after the upgrade.

Base experienced a 224% rise in transaction volume after the fee reduction, demonstrating the elastic demand that cheaper transactions unlock. By mid-2026, median fees have settled further: Base averages approximately $0.05 per transaction, Arbitrum One and OP Mainnet around $0.09, and zkSync Era around $0.07.

The reduction was not uniform across rollup types. zkSync Era's more modest initial improvement reflected its different architecture: ZK rollups post validity proofs alongside data, and zkSync's phased blob adoption meant the full benefit took longer to materialize. After optimization, zkSync's sequencer calldata costs dropped from 0.11 ETH to 0.013 ETH per batch, an 88% reduction in data posting overhead.

Blob Market Dynamics: From Empty to Contested

The blob fee market has gone through distinct phases since launch, illustrating how a new resource market finds equilibrium.

The Silent Period (March to October 2024)

For the first seven months, blob utilization was far below the 3-blob target. The base fee sat at or near 1 wei, meaning rollups posted data for essentially free. Blocks rarely contained more than one or two blobs. While this validated the cost-reduction thesis, it raised questions about whether blob space had been over-provisioned.

One brief exception: “BlobScriptions” in March and April 2024, where users experimented with storing inscription-style data in blobs, temporarily pushing fees above the floor. This was speculative activity rather than genuine rollup demand.

The November 2024 Spike

The first real test of blob fee economics came in November 2024. Surging L2 activity during a broader market rally pushed average blobs per block to 4.3, well above the 3-blob target. The blob base fee spiked to as high as $80 per blob submission, and approximately 166 ETH (~$560,000) was burned from blob fees in a single week. On-chain transaction volume across L2s hit all-time highs, up roughly 40% compared to summer 2024.

This spike demonstrated both the strength and the limitation of the initial design: the fee market worked exactly as intended (prices rose when demand exceeded supply), but the 3-blob target was clearly too low for the growing L2 ecosystem.

Post-Upgrade Expansion

Subsequent upgrades progressively expanded blob capacity. After Pectra doubled the target to 6 blobs in May 2025, demand caught up by September 2025, with nearly every block full. After Fusaka and the BPO forks raised the target to 14 blobs by January 2026, utilization dropped to 20-30% of capacity, as supply once again outpaced demand. The fee market had stabilized rather than continuing the downward spiral that characterized the early months.

Scaling the Blob Count: Pectra, Fusaka, and Beyond

EIP-4844 was always intended as proto-danksharding: a stepping stone toward full data availability scaling. Each subsequent upgrade has expanded blob capacity while refining the fee market mechanics.

Pectra: Doubling the Target

The Pectra upgrade (May 7, 2025) included EIP-7691, which doubled the blob target from 3 to 6 and raised the maximum from 6 to 9. A subtle but important change: the target-to-max ratio shifted from 1:2 to 2:3, creating asymmetric fee adjustments. When blocks carry zero blobs, the base fee decreases by approximately 14.5%. When blocks are full (9 blobs), it increases by only about 8.2%. This asymmetry biases the market toward lower fees when demand is low while limiting upward pressure during spikes.

Pectra also included EIP-7623, which capped worst-case block size to offset the increased bandwidth from more blobs, preventing the overall block size from growing beyond what the network could safely propagate.

Fusaka and PeerDAS: Data Availability Sampling

The Fusaka upgrade (December 3, 2025) introduced PeerDAS (EIP-7594), a fundamental change in how nodes handle blob data. Instead of every node downloading every blob, PeerDAS uses Reed-Solomon erasure coding to split extended blob data into 128 columns distributed across dedicated gossip subnets. Each regular node subscribes to only 8 of these 128 subnets, downloading roughly 1/16 of all data. Nodes verify data availability by sampling: checking a few polynomial evaluation points rather than downloading entire blobs.

PeerDAS enabled the rapid capacity increases through BPO (Blob Parameter Only) forks, introduced by EIP-7892. Unlike traditional hard forks, BPO forks modify only three parameters (target, max, and base fee update fraction) and require no client-side code changes, allowing rapid deployment in response to network conditions.

The Road to Full Danksharding

Full danksharding (sometimes called FullDAS) extends the PeerDAS concept with 2D erasure coding across the entire matrix of blob data, creating stronger redundancy and more efficient verification. The target is 64 to 128 blobs per slot, representing roughly 8 to 16 MB of blob data per block.

The Glamsterdam upgrade, targeting late August 2026, introduces EIP-7732 (Enshrined Proposer-Builder Separation), which expands the block propagation window from 2 seconds to approximately 9 seconds. This unblocks further blob scaling, potentially reaching 72 or more blobs per block. Full danksharding remains officially “several years away” with no concrete mainnet date.

Infrastructure Challenges at Scale

Expanding blob capacity is not free. As blob counts increase, block propagation times grow, and the probability of missed block proposals rises. At the current BPO2 maximum of 21 blobs, the miss rate climbs to approximately 1.79%, compared to a baseline of roughly 0.5% for blocks with fewer blobs. Blocks with 16 or more blobs remain extremely rare, suggesting that validators and block builders are actively avoiding near-maximum blob counts to reduce miss risk.

This creates a practical ceiling below the theoretical maximum: the effective blob capacity is lower than the protocol allows because economic incentives discourage validators from building blocks that are too large to propagate reliably. PeerDAS and ePBS are specifically designed to address this constraint, but the tension between capacity and reliability will persist as blob counts continue to increase.

Ethereum vs. Bitcoin: Different Scaling Philosophies

Ethereum's blob-centric scaling strategy reflects a fundamental architectural choice: rollups execute transactions off-chain but post compressed data back to L1 for security. This means Ethereum L2s will always need some form of on-chain data availability, whether through calldata, blobs, or future danksharding. The entire blob fee market exists to price this ongoing demand.

Bitcoin takes a fundamentally different approach. Layer 2 protocols on Bitcoin, including statechains and payment channels, do not post transaction data to the base layer during normal operation. A Lightning channel, for example, only touches the Bitcoin blockchain when it opens and closes. The thousands of payments routed through that channel in between leave no on-chain footprint and incur no data availability costs.

Why Bitcoin L2s Skip Blob Space

The distinction is not merely technical: it reflects different trust models. Bitcoin L2 architectures like Spark use statechains to transfer ownership of Bitcoin UTXOs without broadcasting transactions. Ownership changes are cryptographic: the Spark Entity generates a new key for the recipient, adjusts its own key mathematically, and the old key is destroyed. No data needs to be posted anywhere because the security model does not depend on data availability. It depends on key deletion and the 1-of-N honest operator assumption.

This means Spark's transaction costs are not tied to base-layer block space demand at all. There is no equivalent of blob fees, no calldata competition, and no need to wait for danksharding to scale. The cost of a Spark transfer is determined by operator infrastructure costs, not by an on-chain resource market.

Neither approach is strictly superior. Ethereum's rollup model provides trustless verification through fraud or validity proofs, which require on-chain data. Bitcoin's statechain model avoids data costs entirely but introduces a trust assumption about operator behavior. The tradeoff is between cryptographic data availability guarantees and infrastructure simplicity.

What the Blob Fee Market Means for L2 Economics

The creation of a separate blob fee market has reshaped the competitive dynamics among Ethereum L2s in several ways.

Margin Compression

L2 sequencers earn revenue from the spread between what users pay and what the sequencer pays for L1 data posting. When data costs drop by 95%, that margin compresses dramatically unless L2s increase volume proportionally. Base's strategy of driving massive adoption at near-zero fees reflects this dynamic: the per-transaction margin is tiny, but the volume makes it sustainable.

Competition for Blob Space

As more L2s compete for limited blob space, periods of high demand will produce fee spikes that disproportionately affect smaller rollups. Large rollups with consistent transaction volume can amortize blob costs across more transactions. Smaller or newer rollups face higher per-transaction costs during peak periods, creating a structural advantage for scale.

Alternative DA Layers

The blob fee market has also fueled interest in alternative data availability solutions like Celestia and EigenDA. Some rollups post data to these external DA layers instead of Ethereum blobs, trading Ethereum's security guarantees for lower costs. This creates a multi-tier DA market where rollups choose their security and cost profile, a development that EIP-4844's architects anticipated but that the blob fee market has accelerated.

Looking Ahead

The blob fee market is still maturing. With BPO2's 14-blob target currently underutilized at 20-30% capacity, there is significant room for L2 growth before fee pressure returns. The planned path to 48 blobs under PeerDAS and eventually 64-128 blobs under full danksharding suggests that Ethereum's data availability capacity will continue expanding faster than demand for the foreseeable future.

For developers evaluating L2 infrastructure, the key insight from EIP-4844 is that scaling strategies depend fundamentally on how a protocol handles data. Ethereum chose to create a dedicated, priced market for L2 data. Bitcoin chose to build L2s that avoid on-chain data entirely. Both approaches are producing viable scaling solutions, but with very different cost structures, trust assumptions, and infrastructure requirements.

For those interested in Bitcoin's approach to scaling, the Spark documentation covers how statechains eliminate on-chain data costs while preserving self-custody. And for a broader comparison of how different Layer 2 architectures handle data availability tradeoffs, see our Bitcoin Layer 2 comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.