
Interpreting Vitalik's New Article: Why Are Rollups That Fail to Efficiently Use Blob Space Trapped in a Development Dilemma?
TechFlow Selected TechFlow Selected

Interpreting Vitalik's New Article: Why Are Rollups That Fail to Efficiently Use Blob Space Trapped in a Development Dilemma?
After the Cancun upgrade, performance is usable, but Vitalik is deeply concerned about Rollup development.
Author: Haotian
How should we understand Vitalik Buterin's latest thoughts on Ethereum scalability? Some say Vitalik is endorsing Blob inscriptions—an absurd claim.
So how do Blob data packets work? Why hasn't Blob space been efficiently utilized post-Cancun upgrade? Is DAS (Data Availability Sampling) preparing the ground for sharding?
In my view, post-Cancun, performance is already sufficient. Vitalik is deeply concerned about the development of Rollups. Why? Let me explain my take:
1) As explained before, Blobs are temporary data packets decoupled from EVM calldata, directly accessible by the consensus layer. The key benefit: the EVM doesn’t need to read Blob data during transaction execution, thus avoiding high computational costs on the execution layer.
Currently, after balancing various factors, one Blob is 128 KB. A single batch sent to the mainnet can carry up to two Blobs. Ideally, an Ethereum block should eventually hold around 128 Blobs—about 16 MB.
Therefore, Rollup teams must balance the number of Blob blocks used, TPS capacity, and storage costs at the mainnet node level, aiming to use Blob space in the most cost-effective way possible.
Take Optimism as an example: currently processing about 500k transactions per day, batching transactions to the mainnet roughly every two minutes, carrying just one Blob each time. Why only one? Because their TPS doesn’t require more. They could carry two, but then neither Blob would be full, yet they’d still incur extra storage fees—unnecessary.
But what if Rollup off-chain transaction volume increases dramatically—say, to 50 million transactions per day?
1. Compress the transaction data within each batch, packing more transactions into each Blob;
2. Increase the number of Blobs per batch;
3. Reduce the interval between batches;
2) Due to gas limits and storage costs constraining the mainnet block’s data capacity, having 128 Blobs per block remains an ideal target. Currently, demand is far below that—Optimism uses only one Blob every two minutes. This leaves ample room for Layer2 projects to boost TPS, grow user bases, and expand ecosystems.
Thus, in the period following the Cancun upgrade, competition among Rollups over Blob quantity, frequency, and bidding for Blob space isn’t intense.
The reason Vitalik mentioned Blobscriptions is simply that such inscription activity temporarily spikes transaction volume and Blob demand, helping illustrate how Blob mechanics work. His real point wasn’t about inscriptions at all.
In theory, if a Layer2 project were to frequently submit large-volume batches to the mainnet, filling every Blob and willing to pay high costs for fraudulent batch submissions, it could disrupt other Layer2s’ normal Blob usage. But practically, like someone buying massive hash power to launch a 51% attack on Bitcoin, this is theoretically possible but lacks economic incentive.
Hence, Layer2 gas fees will likely remain low and stable for a long time—providing a golden window for Layer2 projects to scale up and strengthen their positions.
3) Now, suppose one day Layer2 activity becomes so vibrant that daily batches to the mainnet reach enormous volumes, and current Blob capacity proves insufficient. Ethereum already has a solution: Data Availability Sampling (DAS).
Simply put, instead of requiring one node to store all data, DAS distributes the load across multiple nodes. For instance, each node stores only 1/8 of the full Blob data, and eight nodes form a group to collectively ensure data availability—effectively multiplying Blob storage capacity by 8. This is essentially what full sharding will achieve in the future.
Vitalik has recently reiterated this idea with notable emphasis, almost as if warning Layer2 builders: stop complaining about expensive DA on Ethereum. Your current TPS doesn’t even come close to fully utilizing Blob capabilities. Focus on growing your ecosystems, expanding users and transaction volume—don’t keep chasing shortcuts like easy chain deployment or escaping DA responsibilities.
Later, Vitalik added that among core rollups today, only Arbitrum has reached Stage 1. Though projects like DeGate and Fuel have achieved Stage 2, they’re not yet widely recognized. Stage 2 represents the ultimate security goal for rollups. Very few rollups have reached Stage 1, while most remain at Stage 0—clearly showing Vitalik’s deep concerns about the state of rollup development.
4) In fact, purely from a scalability bottleneck perspective, there’s still significant headroom for improvement in Rollup-based Layer2 solutions.
1. Improve data compression to use Blob space more efficiently. OP-Rollups already have dedicated compressor modules for this. ZK-Rollups inherently compress data via SNARK/STARK proofs when submitting to the mainnet—this *is* compression.
2. Minimize Layer2 reliance on the mainnet, using fraud-proof mechanisms only in exceptional cases. For example, Plasma keeps most data off-chain, but deposits and withdrawals occur on the mainnet, allowing Ethereum to guarantee security.
This suggests Layer2s should tightly couple with the mainnet only for critical operations like deposits and withdrawals—reducing mainnet load while enhancing L2 performance. Ideas like parallel sequencer processing, pre-filtering and categorizing transactions off-chain, and Metis’ hybrid Rollup model—routing regular transactions via OP-Rollup and withdrawal requests through ZK paths—all reflect similar thinking.
To sum up,
Vitalik’s latest reflection on Ethereum’s future scalability path is highly insightful. His dissatisfaction with the current state of Layer2 development, his optimistic validation of Blob performance potential, his vision for future sharding technology, and even his earnest advice on optimization directions for Layer2s—all are thought-provoking.
Now, the only uncertainty left lies with Layer2 itself: how to accelerate growth?
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News











