Skip to main content

​
Ethereum’s limited blob space

Ethereum introduced blobs in the Dencun hard fork↗ with EIP-4844↗. This created a blob target per block↗ of 3 and a maximum of 6 blobs per block. The chart below shows the history of blobs since the Dencun hard fork with the number of blobs per block ranging from none to a maximum of 6.
https://dune.com/queries/3522373/5923037↗
Taking the average of those values, the chart below shows that the target of 3 blobs per block is being consistently reached.
https://dune.com/queries/3757544/6319515↗
Future Ethereum upgrades propose to increase the blob limit (EIP-7691↗) but, even with full Danksharding↗, Ethereum blobs will remain inaccessible to all but the largest rollups and appchains.

​
The problem with one size for everyone

Let’s use Ethereum transactions as a starting point to show how a limitied resource, e.g. gas, can be maximally utilized by multiple participants. As long as an Ethereum block doesn’t exceed the maximum gas limit, more transactions can be added to the block. Even if the block contains a few very large transactions, if there is gas remaining in the block then additional transactions can be added.
Importantly, every transaction included in a block pays a price proportional to its usage of the gas in the block. If a large transaction uses 90% of the gas in a block, it will pay 90% of the gas fee, while a smaller transaction only using 1% of the gas will only pay 1% of the gas free — seems fair! So even if a block was 99% full, if a user sends a small transaction (e.g. a simple ETH transfer) then they could still be included. While Ethereum blobs employ a similar gas pricing mechanism to transactions, there are a lot fewer spaces available per block and blob pricing is per blob space available. Blob sizes are fixed (128 KB↗) and the cost of including a blob in a transaction is the same regardless of how much data is actually stored in it. A large rollup posting 10,000 transactions in a single blob could utilize the entire blob space, massively reducing their cost per transaction. In contrast, a small rollup or appchain would have to pay the same amount for their blob to be included, even if they only posted a single transaction in their blob — not a fair system!

​
How can appchains compete for blobs?

TLDR: They work together 🤝
Spire is building a future where any number of specialized appchains can run on Based Stack without having to compete directly with each other and other blob users for the limited resource of blob space. To achieve this, Spire is developing a blob aggregator to combine multiple blobs before posting to the Data Availablity layer (Ethereum L1, EspressoDA↗, EigenDA↗, etc.). This approach will ensure participation for all Based Stack appchains, enhancing scalability, reducing costs, and enabling greater integration across the ecosystem. To learn more, check out our post detailing a technical concept design of how appchains/rollups could opt in to using a blob aggregator service:
https://mintcdn.com/spire/BLVLXOQXhMRTJ8nz/images/Blob-Aggregation/blob-aggregation-card.webp?fit=max&auto=format&n=BLVLXOQXhMRTJ8nz&q=85&s=ec0ab5e8e62326902e1d64d347af46f2

Spire Blob Compression

Spire Labs