On the eve of Ethereum Cancun upgrade, get a comprehensive insight into the Blob market

Article: 0xEvan, Primev

Translated by: Franci, ETHconomics Research Space

Proofreading: Jason, ETHconomics Research Space

Translator’s Introduction

The previous articles we published were all related to the blob transaction itself and the 4844 fee mechanism. In this article, the author used data backtesting over the past year to simulate the potential of the blob market - how much data can it accommodate? Can it meet the data availability requirements of rollup?

In addition to the impact of the supply and demand curve of blob space on the blob market, the timing games of validators and the review of builders will also have some negative effects on this market. This article conducts data analysis on the possible blob transaction broadcast delay, demonstrates its impact on user experience and rollup data availability overhead, and also proposes a possible solution - pre-confirm blob transactions.

In general, this article is a relatively comprehensive analysis of the blob market. Readers can explore the future landscape of blob space through the context of the article.

text:

🙏Special thanks to @terencechain for the review, @BertKellerman for the insights, and @ethpandaops for the holesky testnet data.

TL;DR

Our research takes a deep dive into the emerging EIP-4844 blob market, which operates similarly to EIP-1559’s gas pricing. The difference is that it does not have a tipping mechanism directly for block builders to encourage them to package blob transactions, which may lead to an unstable blob transaction experience and certain challenges for them to be packaged into blocks.
We note that although blob transactions are large (~125 kB) and cheaper than calldata of the same size, they significantly increase the Ethereum block size. This also means that blob transactions bring incremental bidding power to blocks.
We demonstrated that the capacity of this new market can absorb the data needs of the current rollup and reduce the gas cost of standard block space by 15-20%, thus unlocking lower-cost mev opportunities.
We have observed that during periods of increased network activity, blob transactions can slow down block broadcasts by the order of hundreds of milliseconds, which can lead to censorship of block builders in order to maintain competitive bidding in mev-boost blob.
We evaluate that "pre-confirmed bids" can alleviate these challenges, and blob pre-confirmation can enhance the capabilities of EIP-4844, provide a better transaction experience for L2 users, and provide a stable transaction packaging experience for rollups.
We will conduct experiments on the Holesky testnet, collect block builder data, and set up relay through mev-commit. As a blob pre-confirmation provider, we invite relevant participants from PBS to conduct experiments together.

Introduction

EIP-4844 introduces a blob market, extending Ethereum's data availability. This emerging market uses a gas pricing mechanism similar to EIP-1559 to price and destroy the base gas fee of blobs. However, unlike type 2 transactions, there is no direct way for users in the blob market to bid to builders as a tip for packaging their blobs. The lack of a priority fee design makes it difficult to accurately price blob packaging fees. Additionally, blocks carrying blobs are expected to be broadcast more slowly across the network because blobs are the largest of Ethereum's transaction types. If a builder accepts many blobs in a block, they face a higher risk of block reorganization, so assuming the builder is an economically rational person, they may choose to review blobs during peak mev periods to keep Low latency for block construction.

We propose a blob-related block building and mev-boost data collection effort, as well as a blob pre-confirmation provider experiment using mev-commit, and invite rollups, relays, block builders and proposers in the community to participate . Our insights into blob-related behavior in EIP-4844 indicate that L1 blob pre-confirmation can enhance the utility brought by the blob market, provide a better transaction experience for L2 users, provide a reliable packaging experience for rollup in the presence of mev conditions, and Provide a more stable future for the rollup-centric Ethereum roadmap.

Understanding the Blob Market

Blob Transaction

EIP-4844 introduces a type3 transaction (also known as a blob transaction). Transactions carrying blobs are similar to regular transactions, but with the addition of blob data, KZG commitments, and proofs. Blobs are extremely large (~125 kB) compared to standard Ethereum transactions, and much cheaper than the equivalent amount of calldata. Calldata is priced at 16 gas per non-zero byte and can vary in size; blob data is priced at 1.04 gas per byte and is capped at 131,072 gas per blob.

Blob Gas Mechanism

Blob base gas pricing has a fee mechanism for pricing network congestion, similar to EIP-1559. The main difference is that the price of blob base gas is based on the change in blob usage, while EIP-1559 is based on the change in gas utilization of the previous block (the amount of gas used relative to the target gas amount). The number of Target Blobs is 3 (0.375 MB) and the maximum number of each block is 6 (0.75 MB). The minimum Blob base gas price is set to 1 wei.

When submitting a blob transaction, the sender will submit max_fee_per_blob_gas as the maximum price they are willing to pay for the blob base gas fee, all of which will be burned. max_fee_per_blob_gas is similar to max_fee_per_gas in type0 and type2 transactions. If users want to submit additional fees to incentivize packaging of their transactions, then they also submit max_priority_fee. However, max_priority_fee only covers the non-blob gas portion of the transaction. In other words, under this blob gas fee mechanism, users cannot directly submit blob packaging tips to the builder.

(Translator's note: Regarding the analysis of the principle of the 4844 fee mechanism, our community has written a more detailed article, please see here)

Blob Market Capacity

In this section, we backtest historical interaction activity on the rollup network from January 2023 to January 2024 to demonstrate the capacity of the blob market. We focus on the most active rollup transactions on Ethereum and use historical data to simulate a real-time blob market. Of course, this market is actively growing, and blobs are not yet online on the mainnet. This article uses historical data throughout 2023 to simulate its potential.

Based on the historical calldata activity of rollup and simulating its use in the block space of type3 transactions, we can see that the blob market price can easily absorb all the capacity of the rollup without causing the blob market price to exceed the blob base gas minimum value ( That is 1 wei).

Figure: base blob gas per block

Although rollup publishes more data to Ethereum, most blocks are still below the target blob number, which ensures that blob gas prices remain low.

Picture: The lighter the color, it means packaging The more times a block of a specific number of blobs is constructed

💡 This means that the calldata overhead of the blob market will be lower (calldata consumes 16 gas per byte, while blob consumes 1 gas per byte), and the gas price will also be lower (the gas price of calldata is gwei level, while blob The gas price is at the wei level), thus saving two additional layers of costs for rollup.

Not only can the blob market easily absorb the data availability needs of the current rollup, it can also enable the non-blob market to free up more block space and reduce gas overhead by more than 15-20%. The reduction in gas overhead in turn increases the bidding power of users/searchers, builders, and validators, and unlocks new mev opportunities that were previously priced out of EIP-4844.

Figure: EIP-4844 versus standard blocks Spatial impact (based on 2023 data)

Rollup requires more data availability

Rollup greatly affects the gas usage in the block. They are currently the largest type of gas user in the Ethereum block space. In 2023, rollup stored a record amount of transaction data on Ethereum, as shown in the figure below:

Picture: calldata saved on Ethereum record high

The daily average chart below shows that rollups are starting to occupy more than 15% of each block they are in, directly affecting the price of use for other users.

This may worsen in the event of a black swan and increased demand. As recently as December 2023, the inscription craze caused excessive transaction volume, causing Arbitrum's sequencer to be offline for about an hour. When the Arbitrum sequencer resumed operations and began publishing the backlog of saved state data, the sequencer immediately monopolized the entire block space, causing the gas price to soar to more than 140 gwei, consuming up to 90% of the gas in all blocks, making The network was unavailable to most users for several hours.

**In the next section, we will discuss how timing games and censorship may impact this market even in the absence of this surge in demand. **

Challenges Facing the Blob Market: Review

Blob Transaction Broadcast

EIP-4844 increases the bandwidth requirements per beacon block by up to ~0.75 MB, 42m gas, to accommodate up to 6 additional blobs per beacon block. Unlike calldata, which is stored permanently, blobs persist in beacon nodes for a short period of time (18 days as of February 2024) to keep the growth of the network's archived state under control.

Additionally, blob transactions have two network representations - a blob transaction for block builders and a blob sidecar for validators. Blob sidecars are designed for forward compatibility.

The blob must first be broadcast through the execution layer and then to the consensus layer. **This means that the builder (not the validator) has the final say on blob packaging. **Proposers can only exclude blob transactions under mev-boost dynamics based on invalid promises/proofs.

Figure: Execution verification is performed by the builder, Consensus verification is performed by validators

Block Builder’s Perspective

Recent research on validator “timing games” highlights how latency optimization can strategically enable node operators to maximize profits by delaying block proposals. The authors explain that this is detrimental to the health of the chain. Blob transactions further complicate this game by adding varying amounts of latency when the blob sidecar broadcasts.

Blob transactions are equivalent to the largest possible transaction size type. For this reason, blocks carrying these transactions propagate more slowly, making block builders less competitive in winning mev-boost bids. As a result, this incentivizes block builders to review blobs temporarily or even indefinitely so that they can submit mev bids with greater frequency.

The ethpanda team has been using Xatu to test real-world latency on the testnet. They set up observers in multiple locations around the world (NYC, FRA, BLR, SYD), using different Ethereum consensus clients (Prysm, Nimbus, Lodestar, and Lighthouse) to measure real-world latency. The February 20, 2024 Holesky Blob data snapshot shows that a large amount of latency is generated throughout the mev pipeline.

After a block builder wins a mev-boost bid auction, the proposer must wait for the blob sidecar to be broadcast before validating the blob packaged in the block. The table below shows that with a sample size of 800 blob sidecars, the minimum time for a single blob sidecar broadcast is approximately 400 milliseconds

Chart 1. Blob broadcast time vs. the number of blobs contained in a single slot

Figure: The small amount of data results in cost data One reason for some of the counterintuitive observations described in the set

The table below shows the difference in latency when waiting for more blob sidecars to arrive. The 50th percentile (p50) in the table shows that the difference in latency between a block carrying 2 blobs and a block carrying 6 blobs is about 225 milliseconds.

Chart 2. Time difference between the first arriving and last arriving blob sidecar out of the total number of blob sidecars based on block grouping

This kind of blob broadcast delay will give the block Builders introduce additional block reorganization risk when they fill their own blocks with blobs for little financial gain. Builders may choose to exclude/censor blob transactions to avoid potential reorganizations. If a block contains a large number of mevs, economically rational builders need to appropriately compensate for this risk through the rollup network.

About the user experience of package bidding in the Blob market

In this paper on the study of the validator time game, it is pointed out that later in the mev-boost bidding process, larger bids are associated with larger blocks. As the bid and gas price rise, a larger share of ETH will be destroyed in subsequent slots. If the base fee increases, but the mev withdrawal amount remains the same, the builder has less room to bid on the proposer's future income.

Translator’s Note:

(Value inflow: MEV + handling fee

Value outflow: destroyed ETH + Proposer’s PriorityFee + builder’s tip to Proposer + builder’s own income)

In other words, if more is destroyed, less will be given to the proposer.

In the expected blob market, capacity exceeds current demand. The destroyed blob base fee will remain on a very small order of magnitude, i.e. tens or hundreds of wei. It's critical for rollups to understand that their blob transactions may not be rolled even if sufficient base fees are paid. The low base fee of the blob market means that blob transactions require bids many times higher to incentivize builders to package such transactions. In this case, the blob transaction will have to be resubmitted at a higher fee, resulting in a poor user experience.

In addition, since the initial blob market under EIP-4844 does not have a package tipping mechanism (such as a blob priority gas fee), this further exacerbates the user experience problem because rollup cannot directly bid to compete for space in packaged blob transactions.

Let's look at a transaction example, assuming that the blob base gas fee is 10 wei, and calculate the blob overhead for the same amount of data. It should be noted that this example assumes that there is an effective package bidding mechanism that can bid for blob space.

💡Please see the sample transaction:

Calldata - 129,998 bytes (129429 nonzero bytes) ~ 2,094,140 gas used at 10.56 gwei (10.55 gwei base price + .01 gwei Priority Fee) = .022 ETH

Blob-128,000bytes~131,072gasusedat1gwei(10weibaseprice+.99999999gweipriorityfee)=0.000131072ETH

**Calculations concluded that if rollups used the blob market, they could potentially submit 100 times more bids due to the lower blob base fee, while also saving over 150 times the cost. **Lower blob baseFee will allow rollup to provide more competitive bids while saving overhead. Packaging fees need to be as competitive as existing mev opportunities in the block to compensate builders for potential restructuring risks, so even a bid 100x higher may not be enough. This is without blob pre-validation.

Implement blob pre-confirmation through mev-commit

In this time game, the main role of blob pre-confirmation is to make some pre-confirmed blobs available on the mev pipeline. With mev-commit, each pre-confirmation provider makes its own commitment to the transaction. Providers can then delegate this data to other actors (e.g. block builders, relayers, sequencers). Pre-confirmation data available to other participants in the MEV pipeline allows block builders to send matching execution loads in parallel. This concept can be exploited to create pre-confirmed blob packing lists, or for relays to collaborate on building type 3 block spaces.

Because preconfirmed blobs are known in advance, block builders can build future blocks carrying blobs before their slots begin. This practice provides the basis for pricing and lays the foundation for building a strong futures market. The market will provide rollups with a more reliable transaction packaging experience and make block space prices more stable. Additionally, mev-commit's pre-confirmed bidding provides a more reliable price discovery mechanism for rollups, as rollups can update their pre-confirmed bids in real time without resubmitting the entire blob transaction.

Finally, bundling blobs and using pre-confirmation bidding allows rollups to build alliances. Pre-confirmation bidding can be applied to bundled blob transactions or aggregated blobs, allowing rollups to share bidding capabilities and packaging space, helping to promote the stability and continued development of the Ethereum blob market.

in conclusion

Overall, our research shows that the economics of rollup are improving, while the emergence of new markets requires more factors to be considered, including the impact of time games and the lack of a tipping mechanism. It's too early to enter the solution phase for the issues we highlighted, but since mev-commit is already activated on the Holesky testnet, we can easily conduct experiments with PBS behavioral entities. Primev will collect data on the impact of blobs on block construction and proposer latency, and hopes to understand underlying behavioral patterns.

While economics and user experience are the main drivers for pre-confirmed Type 2 transactions, under EIP-4844, rollups and the rollup-centric transaction packaging experience, reliability and stability of the Ethereum ecosystem will become the key drivers for pre-confirmed blobs. important reason. We will also experiment with a blob pre-confirmation relay, which can leverage blob pre-confirmation and block builder coordination to improve blob sidecar broadcast latency issues on the Holesky testnet. We invite the community to participate in this experiment as it will provide potential solutions for the entire community.