Excessive Blob Fee Slippage: Long inclusion times averaging 730 seconds exacerbated large fee spreads, which we coin as blob slippage, significantly increasing costs for rollups.
Ineffective Blob Posting Strategies: Rollups employed various methods during the June 2024 congestion but failed to reduce blob inclusion times or mitigate fee slippage.
Network Instability and Builder Censorship: The network experienced a spike in instability due to increased reorg rates, with approximately 10% of a typical month's reorgs occurring within half a day. Builders censored blobs because they weren't adequately compensated for the higher reorg risks.
Blob Preconfirmation Experiment: We applied Blob Preconfirmations on mev-commit testnet and proved it as a method for faster, private bidding for blobs —offering a promising solution by reducing inclusion times, mitigating fee slippage, and fostering fee privacy through private blob mempools.
This research delves into the challenges faced by the blob market during the June 2024 congestion, focusing on factors that drove higher fees and prolonged inclusion times. Two major issues—blob slippage and nonce gaps—led to an inefficient blob market, and existing rollup strategies couldn't adequately address these problems to achieve lower inclusion times.
By conducting an in-depth analysis on the Holesky network, we propose preconfirmations as a solution to enhance blob transaction efficiency. We tested preconfirmations through mev-commit, a p2p platform that facilitiates real time exchange of preconfirmations bids. mev-commit is also strengthened by cryptographic commitments, enabling complete end to end privacy.
Our findings demonstrate that preconfirmations significantly improve inclusion times and create a more cost-effective environment for rollups. In addition to reducing fee slippage and inclusion times, this approach strengthens network stability and fosters innovation through private blob mempools.
On June 20, 2024, the blob market experienced severe congestion as a result of a surge in transactions from the Layer Zero airdrop on Arbitrum. Blocknative reported blob gas fees spiking to 8000 gwei, marking a staggering 1 trillion-fold increase from the 1 wei minimum. This resulted in ~166 of ETH overpayment as rollups were slow to switch from blobs to calldata.blob fee market spike before returning to a lower price
The maximum capacity of 30 blobs per minute was overwhelmed, causing an excess of over 100 pending blobs per block. This volatility caused the blob market to cease functioning, sending the average blob inclusion time to 730 seconds with a 5 block standard deviation of 184,000% (2049 seconds).
Despite rollups adopting different strategies, none were able to lower blob inclusion times or mitigate fee slippage. Arbitrum, in particular, faced significant difficulties in handling the large influx of traffic from the Layer Zero airdrop, though it managed to dynamically switch to calldata to cope with the situation.
In contrast, rollups without this capability incurred substantially higher fees until a manual switch to calldata could be made. For example, Blast paid 5.22 ETH for a single blob, and Linea ceased posting blobs entirely.
Amid the market volatility, block builders widely engaged in blob censorship. This is seen in the chart below, which shows that a significant number of blocks were built with zero blobs, even though the mempool contained many pending blobs. We are aware some block builders are trying to include blobs on a best effort basis, yet this social fallback is insufficient during times of high demand.
This behavior could be attributed to a lack of proper economic incentives, as builders were not compensated for the higher reorg risks associated with including blobs.
A blob reorg study conducted by Toni at the EF revealed that 92 reorgs occurred and 1,202 slots were missed per month. In particular the 6 blobs per slot were reorg rate for the month of January was .3%. During this intense blob congestion event, which spanned about 3,000 blocks, missed slots for 6 blob blocks surged to 1.05% and blob reorg rates spiked up to 7%.
The combination of increased reorg risk and a lack of economic compensation may have driven builders to censor blobs, further exacerbating the congestion and instability during this period.
Blob posting strategies currently face two major inefficiencies that impede faster transaction inclusion: fee slippage and nonce gaps.
Fee slippage: This refers to the difference between the fee when a transaction is submitted and the actual fee paid at the time of inclusion. Blob transactions are particularly prone to slippage due to fluctuating market conditions and delayed inclusion times.
Nonce gaps: Ethereum's mempool processes transactions sequentially, meaning transactions with lower nonces must be included before those with higher nonces. This can create bottlenecks, especially when a lower-nonce transaction has a lower fee, forcing higher-fee transactions to wait.
These inefficiencies disrupt the bidding process, making it difficult for rollups to secure optimal pricing and faster inclusion. As a result, transaction pricing and inclusion are adversely affected, leading to higher costs and delays.
Blob slippage refers to a form of multi-block fee slippage, occurring when there is a gap between the blob market price at the time of submission to the mempool and the price at which it is finally included in a confirmed block. This slippage reflects the fee difference between submission and confirmation, often driven by market fluctuations or block inclusion delays.
A positive slippage value means the blob fee was higher at confirmation than at submission, indicating that the rollup overpaid. During the blob congestion event, blob slippage was notably more pronounced than non-blob slippage, as demonstrated in the charts below.
The most “favorable” blob slippage seemed to occur at shorter inclusion times as seen by the negative values in the chart below. This is logical, as shorter mempool durations reduce the uncertainty around market pricing.
Blob transactions exhibited negative priority fee slippage, meaning the actual fees paid were lower than expected, benefiting rollups. In contrast, positive blob fee slippage, as shown in the chart below, reflects overpayment caused by delayed inclusion. Although builders can't capture blob slippage because the fees are burned, they still collect priority fees.
Negative priority fee slippage removes builders' incentive to prioritize these transactions for quicker inclusion, creating a misalignment between market pricing and faster transaction processing.
Geth's mempool enforces sequential nonces, meaning a transaction with a lower nonce must be included before one with a higher nonce, regardless of the priority fee amount. For rollups, this means that even if later transactions have higher fees, they remain pending until the earliest transaction is included. As a result, bids are limited by the strength of the lowest-nonce bid.
A negative nonce gap indicates that blobs were submitted in sequence, while a positive gap suggests that later nonces were submitted first. The chart below shows that all major rollups had nonce gaps within their submissions, explaining why transactions with higher priority fees weren’t getting included.
One issue with this is that if a rollup wants to speed up the inclusion time for multiple pending blobs, it must first resubmit all lower-nonce blobs with higher fees. During a volatile situation, this would test the limits of the public mempool by increasing the number of blob resubmissions needed to improve inclusion rates.
Preconfirmations directly address fee slippage by accelerating inclusion and minimizing delays, reducing costs for rollups and significantly enhancing network stability. By cutting slippage, preconfirmations give rollups a strategic edge, improving cost efficiency and competitiveness. Crucially, network stability is strengthened since only the blob inclusion fee (preconfirmation bid) needs updating, rather than resubmitting the entire blob transaction through the mempool.
However, even with preconfirmations, blob fee slippage remains an additional cost that rollups must manage effectively. The paper Efficient Rollup Batch Posting Strategy on Base Layer* highlights the importance of optimizing posting strategies to balance posting and delay costs. The paper Optimal Publishing Strategies on a Base Layer further generalizes these results to both zk and optimistic rollups, categorizing optimistic rollup cost functions as a homogeneous publishing cost with linear decay and zk rollup cost function as a constant publishing cost.
To assess the impact of preconfirmations on inclusion speed, we compared preconf acceptance times to standard mempool inclusion times. To test the effectiveness of preconfirmations under real-world conditions, we focused on blobs that were struggling to get included in a timely manner. We sent 6 blob transactions with un-competitive priority fee bids.
As shown in the chart below, approximately ~247,000 blobs were confirmed within 24 seconds, while ~15,000 took longer, with some exceeding 24 seconds. The chart below only shows blobs confirmed after 24 seconds.
Each preconf has a decayStartTimestamp
, marking the point when the bid begins to decrease in value, and once a builder accepts the bid, the dispatchTimestamp
is recorded on-chain, ensuring transparency and accountability in bid timing. Details about the bid decay mechanism here. We use the bid decay function to measure preconf bid acceptance latency, which is the time it takes for the builder to notify the bidder that the preconf has been accepted.
On average, preconf bid latency was just ~75ms—dramatically faster than the ~96 seconds (8 blocks) typically needed for inclusion through the public mempool. This represents a 1000x improvement.
This faster response time allows for more agile bidding strategies, particularly during high volatility or congestion when public mempool inclusion times can spike, allowing rollups to have more fine tuned control and more sophisticated blob posting strategies.
If the preconfirmation (preconf) bid is sufficiently high, it acts as a substitution for priority fee, seamlessly integrating into the block-building process. Our inclusion rate tests, as shown in the chart below, demonstrate that blobs submitted with only preconf bids achieve can reliably drive transaction inclusion.
Using mev-commit, rollups can send their blob transaction payloads directly to a builder, creating a private mempool. Using a private mempool has advantages for the rollup because it obfuscates the inclusion bid amount, bypasses the public mempool rules, which are unforgiving to blobs, and prevents more sophisticated rollups from front-running other rollups blobs.
Additionally, private blob mempools offer greater room for innovation than public mempools. Private mempools also allow for more innovation such as Titan’s custom blob pool that enables the sending of all permutations of blob transactions from a single sender, which allows partial blob inclusion and allows for multiple transactions with the same nonce.
This research underscores the transformative potential of preconfirmations in optimizing the blob market, particularly during periods of congestion. Preconfirmations drastically reduce blob inclusion times and mitigate fee slippage. This offers rollups a strategic advantage by securing optimal transaction pricing and faster inclusion. Additionally, the implementation of preconfirmations enhances network stability by reducing the need for costly public mempool resubmissions.
Furthermore, private blob mempools open new avenues for innovation, allowing rollups to bypass the rigid constraints of the public mempool, further improving transaction efficiency. The integration of strategies like Titan’s custom blob pool demonstrates the broader potential for optimizing blob transactions through private infrastructure.
As the Ethereum ecosystem continues to scale, preconfirmations will be critical in solving the bottlenecks that currently limit the blob market. Future work should explore refining preconfirmation pricing models, optimizing blob posting strategies, and deepening the integration of private blob mempools, ultimately contributing to a more efficient and resilient Ethereum network.