From Ethresearch This research was conducted in collaboration with @artificialquant 9, @projectHodl8 and @Alpinex_ 3.
TL;DR:
- Problem: Blob space is limited and underutilized.
- Solution: Combine multiple rollups’ blobs into one, effectively sharing the blob space.
Problem
New rollups are created every day, but not all are as widely used as Arbitrum, Base, and Optimism. Through data availability (DA), rollups make transaction data available to all network participants so they can independently verify it. The data is posted to a DA layer, such as Ethereum (or other DA chains, e.g. Celestia), either using calldata (costly) or blobs (cheaper). These rollups compete for a limited 128KB blob space (6 blobs per block now, increasing to 9 after the Pectra upgrade in March 2025). As demand for blob space grows, fees can rise exponentially.
Since number of blobs is limited, and each blob is paid in full, regardless of how much it is filled, it leads to a situation where smaller rollups (with empty blobs) pay the same as bigger rollups (with full blobs) for each blob tx. Consequently, the limited DA space is wasted and fees rise for all due to more blobs being included.
Following the @hyeonleee research Potential impact of blob sharing for rollups 9, we see that blob under utilization is not only an issue for smaller rollups but also for larger ones (though they are less affected) through increased blob fees.

rollup-blob-utilization552×808 68.1 KB
Solution
We propose to expand the block-building process with “blob building” support by combining multiple rollups’ blobs into one. This would allow rollups to share blob space, lowering their costs, improving blob efficiency, reducing network congestion, and making blob space more affordable for all.
The proposed solution builds on top of existing infrastructure and concepts such as MEV-boost and Flashbots bundles. It’s meant to be permissionless so anyone can start providing blob aggregation services. Safety against blob manipulation is ensured via cryptography.
Technical Details
The specs of proposed implementation is stack-agnostic and can be used even for non-rollup blob data.
We also introduce some new terminology:
- Blob shard: signed blob which is included in aggregated blob.
- Aggregated blob: group of blob shards, prefixed by a header.
- Blob Aggregator: service provider that collects blob shards, groups them into Aggregated blobs, and posts them via flashbots bundles.
- Shared Blob Registry: contract on the ETH mainnet to which the blob txs are posted. It contains blob shard validation logic and fee collection mechanism.
General flow

blob-sharing-flow2899×1379 150 KB
- Rollup generates blob shard and sends it to Blob Aggregator RPC.
- Blob Aggregator connects to multiple Blob Aggregator RPC streams to receive blob shards.
- Blob Aggregator combines blob shards into a single blob and sends it as a blob transaction that interacts with the Shared Blob Registry on the execution layer.
- Shared Blob Registry contract verifies blob shards, calculates fees, and rewards Blob Aggregator.
- Block builder includes the blob in the next L1 block.
Blob Shards
Each blob shard has a specific structure. The actual blob data is prefixed with a header before being included in the aggregated blob. This is done by the aggregator.
Chain ID
Signature (v, r, s)
Blob Data Length
|
|
| Blob Data
|
|
The header contains:
- Chain ID: blob source chain
- Signature: used to derive blob sender. Together with Chain ID it represents a tuple to uniquely identify to whom the blob shard belongs to.
- Blob Data Length: the number of blob data bytes in this shard.
Blob Aggregator RPC
Similar to how eth_sendBundle
is used by MEV searchers to send one or more transactions as a bundle, we propose extending this concept to blobs.
By using eth_sendBlob
, rollups can send their rollup blobs to the aggregator RPC, which will try to combine them into a single blob and post it to L1. The ordering of the blobs is determined similarly to transactions – by gas price per blob byte, and in cases of equal gas prices, by the time of submission.
The structure of the blob bundle request is (encoded in JSON):
Blob Shard: {
Chain ID
Gas Price Per Byte
Block Deadline
Nonce
Blob Data Hash
Blob Data Length
}
Signature
Blob Data
The Blob Shard struct provides metadata for a given blob shard, allowing it to be uniquely identified, preventing double posting, and calculating fees based on the per-shard utilization of available blob space. The proposed structure does not restrict or tie users to a specific blob data layout within their shards. This makes it possible for users to optimize their blob data structure for their specific use cases.
The Signature field ties a blob shard to a specific user, ensuring the request has not been tampered with. It’s also used as an on-chain authentication mechanism to charge fees for the blob and making sure the aggregator takes no more than the amount of fees paid by the blob shard.
Block Deadline serves a similar purpose as the target block parameter in flashbots bundles. This ensures that a shard can be included up to the deadline block. Shards included in blobs that land later than the block deadline are invalid. This makes the blob shard inclusion more predictable and simplifies fallback mechanisms of e.g. rollup batches where they can then post the blob tx themselves.
Blob Aggregator
Blob Aggregator is responsible for gathering blob shards from different users, combining them into a single blob, and submitting it to DA layer to the Blob Shard Registry, preferably in a flashbots bundle that reverts if the TX fails. The aggregator is a permissionless entity that anyone can run.
They are incentivized to run their service by taking a small fee on the realized blob cost savings of each shard. Thus, their goal is to fill the blob with as much data as possible.
The aggregated blob layout contains a blob header, followed by a blob body which includes the shards. The layout of the body can vary across aggregated blob versions (stored in header), and can even be additionally compressed.
The header additionally contains a lookup table to speed up processing by the shard senders, with the following layout: chain ID → shard sender → [shard1 idx, shard2 idx, …]. This makes it possible to jump straight to the start of blob shard data of specific shard sender, without having to process bytes one by one. The lookup table could potentially be moved from the blob header to Blob Shard Registry contract calldata or even emitted via events, but that’s TBD.
Full aggregated blob structure:
Aggregation Version
Blob Compression
Lookup Table
| Blob Shard 1
| Blob Shard 2
| Blob Shard 3
| ...
| Blob Shard N
Once the blob is aggregated, the aggregator prepares the blob tx which calls the recordSharedBlob()
function on the SharedBlobRegistry
contract to register the blob and correctly collect fees and rewards.
Shared Blob Registry
Shared Blob Registry is a contract responsible for verifying blob shards and compensating the blob aggregator for their service.
We propose the following structure for the Shared Blob Registry contract:
/**
* @title Shared Blob Registry
* @notice Manages storage, verification, and correct handling of blob shards used in a given blob.
* Guarantees correct fee payments by blob posters and fair rewards for blob shard aggregators.
*/
interface SharedBlobRegistry {
/**
* @notice Blob shard struct, storing the blob metadata information.
*
* @param chainId ID of the chain that the shard belongs to.
* @param gasPricePerByte Expected gas price per used byte for the shard. Used to calculate fees based on the utilized blob space.
* @param blockDeadline Block number up to which the shard remains valid.
* @param nonce Nonce of the (blobPoster, shard) pair, used to prevent replay attacks.
* @param dataHash Hash of the shard data.
* @param dataLength Length of the shard data.
*/
struct BlobShard {
uint256 chainId;
uint256 gasPricePerByte;
uint256 blockDeadline;
uint256 nonce;
bytes32 dataHash;
uint256 dataLength;
}
/**
* @notice Deposit collateral to cover blob fees.
*/
function depositFeeCollateral(uint256 amount) external;
/**
* @notice Withdraw collateral to cover blob fees.
*
* @dev If @param amount > balance, the full balance is withdrawn.
*/
function withdrawFeeCollateral(uint256 amount) external;
/**
* @notice Record a shared blob composed of multiple shards.
*
* @param shards Blob shards to be recorded.
* @param signatures Signatures verifying the blob shards.
*
* @dev This function performs the following steps:
* 1. Verify the signatures for the BlobShards and identify the blob poster address.
* 2. Calculate the space utilization ratio for each rollup.
* 3. Determine the unused blob space and charge rollups accordingly, including execution transaction base gas fees.
* 4. Calculate savings for each rollup.
* 5. Collect fees, distribute portion of savings, and persist the blob shards.
*
* @dev Shard nonce should be used only once. Must be incrementally consumed.
*/
function recordSharedBlob(BlobShard[] memory shards, bytes[] memory signatures) external;
/**
* @notice Validate a blob shard by verifying its signature, identifying the blob poster address, and ensuring sufficient collateral to cover fees.
*
* @param shard Bob shard to validate.
* @param signature Signature verifying the blob shard.
*
* @return isValid True if the shard is valid; otherwise, false.
* @return blobPosterAddress The blob poster address responsible for paying the shard fees.
*
* @dev Use tryRecover from @openzeppelin/contracts/utils/cryptography/ECDSA.sol because it has additional security checks.
*/
function verifyBlobShard(BlobShard memory shard, bytes memory signature) external view returns (bool, address);
/**
* @notice Get the blob shards for a given block number and chain ID.
*/
function getBlobShards(uint256 blockNumber, uint256 chainId) external view returns (BlobShard[] memory);
/**
* @notice Get the next nonce for a given blobPoster and chain ID.
*/
function nextNonce(address blobPoster, uint256 chainId) external view returns (uint256);
}
Advantages
- Cost Savings: Users can share blob space, lowering costs and making it more affordable for everyone.
- Improved Efficiency: Blob space is utilized more effectively, reducing network overhead.
- Faster Finality: Rollups can post blobs more frequently, shortening the time to finality.
Open Questions
- Incentives: Should each rollups decide the percentage of savings to share with the Blob Aggregator? Or should the Blob Aggregator set the service fee? Alternatively, should the fee be determined by the Shared Blob Registry contract? The best approach is still unclear, as each option has its own advantages and disadvantages.
- Blob Shard Collision: What if blob A contains blob shards 1, 2, 3, and blob B contains blob shards 2, 4, 5, and blob A is successfully posted on-chain? Should blob B still be submitted on-chain, or should it be discarded? Could this cause indefinite delays in blob shard submission since blob shard 2 also impacts blob shards 4 and 5?
- Potential Exploit: Currently, there is no guarantee that the Blob Aggregator actually includes the blob shard in the blob, as the execution client cannot read detailed data about blob contents. How can we ensure that the Blob Aggregator is honest and does not submit empty blobs while still collecting rewards? One possible solution is to rely on the Blob Aggregator’s reputation and incentives, such as future blob aggregation rewards, to discourage such behavior. Another alternative is to use restaking mechanisms. A third option would be to implement Blob Shard support directly into Ethereum, potentially as a new transaction type.
Conclusion
The proposed Blob Sharing concept aims to enhance rollup efficiency by allowing them to share blob space. This approach is expected to lower costs for rollups, improve blob space utilization, and make it more affordable. It also provides an opportunity for Blob Aggregators to experiment with blob shard composition and prepare to evolve into Based Sequencers.
Other Resources
Feedback Invitation
This proposal is meant to gather feedback from other community members before diving into development. We invite everyone to share their thoughts, suggestions, and potential concerns to refine and improve this concept.
All Comments