It has now been 8 months since the Ethereum network introduced blobs through the EIP-4844 upgrade. As anticipated, rollups are benefiting from significantly lower batch posting fees, allowing them to submit more transactions to Ethereum via the cost-efficient blob option.

However, the blob usage has been low as expected—there are still not enough rollups or decentralized applications (DApps) leveraging blobs. As a result, the blob gas base fee has remained at the minimum price of just 1 wei. Despite four periods of high blob demand, the overall cost remains exceptionally low. This makes Ethereum an attractive data availability (DA) layer for rollups, but it also raises concerns within the community about whether rollups are contributing enough to the mainnet. Moreover, Ethereum has been experiencing issuance inflation since the adoption of blobs, sparking debates over their impact.

Some argue that blobs enable Ethereum to scale and that more rollup services will eventually migrate to the network. Others contend that rollups, as of now, offer little to no contribution to Ethereum.

Beyond the price effects, discussions have emerged around the broader implications of blobs. One major topic is whether the minimum blob base fee should be adjusted, as proposed in EIP-7762. The outcome of this proposal remains uncertain. Another debate, captured in EIP-7691, centers around whether the number of blobs should be increased, with proponents asserting that this would not compromise consensus security. Both proposals are under consideration for the upcoming Pectra hard fork.

This article delves into the details of each proposal, exploring the background, the specifics of what has been proposed, and the potential advantages and disadvantages.

For those unfamiliar with blobs, we’ll first cover the basics. If you're already knowledgeable about EIP-4844 and blobs and are interested specifically in the proposals, feel free to skip ahead to the discussion on EIP-7762.

Let’s first dive into the exact concept of data availability, how EIP-4844 enhances Ethereum as a DA layer.

What is Data Availability(DA)?

Data availability is the property that ensures specific data can be accessed at a given point in time, particularly for the purpose of validating new blocks in blockchain networks. It focuses on the real-time access needed to validate new blocks and ensure consensus is reached. It guarantees that the data necessary for current block validation is available to all the participating nodes, enabling them to verify transactions before adding the block to the chain.

DA is often confused with data retrievability, which refers to the ability to access historical data. Retrievability involves retrieving past data, such as information from old blocks, typically for purposes like syncing new nodes or reviewing transaction history. However, retrievability does not impact the real-time validation required for block creation.

For example, the Ethereum blockchain ensures DA by making the necessary data for block validation available to nodes at the time a block is proposed. Even if Ethereum nodes do not provide all historical data to syncing nodes in certain cases, the consensus mechanism ensures that the required data was available during validation. If the data had been unavailable at that moment, the block would not have been added to the blockchain.

It’s also important to note that DA is not a binary property—it doesn’t simply mean “available” or “not available.” Instead, it exists on a continuous spectrum. Secure and decentralized blockchains like Ethereum provide strong DA, but variations in the degree of availability can occur based on factors such as the consensus mechanism and the level of decentralization.

Basics

Why does DA matter for rollups?

Data availability (DA) is vital for rollups because it ensures that transaction data can be accessed to verify state updates and reconstruct the rollup's current state. For optimistic rollups, DA is essential for constructing fraud proofs. If a false state transition is posted, users can rely on the transaction data stored in the DA layer to validate the transition and prove fraud. Without DA, users would have to trust rollup operators entirely, which could expose them to risks if operators act maliciously or withhold data.

For ZK rollups, DA ensures the existence of cryptographic proofs to validate state transitions without needing to post all transaction data. However, in practice, many ZK rollups still post transaction data to the DA layer to enhance transparency and facilitate easier verification by users.

Ethereum’s strong DA guarantees are why rollups use it as their DA layer. Prior to EIP-4844, rollups leveraged Ethereum's calldata field for DA. Now, they can utilize both blobs and calldata, improving scalability and efficiency for rollup implementations.

How does EIP-4844 enhance Ethereum’s DA functionality?

EIP-4844 introduces a new data structure called a blob, which, unlike calldata, is temporarily stored at the consensus layer for approximately 18 days before deletion. Ethereum validators allocate around 50GB for temporary blob storage. Blobs differ from calldata because they are not accessible by the Ethereum Virtual Machine (EVM); only their blob commitments are accessible, reducing the data footprint while still ensuring DA. Blobs offer efficient DA by providing only the essential functions needed for rollups, contributing to significantly reduced transaction fees.

Each blob is approximately 128 KiB, and a block can contain up to 6 blobs, totaling around 0.784 MiB per block. Blobs are added through a new transaction type called blob transactions, which, like legacy transactions, use at least 21,000 gas and can include 1 to 6 blobs.

Source : https://notes.ethereum.org/@vbuterin/proto_danksharding_faq

How is the blob priced currently?

Blobs are priced using a new unit called blob gas, where each blob consumes 2^{17 =} 131, 072 blob gas units.

Similar to Ethereum’s EIP-1559 gas fee mechanism, blob gas prices adjust dynamically based on blob congestion in recent blocks. The blob gas base fee B_blobgas,k+1 for the next block  k + 1 is calculated as follows:

B_{blobgas,k+1 =} B_blobgas,k x exp(u-t/8t)

where B_blobgas,k+1 represents the current base fee for blob gas in block ^k,

u denotes the total blob gas used in ^k,

and ^t is the target blob gas usage, set at 3 x 2¹⁷ blob gas units per block.

When a block is filled with the maximum of 6 blobs, the blob gas base fee may increase by approximately 12.5% in the following block. Currently, the minimum blob base fee is set at 1 wei, establishing the minimum fee per blob at 131, 072 wei.

Each blob transaction also includes the standard execution fee of 21,000 gas multiplied by the gas price. The minimum base fee of 1 wei is under active discussion, with EIP-7762 proposing an increase to better balance costs and data availability needs.

EIP-7762 : Increase minimum blob base fee

EIP-7762 proposes to increase the blob gas base fee (reserve a hotel much closer to the center) to make price discovery faster. What it attempts to change is only one parameter : MIN_BLOB_BASE_FEE. It proposes to change it from 1 wei to 2²⁵ wei. But what is the reasoning behind this proposal?

Is a minimum blob base fee of 1 wei problematic?

The issue isn’t that rollups contribute minimally to mainnet transactions or pay too little in fees. On the contrary, Ethereum’s goal—especially with EIP-4844—is to support scalable, low-cost rollup transactions.

Blob gas base fees have consistently remained at 1 wei since EIP-4844 was activated, with only a few brief surges when blob demand spiked. Ideally, if the base fee could stay at 1 wei indefinitely, this wouldn’t be a concern. What matters is that, during sudden demand bursts, the low starting point for blob base fees presents challenges in price discovery.

During these surges, the blob gas base fee’s gradual adjustment from 1 wei can be slow to align with actual demand. Let’s resemble a hypothetical scenario: imagine attending ETH Bangkok 2024, where you decide to stay at a remote hotel with almost-free groceries nearby. For day-to-day needs, this is ideal. However, when you need to attend an event at the conference center, it takes six hours to reach it in normal conditions. Add traffic and lack of direct routes, and the journey could stretch to 14 hours.

Similarly, when the minimum blob gas base fee is set at 1 wei, rollups benefit from inexpensive blobs when demand is low. But during a demand burst, the blob gas base fee’s upward adjustment is slow, leaving a prolonged price discovery period before a fair market rate is reached.

Moreover, the theoretical minimum time to reach an appropriate price may not hold in practice. If validators or block builders omit blob transactions from blocks, this discovery period could extend even further. For instance (from dataalways’s post), during the LayerZero airdrop on June 20th, the blob base fee rose from 1 wei to 7471 Gwei. Theoretically, this should have taken approximately 252 blocks or 51 minutes (calculated as follows):

log1.125 (7.471 x 1012) = 251.66

However, the actual time was around 6 hours—nearly 5–6 times longer than expected.

Extended price discovery periods mean the base fee fails to accurately reflect blob demand. This discrepancy can drive rollups and blob users to bid aggressively through priority fees, leading to an unpredictable and highly competitive fee market. In summary, a base fee set too low delays price discovery, misaligning fees with real-time demand.

What EIP-7762 proposes is like staying at a hotel closer to the convention center. While you might pay more for groceries nearby, being closer makes it faster and more convenient to reach the conference center when needed.

Wouldn’t rollup transactions be affected by a higher minimum blob base fee?

If the minimum blob base fee increases, rollups will indeed incur higher fees for submitting blob transactions. However, raising the minimum blob base fee from 1 wei to 2²⁵ wei does not imply that the rollups are paying 2²⁵ times the current fee for blob transactions. This is because blob transactions not only pay fees for blob gas, but also pay execution fees for blob transactions. Same as non blob transactions, blob transactions pay at least 21,000 gas. If they post calldata, the execution fee rises further.

Assuming a base gas fee of 5 Gwei, the execution fee for blob transactions would be (at least) approximately  21,000 x 109 = 2.1 x 1013 wei. By comparison, the minimum fee for a single blob is  131,072 = 1.3 x 105 wei, making the blob base fee trivial – about 1.6 x 108 = 160,000 times cheaper than the execution fee. Intuitively, a modest increase in the minimum blob base fee would not drastically impact the total cost of blob transactions.

For example, under EIP-7762’s proposed minimum blob base fee of 2²⁵ wei, the blob fee becomes  225 x 1.3 x 105 = 4.3 x 1012 wei. Thus, the total cost (Execution fee  + Blob fee) becomes 2.1 x 1013 + 4.3 x 1012 = 2.5 x 1013

This represents roughly a 20% increase from the current 1 wei minimum blob base fee. In cases where the block is filled with the maximum 6 blobs, the increase could reach around 120%.

The actual cost increase from EIP-7762 also depends on each rollup’s transaction strategy. Rollups vary in blob submission strategies: they use different blob counts per transaction, post varying amounts of calldata, and thus incur different execution fees. Rollups that post more complex proofs in calldata will pay higher execution fees, meaning the proposed increase in blob base fee will affect their overall transaction costs less significantly.

Data from historical simulations by dataalways indicates that for OP Stack-based rollups like Base, Optimism, and Blast, costs could increase up to 16% with the blob base fee at 2²⁵ wei. Other rollups, however, showed less than a 2% increase, suggesting a minimal impact on total blob transaction costs.

Source : dataalways.eth

Avoiding a sudden blob base fee spike

In addition to adjusting the MIN_BLOB_BASE_FEE, a small change was made to how excess blob gas is calculated. Previously, the calculation of excess_blob_gas could potentially lead to an undesirable spike in the blob base fee. To prevent this, the EIP introduces a modification that resets the excess blob gas at the fork height. This adjustment ensures smoother transitions around the fork event.

Discussion around EIP-7762

Since EIP-7762’s proposal, it has spurred considerable discussion. While researchers largely agree on the motivation behind this proposal and the need to address issues in price discovery, some concerns remain. One primary issue is the potential impact of frequent protocol adjustments on Ethereum's stability. Regular fine-tuning may introduce unforeseen complexities and risks.

Another concern centers on determining an appropriate minimum blob base fee. The arbitrary choice of 2²⁵ wei lacks a strong empirical basis, prompting calls for further investigation to ensure this value supports the protocol’s long-term goals. Establishing a robust rationale for this baseline fee is essential to avoid potential instability or unintended market distortions.

EIP-7691 : Blob throughput increase

EIP-7691 proposes a straightforward change: increasing the maximum number of blobs per block. Currently, the cap is 6 blobs per block, with a target of 3. EIP-7691 suggests that by raising this limit (no exact number for now), rollups could achieve greater scalability without compromising Ethereum’s consensus stability.

What challenges arise from increasing the blob count?

Raising the number of blobs per block could increase the total data size transmitted across the Ethereum peer-to-peer (p2p) network, potentially leading to delays in reaching consensus. Each blob contains 128 KiB of data, so 6 blobs add up to 784 KiB. With Ethereum’s maximum block size around 2 MB, the total data transmitted per slot, including blobs, could reach approximately 2.78 MB.

As the blob count increases, so does the data size, which extends the time required for blocks and blobs to propagate across nodes. This delay can challenge Ethereum’s consensus process, especially since validators must submit attestations within a 4-second window before each slot ends. Ensuring consensus stability, therefore, demands careful management of these propagation times.

Some may argue that because each blob is propagated via a separate channel, the increased blob count should not significantly affect consensus. However, nodes must still wait for all blobs and block data to arrive, meaning that a higher blob count could potentially result in longer wait times.

Empirical analyses following EIP-4844 (see post1, post2) reveal that the fork rate has increased post-implementation, and it rises with the blob count per block. The chart below illustrates reorg rates by blob count from April 6 to June 6, 2024. Blocks containing the maximum of 6 blobs show a significantly higher reorg rate than blocks with fewer than 4 blobs, sparking concerns about EIP-4844’s impact on Ethereum’s consensus security.

Is it safe to increase the number of blobs?

While reorgs can occur for multiple reasons, higher data loads across the p2p network are just one factor. Suboptimal client implementations may also contribute to reorg rates.

My initial analysis suggests that the data availability (DA) time, the duration nodes wait for the final blob to arrive, is minimal—averaging less than 20 ms, with a difference of less than 5 ms between blocks containing 0 blobs and those with 6 blobs. Given that nodes wait approximately 4000 ms before submitting attestations, this latency appears negligible and unlikely to critically affect consensus. Below chart shows the DA time estimated with blocks containing different numbers of blobs.

Furthermore, Toni’s analysis indicates that overall reorg rates have been declining since the implementation of EIP-4844. While earlier data showed a strong correlation between reorg rates and blob counts up until June, more recent data from the last three months reveals minimal differences in reorg rates across blocks with varying blob counts. These findings, attributed to ongoing improvements in Ethereum client performance, suggest that increasing the blob limit would not pose a significant risk to consensus stability.

Source: : ethresear.ch/t/steelmanning-a-blob-throughput-increase-for-pectra

How EIP-7623 support EIP-7691

Recently, Vitalik suggested, “I think we should revisit adding EIP-7623 and a small blob count increase (e.g., target 3 -> 4, max 6 -> 8) for PectraA.” To understand how EIP-7623 can facilitate this increase, let’s first examine its core proposal.  (See here for detailed explanation of EIP-7623)

About EIP-7623

EIP-7623 proposes to adjust the gas cost for calldata specifically for transactions that primarily serve data availability (DA) purposes. Essentially, transactions with low execution gas relative to their calldata size would incur a higher gas cost—potentially up to 3 times more—for calldata usage. Transactions that contain large calldata but perform minimal EVM execution would therefore see higher costs, encouraging the use of blobs over calldata for DA-related functions.

The rationale behind this adjustment is to minimize the impact on daily, non-DA user transactions while optimizing the DA framework. By increasing calldata costs for DA-specific transactions, EIP-7623 encourages data-heavy operations to transition from calldata to blobs, optimizing the network’s storage and DA efficiency. Additionally, this proposal aims to reduce the worst-case block size from 2.78 MB to approximately 1.2 MB, addressing the current gap where Ethereum’s average block size of around 125 KB could potentially reach a much larger limit.

EIP-7623 and EIP-7691

If EIP-7623 effectively reduces the maximum block size, it creates room for a higher blob count, supporting the goals of EIP-7691. Even with an increased number of blobs, the total data size remains manageable under worst-case conditions due to the reduced reliance on calldata for DA. This alignment between EIP-7623 and EIP-7691 allows for a greater blob throughput without increasing the maximum block size beyond sustainable limits.

Summary and Conclusion

This article has introduced recent EIPs focused on enhancing Ethereum’s blob functionality. EIP-7762 proposes raising the minimum blob base fee to enable faster price discovery during demand surges while minimizing the impact on overall blob transaction costs. EIP-7691 seeks to increase the blob count per block to further scale Ethereum’s data availability (DA) layer. With a higher blob count, the blob base fee would experience a more controlled increase during demand peaks, allowing for smoother price adjustments.

Detailed discussions are taking place around these proposed changes. For instance, debates include setting the target blob number to 4 and the maximum blob count to 6, as well as determining whether the base fee update rule should be symmetric or asymmetric. Additional considerations involve normalizing excess blob gas and adjusting the blob base fee update fraction.

Blobs are a recent addition to Ethereum’s ecosystem, and every change related to them is approached with caution due to their impact on both the application layer and consensus security. Nonetheless, Ethereum is rapidly advancing, with the research community working diligently to drive development and ensure the network continues to grow and evolve.