Blob Sharing On Ethereum: Making Blobs Cheaper And More Efficient With BlobFusion
In March 2024, Ethereum’s Dencun upgrade brought EIP-4844 to mainnet, which introduced blobs. Blobs are a new way to store ephemeral data onchain, which is much cheaper than the traditional way of using calldata. This change already reduced the cost for L2s by more than $74 million in the first month alone.
But there’s a big downside to them: You can only post full blobs.
The Problem with Blobs
Imagine you had 25 KB of data you wanted to post to the Ethereum network.
If you used blobs for this, you’d have to add 103KB of empty space to create a full blob of 128KB. Of course you'd pay for the unused space, too.
25KB isn’t an arbitrary value. Having a look at the Blobscan statistics, you can see that the average blob size is currently at ~25KB, which is about 20% of a full blob:
This means that on average, people are paying more than five times what they actually need for using blobs.
And the reverse is also true: on average, blobs are only 20% full. This means that 80% of the blobspace is wasted.
This is a big problem with how we're using blobs right now. Although it might not seem like a big deal with blob gas prices at 1 WEI, it will become more important once demand for blobspace increases (like we saw with blobscriptions).
Right now, this inefficiency mostly affects Layer 2s, and their solution to avoid paying too much is to wait until they fill a full blob.
When we look at Starknet's blob usage, for example, we see that they're posting blobs every 8 hours:
Arbitrum, on the other hand, doesn't post at regular intervals. Instead, they seem to post based on user activity on their network (the lows are at night when there's less activity):
Ideally, both networks would post transactions as soon as they were sent, to ensure great transaction finality and user experience. But it would currently mean increased cost because the blobs wouldn’t be full.
So there is a tradeoff for L2s between optimizing for high speed and low cost. But there is another way.
Merging Blobs To Save Costs And Optimize Blobspace Utilization
Instead of waiting until a blob is full (=optimizing for cost) or posting smaller blobs (=optimizing for speed), we can also share blobs with others to post them earlier (=perfect balance between speed and cost).
So instead of posting partially filled blobs...
...we can also post a blob that combines all of them.
Sharing blobs with others isn’t currently supported by Ethereum, but we’ve built a protocol that makes it possible.
Enter BlobFusion.
BlobFusion: Making Blobspace Affordable
An initial solution we built made it easy to send blobs to Ethereum. But with BlobFusion it becomes not only easy, but also cheap.
What is BlobFusion?
BlobFusion is an API and interface for sharing blobs with other people. Think of it as a kind of ridesharing service for blobs. Why drive alone in an empty car when there is room for four people, and you could also save money?
To use BlobFusion, you first send some funds to its smart contract. Those funds will later be used to send the blob to the network.
Once you’ve added the funds, you can create a new blob. You can do this either through the interface, or by sending it to the API. The blob you send has three parts:
- The data you want to include
- A bid
- The signature over the blob data.
Why do you need a bid and a signature?
The bid lets you say how much you’re willing to pay for this blob to get included. It gives you the flexibility to decide if you want to optimize for speed or cost.
If you choose a lower bid, you might have to wait a while to get included. If you choose a higher bid, you could get included sooner but pay more.
The signature is used to verify the origin of the data. When you normally post a blob, it is linked to a transaction. And each transaction is sent by someone. So when you send a normal blob, there is always a reference to the sender, which proves who sent it.
When you share blobs, this information is lost because there can only be one sender (the BlobFusion protocol). So each individual piece of data needs to be authenticated, which is what the signature is for. It basically says that this data was submitted by you alone.
With this info, we can fuse the blob you’ve submitted with other blobs.
How BlobFusion Works under The Hood
In its current state, BlobFusion has two main parts: the frontend, which we just used to submit a blob, and the backend. Let's take a look at how the different parts work together.
First, the user makes a deposit to a smart contract deployed on Arbitrum (Sepolia). The network event listener then waits for the appropriate Deposit event, and updates the balance or “credit” of the user, which they can then use to send blobs.
Once the user has a balance, they can create a new blob with their signature and bid. The blob gets saved to the mempool until it is included.
The server checks the mempool periodically to find an optimal blob. It submits a fused blob to the Ethereum network (currently Sepolia) when the following conditions are met:
- As much space as possible is filled with data
- Every partial blob’s bid is higher than its estimated cost
- The sum of all bids is higher than the total estimated cost.
Once it has found an optimal blob, it will fuse the partial blobs together and send them to the network. The fused blob contains the signatures, length of the data, and data of the submitted blobs.
But how exactly do you find this optimal blob, and what should the user pay for using BlobFusion?
How To Fuse Blobs – Or Solving An NP-Hard Problem
Fusing blobs together is an instance of the NP-hard bin packing problem, which is related to the knapsack problem.
NP-hard means that you can only find the optimal solution in exponential time. This means you’d have to try out all possible combinations before knowing the best solution.
Of course the blob merger doesn't need the optimal solution all the time. It needs to be fast enough to find a good solution. Fortunately, there are solutions that solve this problem in pseudo-polynomial time.1
As BlobFusion is currently only a prototype, we’ve opted for a simple greedy algorithm that is optimized for posting blobs as quickly as possible. Instead of trying to find the fullest blob, it tries to match bids and costs and sends the blob to the network once there is one possible solution – even if it isn’t the most optimal solution yet.
How To Price Blobs – The Nash Bargaining Problem
Intuitively, it makes sense that blobs should be priced based on the amount of space you’re using.
So if you occupy 25% of the blob, you should also pay for 25% of the blob. When submitting a small blob of 32KB, you’re only paying 25% of what you’d pay when submitting the blob directly. If you're sending a larger blob of 96KB, you'd only pay 75% (assuming the blob is completely filled).
While this is already a pareto-efficient solution (meaning there is no change in pricing that would improve the situation for one person without making others worse off), it isn’t the best solution.
In the paper EIP-4844 Economics and Rollup Strategies, Davide Crapis, Edward Felten, and Akaki Mamageishvili suggest a solution to this problem that is based on the Nash Bargaining Solution. Their solution meets the following criteria:
- Invariance of utility scaling (the solution should be the same regardless of how you measure utility)
- Pareto optimality (there's no other allocation that would be better for one user without making the other user worse off)
- Symmetry (when both users have the same space requirements, then they are treated the same)
- Independence of Irrelevant Alternatives (eliminating feasible alternatives doesn’t affect the result)
In practice, the intuition for this type of pricing is that the value from using BlobFusion is higher for users with smaller blobs than for users with bigger blobs. The additional cost of using blobs directly (i.e. without BlobFusion) is much lower for users with larger blobs, so it should be offset to make it cheaper for them to share blobs.
Prospect
This is just the beginning of merging, sharing and fusing blobs.
You can try sending your own blob at blobfusion.ephema.io, or check out the public repository on GitHub, which has extensive documentation on how to create your own instance of BlobFusion.
We are inviting L2s to experiment with BlobFusion and to reach out to us if this would be an interesting product for them.
You might also want to check out ephema’s Blob Creator for an easy way to send blobs to Ethereum directly from your browser.
Footnotes
Footnotes
-
Garey, M. R.; Johnson, D. S. (1979). Victor Klee (ed.). Computers and Intractability: A Guide to the Theory of NP-Completeness. A Series of Books in the Mathematical Sciences. San Francisco, Calif.: W. H. Freeman and Co. pp. x+338. ISBN 0-7167-1045-5. MR 0519066. ↩