Blobonomics & the New Attack Surface: How Ethereum Is Hardening Its DA Layer
EIP-4844's Blob Pricing Created a New Attack Vector, Forcing Rollups to Design Smarter Economic Defenses
Thanks to the zkSecurity team for their paper “Unaligned Incentives: Pricing Attacks Against Blockchain Rollups”, which laid the groundwork for understanding DA mispricing and inspired many of the ideas explored here.
Key Takeaways
When Ethereum introduced blobs in March 2024 through EIP-4844, it quietly solved one of the biggest problems rollups faced: the cost of putting their data on Ethereum.
Before blobs, every rollup, Arbitrum, Optimism, Base, Scroll, zkSync, and many others had to post their transaction data as calldata on Ethereum’s main chain. This was expensive. In fact, 90% of a rollup’s costs went just to this data posting step.
Blobs changed that. Instead of squeezing rollup data into the same expensive space used for smart contracts, Ethereum created a separate lane just for data, cheaper, bigger, and still fully secured by Ethereum’s validators. This lowered costs dramatically and made it viable for rollups to offer cheaper transactions to users.
Then came Pectra in May 2025, which doubled blob capacity, increasing the target from 3 blobs per block to 6, and raising the maximum to 9.
The introduction of blobs through EIP-4844 didn’t just lower costs for rollups; it created a new fee market inside Ethereum.
The Economics Behind Ethereum’s Data Availability Layer
To understand how this works, it helps to separate the two layers involved when a rollup posts its data: the Consensus Layer and the Execution Layer.
1. Consensus Layer (CL)
Think of this as Ethereum’s data storage layer. When a rollup posts its data, it gets packed into “blobs.” Each blob is a 128 KB chunk of compressed rollup data. These blobs are stored by Ethereum’s consensus nodes for 18 days.
By keeping the data available to everyone, Ethereum makes it possible for anyone to independently verify a rollup’s state.
The cost of using this layer is set by the blob base fee, a special fee introduced by EIP-4844. This fee automatically adjusts depending on how full the blob space is, just like how Ethereum’s base gas fee adjusts based on block usage. When usage rises above the target, the blob base fee goes up; when it’s below, it goes down.
2. Execution Layer (EL)
Posting a blob isn’t done directly. Instead, the rollup sends a type-3 transaction to the Execution Layer. This transaction doesn’t carry the blob data itself, it’s more like a wrapper that references one or more blobs stored in the CL. These transactions are priced just like any normal Ethereum transaction
The key difference
The Consensus Layer counts how many blobs (data chunks) are being posted.
The Execution Layer counts how many transactions are sent to post those blobs.
This is why you see a gap between the two: roughly 11.7 million blobs have been posted to the CL so far, but only 4.9 million blob transactions have gone through the EL. On average, each blob transaction carries about 2.4 blobs, because rollups bundle multiple blobs together in one transaction to save gas.
Why Rollup Fee Mechanics are more complex
Once you introduce blobs and split data posting across the Consensus and Execution layers, the economics for rollups change fundamentally.
On Ethereum L1, there’s a single gas price that reflects all the costs involved in executing and storing a transaction. But for rollups, costs are spread across multiple layers and resources, each with its own pricing dynamics. This makes fee design more complicated, and sometimes, exploitable.
Multi-Dimensional Model
For every transaction, a rollup must recover three separate types of costs:
L2 Execution Costs – These are the resources spent running the transaction inside the rollup. They cover compute, storage, and bandwidth. For ZK rollups, they also include the cost of generating cryptographic proofs.
L1 Data Availability Costs – This is what the rollup pays to post the batch’s compressed transaction data to Ethereum as blobs. It ensures that anyone can later verify the rollup’s state.
L1 Settlement and Verification Costs – This is the onchain gas needed to commit batches and, for ZK rollups, to verify validity proofs on Ethereum.
A typical sequencer charges users a transaction fee that covers all three of these cost categories, while leaving some margin to stay profitable.
Most rollups use a first-price auction at the L2 level: users set an L2 gas price, and the sequencer fills the block by including the highest-bidding transactions first. It’s simple, but not always economically efficient.
The total transaction fee is usually calculated with a simple formula:
Total Transaction Fee = L2 Fee + L1 FeeL2 Fee = (L2 base fee + priority fee) × L2 gas used
Pays for off-chain execution, bandwidth, storage, and proof generation (for ZK rollups).
L1 Fee = (L1 blob base fee × blob scalar × data bytes) + commit cost + proof verification cost.
Pays for posting data to Ethereum blobs and the transaction’s share of batch commit and verification costs.
L1 DA Fee = L1 blob base fee × blob scalar × data bytesL1 blob base fee: Ethereum uses an EIP-1559-style mechanism for blob pricing. Target: 6 blobs per block (post-Pectra).
If more than 6 blobs are posted, blob fee increases slightly each block (exponentially, similar to base gas fee).
If fewer than 6 blobs are posted, blob fee decreases over time
Blob scalar: Adjusts blob costs based on how well data compresses, lower if data compresses efficiently, higher if it’s hard to compress (like spam).
Data bytes: Number of bytes the rollup needs to post for that batch or transaction.
Where Mispricing creeps in
This three-part fee model works in theory, but in practice, the pieces don’t sync up perfectly. Here is a fundamental mismatch.
L2 blocks are produced every 1-3 seconds, but L1 blob prices update every 12 seconds on Ethereum. Most rollups only refresh their internal blob pricing every 5-64 L1 blocks to avoid using unfinalized data.
But here’s the deeper issue: Rollup DA pricing is pegged to L1 blob fees, not L2 demand. When L2 gets congested, there’s no immediate price signal because DA costs are set by L1’s external blob market, while L2 blocks happen much faster than L1 can react. L2 gas fees track execution, not data usage.
This creates a window where attackers can flood the system before economics catch up.
Here is how attackers exploit this:
They craft transactions that are data-heavy but compute-light. The recipe is simple: execute only the STOP opcode (minimal computation, ~21,000 gas), pack the transaction with 128 KB of random, incompressible calldata, and use about 5.1 million gas to fill one full blob. The total stays under typical L2 block limits of 15M gas.
Why this works: L2 gas consumption stays low so base fees don’t spike, while L1 blob fees are externally priced and update slowly. Random data with only ~3% zeros compresses poorly, maximizing blob usage. Filling 3 blobs requires only ~15.3M gas—within normal limits and well below what would trigger meaningful fee increases.
There arises 3 possible attack vectors.
Attack 1. DA Saturation: Rollup-Level Denial of Service
Attackers monopolize the rollup’s limited blob capacity, preventing honest transactions from being included in batches posted to Ethereum.
Each rollup batch has a strict DA limit—typically 1-6 blobs depending on configuration. Ethereum targets 6 blobs per block (9 max) after Pectra, but most rollups use only 1-3 blobs per batch to manage costs. Attackers fill this quota faster than honest users by outbidding on priority fees.
Why it’s devastatingly cheap: When blob usage is below Ethereum’s target (common post-Pectra), blob base fees can drop to 1 wei per byte, essentially free. The paper shows periodic DoS costs under 2 ETH for 30 minutes on most rollups. But sustained DoS is even cheaper: 0.87 ETH per hour on Linea, 0.8 ETH/hour on Optimism (throttled), and 2.7 ETH/hour on Base (throttled), indefinitely.
Costs stay low because blob floor pricing makes data nearly free, there’s no L2 feedback loop reflecting DA congestion, and rollups sync blob prices infrequently. Eventually, blob usage exceeding Ethereum’s 6-blob target triggers 1.15× price increases per block, but by then the damage is done.
Real-world impact: Honest users must outbid attackers, which defeats the rollup’s “cheap fees” value proposition. Even short disruptions create opportunities for arbitrage interference, oracle manipulation, and delayed liquidations. For chains securing billions in TVL, this causes massive reputational damage.
Attack 2. Amplified Finality Delay Attack
By flooding the L2 with spam instead of attacking Ethereum directly, attackers can delay when transactions finalize by 1.45×–2.73× longer.
Why this works: Ethereum can handle 9 blobs per block, but most rollups only post 1-3 blobs at a time. When an attacker clogs these few blob slots, they create a massive bottleneck.
Think of it this way: a rollup might produce a new block every 2 seconds, but it can only post to Ethereum every 12 seconds. That’s 6 L2 blocks waiting for each L1 slot. Block one blob, and you’ve delayed 6 L2 blocks worth of transactions. Keep doing this, and the backlog compounds fast.
Real impact with 10 ETH budget:
The consequences are severe: bridges desync with cross-chain messages stuck in limbo, CEX withdrawals delay as exchanges wait for L1 finality, cross-rollup DeFi strategies break, and users are stuck with transactions “executed” on L2 but not finalized on L1 for hours.
Attack 3. Direct Economic Damage Attack
The Direct Economic Damage Attack exploits the lag between when rollups charge users and when they actually pay L1 blob fees.
Lock in cheap prices: The attacker sends DA-heavy transactions during a period when blob prices are low. Rollup users are charged this stale low rate.
Fee spike: Ethereum blob fees then increase rapidly. But the rollup’s pricing mechanism only updates periodically (e.g., every L1 block), so it continues charging users the outdated, cheaper fee.
Rollup pays the difference: When the rollup later posts its batch to L1, it must pay the higher actual blob price but has only collected the lower one from users. The rollup, not the attacker, eats the gap.
OP Stack DA DoS Vector
In late 2024, Conduit engineers discovered a critical DA spam vulnerability in OP Stack rollups (used by Optimism, Base, and others). While testing Base Sepolia Layer-3 networks, they found that an attacker could repeatedly send large, data-heavy transactions to fill the rollup’s limited blob capacity. By doing this over multiple Ethereum L1 blocks, the attacker could delay batch posting long enough to trigger a chain reorganization through OP Stack’s built-in security logic.
This delay opened a serious exploit path. An attacker could bridge funds into the rollup, spam the DA pipeline to force a reorg, then use a fast bridge to withdraw the same funds during the delay window. When the rollup reorganized, the original deposit was restored on the reverted chain, while the fast bridge withdrawal had already executed, effectively creating a double spend. Conduit reported the issue to OP Labs and Base, leading to DA throttling in op-stack v1.9.5 and a full fix in OP Batcher v1.15.0.
Mitigations Against DA Attacks
All three DA-related attacks, saturation, amplified finality delays, and direct economic damage, stem from the same issue: rollups peg their DA price to Ethereum’s blob base fee, which updates slowly and often remains near zero. This creates a cheap, predictable choke point for attackers. The solution is to combine short-term reactive defenses with structural pricing changes.
Short-Term Defenses: Filters and Multipliers
These are quick, reactive measures that rollups can implement immediately to limit spam:
Transaction size caps: Limit how much blob data a single transaction can consume. Oversized transactions are dropped or delayed, preventing one attacker from monopolizing blobspace.
Dynamic fee multipliers: Charge progressively higher fees as transactions fill more of a blob. This discourages cheap, high-volume spam that relies on a few large transactions.
Filtering low-efficiency traffic: Identify and deprioritize transactions with poor compression ratios or suspicious patterns, blocking compression-resistant junk data.
These tactics are easy to deploy, especially for single-sequencer rollups, but attackers can adapt to them. They buy time, not solve the core pricing lag.
Structural Fix: Local Blob Fee Market
The lasting solution is to make DA pricing responsive at the rollup level. Each rollup should maintain its own local blob base fee, updated every L2 block based on local usage.
If blob usage rises, the local fee increases immediately; if usage drops, it decreases, mirroring Ethereum’s EIP-1559 mechanism but at sub-second cadence.
A floor equal to Ethereum’s blob base fee ensures the rollup never underprices during L1 congestion.
This closes the delayed feedback loop that attackers exploit, forcing them to pay rising fees in real time instead of abusing 5–64 blocks of underpriced capacity.
My thoughts: After researching deeper into blob economics and attacks, I started looking for designs that offer long-term resilience. I came across two upcoming Ethereum upgrades that tackle this from different angles, one focuses on scaling blob capacity more flexibly, and the other keeps blob fees from collapsing to near-zero. Alongside these, Luban introduces an entirely new idea: a blob futures market, letting rollups lock in data capacity ahead of time instead of competing on the spot.
Exploring the Design Space for Long-Term Resilience
Mitigations can patch current vulnerabilities, but long-term resilience requires rethinking how rollups design their fee mechanisms and interact with Ethereum’s data layer. This involves exploring the broader design space
EIP-7892 — Blob Parameter-Only Hardforks
EIP-7892 introduces a lightweight type of hardfork that changes only Ethereum’s blob capacity settings, without touching other parts of the protocol. Specifically, it lets core developers update three key blob parameters more frequently and easily:
Target – how many blobs Ethereum aims for per block.
Max – the absolute cap of blobs per block.
Base Fee Update Fraction – how quickly blob prices adjust each block.
These values live in a shared “blob schedule” that both the execution layer and consensus layer follow, keeping the network aligned. Until now, changes to blob capacity could only happen during major network upgrades (big hardforks), which typically happen once or twice a year. But rollup demand for data grows much faster than that. With EIP-7892, Ethereum can:
Ship smaller, focused forks just to update blob parameters
React faster to real network demand
Start with conservative blob limits, observe mainnet performance, and scale up gradually
EIP-7918 — Introducing a Dynamic Blob Fee Floor
Ethereum introduced blob transactions with EIP-4844, creating a cheaper data lane for rollups. Blob fees follow an EIP-1559–style mechanism: when usage is low, the blob base fee can fall to 1 wei per byte. This is efficient during quiet periods, but it introduces a critical weakness, blob fees can become so cheap that they stop functioning as a real price signal. When demand spikes again, fees take many blocks to recover. In the meantime, rollups revert to Priority Gas Auctions (PGAs), leading to congestion, unpredictable fees, and exploitable pricing windows for attackers.
Priority Gas Auctions Mechanics
EIP-7918 introduces a dynamic fee floor that ties minimum blob fees to the execution base fee. This sets a reserve price below which blob fees cannot fall:
Reserve Price = BLOB_BASE_COST × execution_base_feeIf blob fees dip below this reserve price, the protocol stops lowering them, while still allowing fees to rise normally when demand increases. This ensures blob fees remain economically meaningful even during periods of low blob usage.
Key Parameters
GAS_PER_BLOB = 131,072 (128 KB per blob)
BLOB_BASE_COST = 8,192, exactly 1/16 of GAS_PER_BLOB
This means the minimum blob fee is always 1/16 of the execution gas cost per blob, ensuring pricing stays anchored to network conditions.
Example
Suppose the execution base fee is 16 gwei:
Floor = 8,192 × 16 gwei = 131,072 gwei ≈ 0.000131072 ETH per blobEven if blob usage collapses, blob fees won’t fall below this value.
By keeping blob fees from collapsing to near-zero, EIP-7918 raises the baseline cost of spamming blobspace, making DA saturation attacks more expensive and less predictable. Attackers can no longer exploit long periods of ultra-cheap blob pricing to flood rollups — the reserve price acts as a built-in economic defense.
Luban: Introducing Blob Futures on Ethereum
Blobs gave rollups a cheaper data lane on Ethereum, but the spot blob market is volatile. Rollups must buy blob space in real time, competing for inclusion against bigger players like Base or Taiko.
Luban changes this by introducing blob futures, a way for rollups to pre-purchase guaranteed blob capacity at fixed prices for future blocks, like booking bandwidth in advance.
Powered by Taiyi (built on restaking layers like EigenLayer and Symbiotic), validators or underwriters commit future blobspace. Rollups can lock in prices for upcoming slots, ensuring inclusion even if gas spikes later.
This creates a new DA market dynamic:
Rollups get predictable costs and guaranteed inclusion
Validators unlock new yield by selling blob futures
Underwriters market-make blob capacity, taking on volatility risk
A high-throughput OP Stack rollup, Rise Chain used Luban futures to secure stable blob capacity, smooth throughput, and avoid fee spikes — even with rotating sequencers.
Looking ahead, Luban aims for Pre-Settlement, letting rollups commit state updates before final settlement, making based rollups faster, more composable, and economically aligned with Ethereum.
Future upgrades
Full Danksharding is Ethereum’s long-term plan to massively scale data availability by increasing the number of blobs per block by orders of magnitude. Unlike proto-danksharding (EIP-4844), which introduces a small, fixed blob capacity, full danksharding will enable dozens or even hundreds of blobs per block.
This is made possible by data availability sampling (DAS), which lets nodes verify only small random portions of blob data instead of downloading everything, keeping verification lightweight even as total capacity explodes.
By making blob space abundant and cheap, full danksharding makes it far harder for attackers to monopolize data availability with fixed budgets, while giving rollups a huge, low-cost lane for publishing their data. This shift turns blobspace from a scarce resource into a high-throughput DA layer for the entire rollup ecosystem, setting the foundation for Ethereum to support thousands of rollups without overwhelming the network.
Conclusion
Ethereum’s DA layer is entering a new phase, one defined not just by cheaper data, but by smarter pricing, protocol agility, and market innovation. From fee floors to blob futures, the design space is expanding to make DA both economically robust and ready for rollup-scale growth.
Hazeflow is a blockchain & crypto research firm focused on underlying technologies, product approaches, and functions of blockchain products.
Written by Ishita Rastogi, edited by Pavel Paramonov.