Aggregating EIP-4844 blobs across rollups
EIP-4844 gave rollups a cheaper place to post data. Sharing blob space across rollups can push data-availability cost down further. Here is the idea and the constraints.
Data availability is the rollup bill
A rollup's dominant recurring cost is not execution. It is posting data back to Ethereum so anyone can reconstruct and verify L2 state. Before EIP-4844, rollups paid for that data as regular calldata, competing directly with every other transaction for the same block space.
EIP-4844 (proto-danksharding) introduced blobs. Large, cheap, temporary data packets carried alongside a transaction but priced in a separate blob-gas market. Rollups post their data as blobs, pay the blob fee instead of calldata prices, and the data is retained long enough for anyone to verify, then pruned.
Blobs come in fixed sizes
A blob is a fixed size, committed to with a KZG commitment, and there is a target and maximum number of blobs per block. That fixed granularity is the opening for optimization. A rollup that only half-fills a blob still pays for the whole thing, and blob space, like calldata before it, is a shared and finite resource.
When many rollups each post partially-filled blobs, the network is paying for empty space in aggregate. That is the inefficiency cross-rollup aggregation targets.
The aggregation idea, and its constraints
Cross-rollup blob aggregation asks whether multiple rollups can share blob space, packing several rollups' data into the same blobs, so the fixed cost of a blob is spread across more useful bytes and less is wasted on padding.
The constraints are what make it interesting research rather than a free lunch. Each rollup still needs to prove which bytes are theirs and reconstruct exactly their data, aggregation adds coordination and latency, and the trust and liveness assumptions of the aggregator have to not weaken the rollups relying on it. The win is real, but only if the data-availability guarantees each rollup depends on survive the sharing.
Common questions
- What is an EIP-4844 blob?
- A blob is a large, fixed-size, temporary data packet introduced by EIP-4844 (proto-danksharding). Rollups post their data as blobs priced in a separate blob-gas market, far cheaper than calldata, and the data is retained long enough to be verified before being pruned.
- Why does data availability dominate rollup cost?
- A rollup must publish enough data for anyone to reconstruct and verify L2 state. That publishing cost recurs for every batch and typically outweighs execution, which is why cheaper data availability, first blobs and then aggregation, matters so much.
- What does cross-rollup blob aggregation achieve?
- Blobs are a fixed size, so partially-filled blobs waste space. Aggregating several rollups' data into shared blobs spreads a blob's fixed cost across more useful bytes, reducing data-availability cost, provided each rollup can still prove and reconstruct its own data and the DA guarantees hold.
Working on something like this?
This is the layer we work in. If you have a hard problem underneath a product, tell us the hard part.