> For the complete documentation index, see [llms.txt](https://spire-docs.gitbook.io/spire/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://spire-docs.gitbook.io/spire/da-builder/blob-aggregation.md).
# Blob Aggregation Conceptually
## Ethereum's limited blob space
Ethereum introduced blobs in the [Dencun hard fork](https://ethereum.org/en/roadmap/dencun/) with [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844). This created a [blob target per block](https://eips.ethereum.org/EIPS/eip-4844#throughput) 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.
Future Ethereum upgrades propose to increase the blob limit ([EIP-7691](https://eips.ethereum.org/EIPS/eip-7691)) but, even with full [Danksharding](https://ethereum.org/en/roadmap/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](https://eips.ethereum.org/EIPS/eip-4844#parameters)) 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](https://docs.espressosys.com/network/espresso-architecture/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer), [EigenDA](https://www.blog.eigenlayer.xyz/intro-to-eigenda-hyperscale-data-availability-for-rollups/), 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:
{% embed url="" %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://spire-docs.gitbook.io/spire/da-builder/blob-aggregation.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.