Title: EIP_7918__Blob_base_fee_bounded_by_execution_cost
Category: EIPs

Author: aelowsson
Date: 2025-03-26T08:29:45.340Z

Discussion topic for EIP-7918; PR.
Relevant background on the current auction design (Data Always, Wahrstätter, Crapis).
Abstract
This EIP imposes that the price of the targeted number blobs TARGET_BLOB_GAS_PER_BLOCK * base_fee_per_blob_gas stays above the price of a simple blob-carrying transaction TX_BASE_COST * base_fee_per_gas. This ensures that the blob fee auction can function properly, because the equilibrium always forms relative to the fee that carries the price signal. The proposed if statement to check fee parity in calc_excess_blob_gas() represents a neutral, simple, and future-proof resolution to current blob fee auction idiosyncrasies.
Motivation
Ethereum deploys a dynamic pricing auction to set the blob base fee, lowering the fee if less gas is consumed than TARGET_BLOB_GAS_PER_BLOCK and raising the fee if more gas is consumed. Such an auction can function well when the blob base fee represents the price signal, allowing the mechanism to control the real price facing the consumer. However, when the cost of execution gas in the blob-carrying transaction dominates, the price signal is lost. The blob base fee no longer represents the actual cost facing the consumer, and the protocol cannot adjust the blob base fee to regulate the equilibrium quantity of blobs consumed. Under these circumstances, the current mechanism will continue lowering the blob base fee until it eventually settles at 1 wei. Whenever demand picks up, a sustained succession of near-full blocks is required to restore equilibrium, with the mechanism intermittently resorting to a first-price auction, considered a worse UX by blob consumers. The resulting spikiness in resource consumption is suboptimal for scaling blobspace.
Figure 1 shows how execution costs make the demand curve inelastic, such that a small shift in demand or execution base fee (arrows) can lead to dramatic shifts in the equilibrium blob base fee. To alleviate this, the proposal imposes that the equilibrium (squares) must form under at least fee parity between blob data costs and execution costs, somewhere along the edge of the upper-left quadrant, bounded by the supply curve (blue) and the fee parity line (dashed). This ensures that an equilibrium always forms relative to the fee that carries the price signal, thus alleviating spikiness while remaining neutral and future-proof. To achieve this, a simple if statement is added to the excess gas update function.
Figure 12617×1816 397 KB
Figure 1. The demand for blobspace under different execution base fees (black to red lines). When execution cost dominates, the demand curve becomes inelastic and parallel to the supply curve, leading the equilibrium fee to change dramatically even with small shifts in the demand curve (arrows). The proposal imposes that the equilibrium (square) forms on the edges of the upper-left quadrant, at the intersection between supply and demand or fee parity and demand.
Specification
The function calc_excess_blob_gas() from EIP-4844 is changed to add parent.blob_gas_used // 3 and not subtract TARGET_BLOB_GAS_PER_BLOCK when updating the excess_blob_gas, if the price of TARGET_BLOB_GAS_PER_BLOCK is below the price of TX_BASE_COST.
def calc_excess_blob_gas(parent: Header) -> int:
    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0

    if TX_BASE_COST * parent.base_fee_per_gas > TARGET_BLOB_GAS_PER_BLOCK * get_base_fee_per_blob_gas(parent):
        return parent.excess_blob_gas + parent.blob_gas_used // 3
    else:
        return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK

Rationale
Fee-inelasticity
This proposal alleviates idiosyncrasies in the blob base fee auction. Fundamentally, the issue is that the demand curve becomes fee-inelastic as the cost of blob data falls relative to the cost of the blob-carrying transaction. When the execution cost dominates, it does not matter to the blob consumer how the blob fee evolves—it is ultimately the execution cost that determines equilibrium formation. Given that the protocol stipulates a long-run perfectly inelastic supply curve (vertical blue line in Figure 1), the blob base fee will simply fall to the boundary of 1 wei whenever the execution cost is too high for equilibrium formation at TARGET_BLOB_GAS_PER_BLOCK. Thus, in the regime where execution fees dominate, the demand curve is blob fee-inelastic, and whenever the blob fees dominate, the demand curve is execution fee-inelastic. Figure 1 maps the quantity of blobs demanded Q to the blob base fee b and the execution cost c:
        Q(b + c)
The execution cost c is expressed “per blob gas” to match b, which is a fee taken out per blob gas. Thus, c is computed as:
c = TX_BASE_COST * base_fee_per_gas / (GAS_PER_BLOB * N)

Here, N is the number of blobs over which the consumer amortizes its execution cost (set to the target in this proposal). The auction adjusts b to achieve a desirable Q at equilibrium. However, if c > 0, every demand curve will have an “inelasticity horizon” (see Figure 1), beyond which further reductions in b cannot increase Q, rendering such fee reductions redundant:
        lim b→0: Q(b + c) = Q(c).
This proposal ensures that the auction stops reducing b before reaching this horizon, specifically at fee parity b = c. Thus, an equilibrium always forms relative to the fee that carries the price signal, alleviating spikiness in resource consumption. When the price signal comes from the execution fee, equilibrium forms along the fee parity line in Figure 1, and when the price signal comes from the blob fee, the equilibrium forms along the supply curve.
The demand curve could potentially be somewhat inelastic even under zero execution costs. This would however just be another reason to move forward with this proposal. Regardless of the exact shape of the demand curve—which of course will remain unknown and can vary going forward—the proposal is based on something tangible and measurable. The execution cost must contribute to inelasticity, and this inelasticity can be modeled. This makes it a justified neutral bound on the blob base fee.
Designing for the future
Figure 2 once again shows the permitted (green) and restricted (red) regions also captured in Figure 1, but this time with execution base fee on the x-axis. Various settings for fee parity are indicated by black lines. When fee parity is imposed based on a transaction carrying many blobs (e.g., 48), its total cost will be relatively higher, and the blob base fee will as a result be operational at a relatively lower level. Such a shift is inherent by design and as intended. If blob consumers include many more blobs in their blob-carrying transactions, the execution gas may no longer carry the price signal at the same blob base fee, and the blob base fee should be able to settle relatively lower. This is also why fixed thresholds not relating to blob quantity or the execution fee may not be sustainable. In a scenario where Ethereum provides many orders of magnitude more blobs, the equilibrium blob base fee should ideally have a relatively lower floor. To understand why potential future blob scaling is important to account for when designing the mechanism, consider how the price of storing a fixed amount of data has fallen over the last 80 years.
However, as Ethereum scales, the number of blobs submitted in the average blob-carrying transaction, as a proportion of the BLOBS_PER_BLOCK_TARGET, will fall. Similarly, the number of blocks where BLOBS_PER_BLOCK_TARGET is submitted in a single blob-carrying transaction will also fall. The mechanism can be designed to account for this. A natural idea is to impose fee parity between execution costs and the square root of the target number of blobs. If the target is 49 blobs per block, then fee parity is set to the cost of 7 blobs, etc. This means that the if statement would be altered by replacing TARGET_BLOB_GAS_PER_BLOCK with integer_squareroot(BLOBS_PER_BLOCK_TARGET * GAS_PER_BLOB**2). Note that if blob-carrying transactions become restricted from including BLOBS_PER_BLOCK_TARGET, this should be accounted for.
Figure 22658×1816 453 KB
Figure 2. Proposed restriction imposed on the blob base fee to ensure desirable equilibrium formation. When the blob fee is the primary price signal (green area), equilibrium can form just as today. When the execution fee is the primary price signal (red area), the demand curve becomes too inelastic, and the blob base fee is imposed to rise to the green area. Black lines indicate fee parity between blob data cost and execution costs.
Delayed response during a quick rise in execution fees
When the if statement concludes that Ethereum operates in the execution-fee-led pricing regime, the blob base fee rises in accordance with blob_gas_used // 3, without subtracting TARGET_BLOB_GAS_PER_BLOCK. This is an intuitive way to return to the blob-fee-led pricing regime, retaining the same maximum fee increase while not allowing for a decrease. If the execution base fee rises quickly, there may be a few blocks before the blob base fee catches up (during which TARGET_BLOB_GAS_PER_BLOCK will never be subtracted and the blob fee moves in the direction of the arrows in Figure 2). This is arguably not an issue, and the smooth response in the blob base fee under these circumstances may even be seen as a benefit.
…review the EIP for further details.

Author: sbacha
Date: 2025-03-28T04:12:25.683Z

please dont post AI slop on here we are better than that

Author: dataalways
Date: 2025-03-28T17:50:12.826Z

Thank you for the proposal. I like the idea and definitely think we should explore the solution space. I have a few question:


This seems to be moving towards recoupling the two fee markets, is that something that we want? Like the two are already often entangled because demand drivers on one layer tend to drive demand on the others as well (i.e., price volatility driving more defi usage), but do we want to explicitly increase the entanglement?


If we’re tying the two markets together, why did you choose this value? Does it make sense to tie the price to additional liveness risk of including blobs instead?


The main blocker for EIP-7762 was a desire not to tinker with the blob fee market and not to add more complexity to Pectra. This seems more complicated than 7762 and the benefits over 7762 aren’t that clear to me. If in the long-term we want to have blob capacity > demand to keep price stability but then charge L2s a small amount, then wouldn’t it be better to have a fixed base fee that is easier to justify tuning?


I’m curious to the historical empirical impact of this proposal. How often would it have been a major contributor v.s. being overshadowed by blob fees?

Author: aelowsson
Date: 2025-04-01T12:52:43.643Z

dataalways:

Thank you for the proposal. I like the idea and definitely think we should explore the solution space. I have a few question:


Thanks for your question and your analytical work on blob base fees, which has been very valuable.
Question 1: Coupling of fee markets



 dataalways:

This seems to be moving towards recoupling the two fee markets, is that something that we want? Like the two are already often entangled because demand drivers on one layer tend to drive demand on the others as well (i.e., price volatility driving more defi usage), but do we want to explicitly increase the entanglement?


The price of blobspace depends on the price of execution gas, and this should be reflected in the fee market. Currently, the mechanism behaves as follows:

Users purchase blobspace by spending execution gas and blob gas.
The blob gas fee update mechanism is unaware of the cost of execution gas, and thus unaware of the cost of blobspace.
A relatively high cost of execution gas renders changes to the blob gas fee subordinate in determining quantity demanded.
The mechanism fails to timely converge on equilibrium whenever the cost of execution gas dominates the cost of blob gas.

In essence, the mechanism behaves as if it controlled the price of blobspace when it only controls the price of blob gas. EIP-7918 resolves this by adjusting the auction mechanism when the cost of execution gas dominates. The two fee markets still remain fully independent in the operational range where the blob base fee carries the price signal.
Question 2: Alternative designs



 dataalways:

If we’re tying the two markets together, why did you choose this value? Does it make sense to tie the price to additional liveness risk of including blobs instead?


I am not sure what exact value you are referring to? A nice thing about this proposal is its minimalist nature. Fee parity and amortization across target blobs was the most neutral condition I could think of. The only other option I considered was amortization across max blobs instead of target blobs. I think both options are perfectly valid but favored target blobs for two reasons:

It represents the equilibrium condition and can thus be perceived as slightly more neutral.
It results in a slightly higher fee parity threshold, both in terms of its nominal level (see Figure 1 below) and the relative level that more execution-gas-intensive blob consumers operate on. Concerning the relative level, we can focus on the bump centered at around 126k in your informative analysis of execution gas used by block submitters. A gas-intensive L2 submitting a single blob would uses (6/1) × (21k/126k) = 36 times more execution gas than blob gas under Pectra settings before the bound on blob gas activates. With amortization across max blobs, the outcome is (9/1) × (21k/126k) = 54.

Concerning tying the price to liveness risk, I suppose it can make sense, but it is not something I have explored.
I have considered one other option, which I call a composite fee market. This would however be a much bigger change, also conceptually. It is not something we should be pursuing right now and would have to be part of a potential future harmonization of fee markets. The design can however be informative also for understanding EIP-7918, and it is therefore described briefly below.
Composite fee market
The composite fee market updates the blob base fee based on the real demand function for blobspace, as previously specified in EIP-7918:
        Q(b + c).
In this equation, the long-run average per-block quantity of blobs demanded Q depends on the blob base fee b and the tx cost c, expressed per blob gas as specified in the EIP. The real demand function will reflect variations in blob submission strategies, but the same estimate for c as in EIP-7918 could potentially be used. Other options are to simply compute c for every block or to specify c as the long-run average.
Let q represent the desired fractional shift in the cost of blobspace, e.g., in the range [-0.125, 0.125], computed from the realized Q of the block and the target quantity for a block. Further, let c₀ define the tx cost of the previous slot, computed according to one of the options of the previous paragraph and expressed per blob gas. The composite fee auction then updates from b₀ to b₁ by accounting for c₀:
        b₁ = b₀ + q(b₀ + c₀)
To the user that employs the same execution gas per blob gas as in c₀, the maximal change in cost of blobspace per slot would still be 12.5%. The proportional change in b can however be dramatic whenever b << c. This is as intended, allowing the composite fee auction to quickly converge on equilibrium, no longer “getting stuck” at lower blob base fees.
As a general comment: to devise a sound fee market, it is important to model the real demand function.
Question 3: Comparison with EIP-7762



 dataalways:

The main blocker for EIP-7762 was a desire not to tinker with the blob fee market and not to add more complexity to Pectra. This seems more complicated than 7762 and the benefits over 7762 aren’t that clear to me. If in the long-term we want to have blob capacity > demand to keep price stability but then charge L2s a small amount, then wouldn’t it be better to have a fixed base fee that is easier to justify tuning?


The fee mechanism is currently unaware of the full price of the goods that it attempts to regulate the price for. It therefore fails to converge on equilibrium in a timely manner. To resolve this, the fee update should be made aware of the price of execution gas. The main blocker against EIP-7762 is arguably that it does not relay this price signal but instead specifies a hard-coded price floor. Such a fixed floor could perhaps be characterized as “tinkering”, and this was potentially why the EIP had difficulties gathering consensus. If the price of execution gas becomes much lower, say between 2**5 to 2**6 wei, it is hard to imagine that the price floor for blob gas of 2**25 wei specified in EIP-7762 would be considered appropriate. A price floor that adapts with the price of execution gas is more neutral. It can then adapt with the actual cost of blobspace to ensure a functioning fee market, while letting the price of blob gas evolve without restrictions within these technical limits. Framed within the current “price discovery” discourse, EIP-7918 identifies the inelasticity horizon as an impediment to effective “price discovery”, and keeps the price of blob gas sufficiently high to always influence blobspace equilibrium formation.
EIP-7762 indeed takes the cost of execution gas as its starting point:


To set the parameter apropriately, one aproach is to look at the cost of simple transfers when base fees are low. The cost of a simple transfer when the base fee is 1 GWEI is ~5 cents USD at today’s prices (2,445.77$ ETH/USDC). We can try to peg the minimum price of a blob to that.


One difference is that EIP-7918 allows this type of comparison to take place automatically every block, such that the protocol no longer needs to rely on developers to adjust the floor, should the cost of execution gas change going forward. You mention that the fixed floor of EIP-7762 makes it easier to justify tuning the floor to keep price stability, but I would argue that this is rather a drawback. A self-adjusting dynamic floor is the ideal to strive towards. I would further argue that the change is specifically to ensure a functioning fee market, as opposed to the protocol charging L2s some specific amount for blob gas. EIP-7918 will indeed increase protocol income, just like EIP-7762, but this is mainly a necessity to allow the protocol to operate under more stable resource consumption, without having longer periods of successive blocks consuming above-target blob gas.
A second difference is that EIP-7918 accounts for the potential to amortize the cost of execution gas across blobs when setting the floor. It is reasonable to account for improved future gas efficiency derived via scaling. As stipulated in the EIP:



 aelowsson:

To understand why potential future blob scaling is important to account for when designing the mechanism, consider how the price of storing a fixed amount of data has fallen over the last 80 years.


The discussion regarding the fixed floor in EIP-7762 has focused on whether it is sufficiently low to account for potential future ETH price appreciation. The computer scientist in me would like to remark that this is a bit like trying to predict the appropriate cost of 128 kB of storage 50 years into the future based on the ability of the dollar to retain its value. It can be assumed that the cost of a fixed amount of data availability will fall drastically over the next half-century, both due to improvements in hardware and software, while Ethereum’s income from data availability still rises. Thus, we cannot ascertain the appropriate minimum price for one 128 kB blob based on ETH price considerations, but should instead codify the economic relationship between blob gas and execution gas, allowing the minimum price to adapt with future scaling. To be fair, the change in blob count might take place during a hard fork, and developers could then readjust the EIP-7762 threshold. But as argued, this is undesirable “tinkering”, and changes in blob count migh also happen automatically in the future.
Figure 1 shows how the blob base fee floor adapts with the execution base fee in EIP-7918, while remaining fixed in EIP-7762. The price floor in EIP-7918 varies along the fee parity line, as indicated by arrows. When the target is 6 blobs, the floor has a higher baseline (black arrows) than when the target is 12 blobs (grey arrows), reflecting different opportunities to amortize execution costs across consumed blobs.
Figure 12658×1816 463 KB
Figure 1. Comparison between EIP-7762 and EIP-7918. EIP-7762 stipulates a fixed threshold at 2**25wei. EIP-7918 stipulates a fee-parity threshold that varies with the execution base fee (the cost of the blob-carrying transaction) and the blob target (the opportunity to amortize the blob-carrying transaction).
Concerning implementation complexity:

EIP-7762 changes one constant and adds block_timestamp as an input variable to calc_excess_blob_gas(). This input is included in an if statement evaluating timestamps, returning 0 if TRUE.
EIP-7918 adds one if statement to calc_excess_blob_gas() evaluating computed gas prices, altering the return to be parent.excess_blob_gas + parent.blob_gas_used // 3 if TRUE.

Whether one change brings more complexity than the other is hard for me to tell. They should both be fairly similar and both be straightforward.
Question 4: Request for empirical analysis



 dataalways:

I’m curious to the historical empirical impact of this proposal. How often would it have been a major contributor v.s. being overshadowed by blob fees?


Figures 2-3 show price evolution over three weeks in November 2024, when the average execution base fee was around 16 gwei, as well as in March 2025, when the average was around 1.3 gwei. Thresholding of EIP-7762 (blue) and EIP-7918 (green) is applied directly to the original data, without accounting for its potential effect on the equilibrium fee. The equilibrium blob base fee would in reality rise from the threshold level once demand at this fee is above target supply. A target of 6 blobs was used as the amortization factor to make the comparison applicable to Pectra settings. As evident and in line with the previous Figure 1, the floor in EIP-7918 becomes higher than the floor in EIP-7762 when execution gas is more expensive, and lower when execution gas is cheaper.
Figure 22581×1650 326 KB
Figure 2. Blob base fee evolution with the current fee market (black), with EIP-7762 (blue), and with EIP-7918 (green), during three weeks of November 2024 when the average execution base fee was around 16 gwei. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.
Figure 32581×1648 333 KB
Figure 3. Blob base fee evolution with the current fee market (black), with EIP-7762 (blue), and with EIP-7918 (green), during three weeks of March 2025 when the average execution base fee was around 1.3 gwei. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.
Figure 4 shows histograms for the four-month period from the start of Figure 2 to the end of Figure 3, corresponding to approximately 900k blocks beginning at block number 22075724. The histograms employ 100 log-spaced bins per decade (factor-of-ten increase), which are smoothed using a Hanning window of width 41 with mirror-reflected edges. The threshold set by EIP-7918 (green) can operate both below or above the threshold set by EIP-7762 (blue), depending on the cost of execution gas.
Figure 42644×2217 206 KB
Figure 4. Histogram of the blob base fee when applying EIP-7762 (blue) or EIP-7918 (green), with light smoothing applied. A four-month period from November 2024 through March 2025 was analyzed. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.

Author: potuz
Date: 2025-04-10T15:23:03.352Z

I’ll leave the same comment as in ACD, rather than using TX_BASE_COST  use a function of it, that can be set to be equal to TX_BASE_COST at the first implementation, but allows for a simple change in case this limit proves inadequate.

Author: aelowsson
Date: 2025-04-11T22:25:46.530Z

Thanks for your suggestion! I saw the comment quite late and did not have time to respond. I can see the benefit of allowing for a simple change. This is the current if-clause

if TX_BASE_COST * parent.base_fee_per_gas > TARGET_BLOB_GAS_PER_BLOCK * get_base_fee_per_blob_gas(parent):


The left-hand side accounts for the minimum tx cost and the right-hand side represents the blob cost when including target blobs in the tx. An intuitive point for flexibility would also be the blob gas parity condition on the right side of the if-clause, currently set to TARGET_BLOB_GAS_PER_BLOCK.
There are several ways to do this. We could appy the same idea as in your suggestion on the right-hand side, assign target blob gas (or any other choice) to BLOB_GAS_PARITY (can also be a function), and execute:

if TX_BASE_COST * parent.base_fee_per_gas > BLOB_GAS_PARITY * get_base_fee_per_blob_gas(parent):


Another option is to instead rely on a PARITY_FACTOR that scales the fee parity condition. An example under a cap MAX_BLOB_GAS_PER_TX on the blob gas (it seemed to have fairly strong support during the last ACDE) is:

if TX_BASE_COST * parent.base_fee_per_gas > MAX_BLOB_GAS_PER_TX * PARITY_FACTOR * get_base_fee_per_blob_gas(parent):


At PARITY_FACTOR = 1, the blobs can at most represent 50% of the total cost—applicable when using a simple tx and maximum (capped) blobs. In all other cases the blobs will represent less than 50% at the threshold. Setting PARITY_FACTOR = 4 instead shifts that limit down to 20%. If the cap scales with max blobs, EIP-7918 would still ensure that whatever proportion that is specified through PARITY_FACTOR remains intact.
Do any of these solutions make sense to you?

Author: benaadams
Date: 2025-04-12T17:54:17.136Z

Could we add a lower floor cap in addition; so combine EIP-7918 and EIP-7762; but with a lower level for the EIP-7762 part; say at 0.1gwei
TX_BASE_COST = Max(TX_BASE_COST, 0.1Gwei)
They are 128kB txs after all; so there is a higher cost to them on the network vs a regular 21k gas tx at 100 bytes.
0.1Gwei absolute floor would be 762wei per byte, or 0.8gwei per MB (or about 1c per blob); so isn’t an onerous floor

Author: benaadams
Date: 2025-04-13T04:52:19.178Z

Or maybe https://x.com/VitalikButerin/status/1911223517728698690
TX_BASE_COST = Max(TX_BASE_COST, 1Gwei)

Author: pintail
Date: 2025-04-14T16:04:43.740Z

Wouldn’t the most neutral approach be to change the blob base fee update rule to intrinsically account for the cost of execution? So in times when execution cost dominates the blob base fee would quickly fall to zero (since it can’t be negative) but when demand picks up the blob base fee would initially rise much faster because the update rule targets the total fee including execution cost.
This would be slightly more complex than the rule proposed above but I think it would be more neutral and would more precisely reflect the actual market for blobspace.

Author: pintail
Date: 2025-04-14T16:15:57.340Z

Tried to edit original post but can’t seem to do this on Android. Anyway to illustrate I’m suggesting that we change the update rule something like:
next_blob_premium = (current_execution_cost + current_blob_premium) * (blob_count - blob_target) * update_factor - next_execution_cost

Author: benaadams
Date: 2025-04-14T17:10:35.579Z

pintail:

... update_factor - next_execution_cost


That’s doing the opposite of what is suggested?
A blob transaction is much larger than a regular Eth transfer tx; which is what it generally pays on EL gas side.
Both from the blobs themselves at 128kb each vs 100 bytes for an Eth transfer and the KcgCommitments which it’s getting for free as they aren’t even priced as calldata.
So the proposal is suggesting the price of a blob shouldn’t fall below the EL tx cost.
You are proposing to discount further.

Author: pintail
Date: 2025-04-14T18:03:57.476Z

The problem isn’t that the blob fee goes too low, the problem is that it takes too long to ramp up when demand increases. The formula I propose (admittedly in rough pseudo code) would ensure that the blob fee much more quickly rises to match demand once execution no longer dominates the costs.

Author: benaadams
Date: 2025-04-14T19:09:31.933Z

pintail:

The problem isn’t that the blob fee goes too low,


Is a blob more work to the protocol than a simple Eth transfer?
The answer is definitely yes; regardless of data the EL is also validating their proofs, so they should not be dropping below this price as an example

Author: pintail
Date: 2025-04-14T19:24:50.849Z

I would argue that the basic “cost” to the network is captured by the EL fee, but it would be interesting to consider what other ways there might be to model the cost.
I’m just saying that Anders’ proposal was based on the observation that in periods of low blob demand, the cost to post blob data is dominated by the EL fee, but this is not captured in the blob fee update formula, which is why it takes so long for the blob base fee to catch up when demand increases.
He has proposed one option which is to say that the blob fee should never go below the EL fee and argues that’s the most neutral proposal. I’m saying that the ultimate neutral proposal would be to include both EL and blob fees in the update rule, and I think that although it’s more complex, it would better reflect the market and respond better to the transition from EL-dominated to blobfee-dominated regimes.

Author: aelowsson
Date: 2025-04-14T19:41:32.402Z

pintail:

Wouldn’t the most neutral approach be to change the blob base fee update rule to intrinsically account for the cost of execution? So in times when execution cost dominates the blob base fee would quickly fall to zero (since it can’t be negative) but when demand picks up the blob base fee would initially rise much faster because the update rule targets the total fee including execution cost.


This is the composite fee market, as I already proposed above:



 aelowsson:

Composite fee market
The composite fee market updates the blob base fee based on the real demand function for blobspace, as previously specified in EIP-7918:
Q(b + c).
In this equation, the long-run average per-block quantity of blobs demanded Q depends on the blob base fee b and the tx cost c, expressed per blob gas as specified in the EIP. The real demand function will reflect variations in blob submission strategies, but the same estimate for c as in EIP-7918 could potentially be used. Other options are to simply compute c for every block or to specify c as the long-run average.
Let q represent the desired fractional shift in the cost of blobspace, e.g., in the range [-0.125, 0.125], computed from the realized Q of the block and the target quantity for a block. Further, let c₀ define the tx cost of the previous slot, computed according to one of the options of the previous paragraph and expressed per blob gas. The composite fee auction then updates from b₀ to b₁ by accounting for c₀:
b₁ = b₀ + q(b₀ + c₀)
To the user that employs the same execution gas per blob gas as in c₀, the maximal change in cost of blobspace per slot would still be 12.5%. The proportional change in b can however be dramatic whenever b << c. This is as intended, allowing the composite fee auction to quickly converge on equilibrium, no longer “getting stuck” at lower blob base fees.


The composite fee market is conceptually implemented roughly as follows, when adhering to the structure in the proposal, b₁ = b₀ + q(b₀ + c₀) in the normal domain:
def calc_excess_blob_gas(parent: Header) -> int:
    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0

    # Upsampling so that we can illustrate the composite market using current fake_exponential
    Up = 10**6
    # Compute blob base fee, with the minimum tx cost expressed per blob gas
    b0 = get_base_fee_per_blob_gas(parent)
    c0 = TX_BASE_COST * parent.base_fee_per_gas // TARGET_BLOB_GAS_PER_BLOCK

    if parent.blob_gas_used > TARGET_BLOB_GAS_PER_BLOCK:
        q_Up = fake_exponential(Up, parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK, BLOB_BASE_FEE_UPDATE_FRACTION) - Up
        return fake_log(MIN_BASE_FEE_PER_BLOB_GAS, b0 + q_Up * (b0+c0) // Up, BLOB_BASE_FEE_UPDATE_FRACTION)
    else:
        q_Up = fake_exponential(Up, TARGET_BLOB_GAS_PER_BLOCK - parent.blob_gas_used, BLOB_BASE_FEE_UPDATE_FRACTION) - Up
        return fake_log(MIN_BASE_FEE_PER_BLOB_GAS, b0 - Up * (b0+c0) // q_Up, BLOB_BASE_FEE_UPDATE_FRACTION)

Note the new function fake_log(). As mentioned in the description for this proposal, the change is conceptual in nature, and not something I intended for Fusaka, but rather suggested as a potential part of a wider harmonization of fee markets. If there is support for a composite fee market, we can of course push for it, but my intuition is that the proposed simple solution following the same principle was more suitable at this stage, also due to its ability to establish a neutral price floor for blobs. Such a price floor has been suggested as a goal in itself among some members of the community. EIP-7918 is designed to be “the best of both worlds” in this respect, establishing a neutral price floor that ensures a functioning fee market, adhering to economic efficiency.

Author: benaadams
Date: 2025-04-14T19:43:20.378Z

pintail:

I would argue that the basic “cost” to the network is captured by the EL fee


It is demonstratablely not because the EL fee for 3 blobs is the minimum tx fee of 21k gas
image1290×403 46.6 KB

Author: pintail
Date: 2025-04-14T19:57:24.414Z

Ah ok, I think I had not understood the composite alternative proposal. Still seems to me like a much better function and in enforcing that the min blob fee should be equal to the EL fee seems a bit arbitrary. But still an improvement on a hard floor.

Author: pintail
Date: 2025-04-14T20:11:59.771Z

How would you model the cost?

Author: benaadams
Date: 2025-04-14T20:27:06.055Z

I’d probably go for that the cost of a blob shouldn’t fall below the Point Evaluation Precompile cost at 50000 gas * EL base fee, we already have a price for it; or you are getting the EL work cheaper than a smart contract does.
The blob submitter is still getting a good deal as they only have to pay the priority fee on the 21k gas for basic tx cost (and deeply discounted data vs calldata on both commitments/proofs and the blobs themselves)

Author: pintail
Date: 2025-04-14T20:51:57.573Z

Seems reasonable - and could be achieved by repricing blob transactions on the EL.

Author: benaadams
Date: 2025-04-15T00:58:57.593Z

Specifically; rather than using TX_BASE_COST use POINT_EVALUATION_PRECOMPILE_GAS and also enforce floor first so an individual blob cost shouldn’t stay under the cost of EL verification
So changing to
def calc_excess_blob_gas(parent: Header) -> int:
    base_blob_fee = get_base_fee_per_blob_gas(parent) * GAS_PER_BLOB
    base_verification_fee = parent.base_fee_per_gas * POINT_EVALUATION_PRECOMPILE_GAS

    if base_verification_fee > base_blob_fee:
        # Fee too low relative to execution cost
        # increase, but not by more than a max fill would (e.g. div 3 for 6/9)
        return parent.excess_blob_gas + parent.blob_gas_used // 3

    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        # Below target usage; blob fee sufficiently high; reset excess
        return 0
    else:
        # Above target usage; normal EIP-4844 excess gas logic
        return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK

Author: benaadams
Date: 2025-04-15T12:59:44.733Z

Then if you blend in EIP- 7762; and @vbuterin’s latest feedback https://x.com/VitalikButerin/status/1911223517728698690
It would become
def calc_excess_blob_gas(parent: Header) -> int:
    min_price = 2**30 // approx 1 gwei
    base_blob_fee = get_base_fee_per_blob_gas(parent) * GAS_PER_BLOB
    base_verification_fee = parent.base_fee_per_gas * POINT_EVALUATION_PRECOMPILE_GAS

    if base_verification_fee > base_blob_fee or min_price > base_blob_fee:
        # Fee too low relative to execution cost
        # increase, but not by more than a max fill would (e.g. div 3 for 6/9)
        return parent.excess_blob_gas + parent.blob_gas_used // 3

    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        # Below target usage; blob fee sufficiently high; reset excess
        return 0
    else:
        # Above target usage; normal EIP-4844 excess gas logic
        return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK

Author: niran
Date: 2025-04-15T20:28:41.816Z

This proposal aims to avoid reducing the blob fee when blob fee reductions won’t increase the demand for blobs, but it misidentifies L1 execution costs as the source of this problem. The situation where lowering the blob fee doesn’t result in more blobs posted is common, but there are only a few causes for each L2:

The L2 is congested. They’re running near their gas target and have a significant base fee as a result. They are unable to submit more blobs regardless of the price.
The L2 is subsidized. They are serving all demanded transactions that meet their subsidy criteria without price sensitivity. Can’t fill more blobs.
The L2 has no fee market due to low demand. They are serving all demanded transactions with near zero fees. Can’t fill more blobs.
The L2 is limited by L1 execution costs. Transactions are priced out by the L1 execution cost before the blob fee is even considered.

If there is a single L2 that doesn’t meet these criteria, lowering the blob fee will result in more blobs posted. That’s why this proposal is so harmful: there is almost always at least one subsidy-free chain with a fee market where higher blob fees will shift the chain from being congested to uncongested. That means setting the minimum blob fee to the L1 execution cost is too high and will reduce the number of blobs posted. Ethereum should never price out blobs that it can safely handle.
It’s possible that there is a minimum blob price that wouldn’t reduce blobs posted (which reduces Ethereum L2 capacity). But it’s not the point where execution price equals blob price. It’s the point where the least congested L2 becomes uncongested and dips below its gas target. Any higher blob price will reduce the demand for L2 transactions, which I hope we all agree should be avoided.

Author: 0x00101010
Date: 2025-04-15T21:47:02.706Z

There are several drawbacks of this proposal that is worth considering:

when execution fee rises and continue to be high, even if blob capacity remains at target / below target, blob fee will continue to rise until it’s higher than execution fee
a. this is the most important drawback and it adds an unwanted worst case scenario that does not quite justify its benefit
b. This is bad since EVM execution congestion now negatively affects blob capacity, which is bad for scaling and negate the intention of multidimensional gas market
This affects rollup’s ability to correctly calculate L1 fees and charge users for it, users and developers now have to reason about 2 interacting base fees, imo this is unnecessary complexity.
It is still too early to say that blob fee market does not work, there simply isn’t enough blobs and throughput for it to be working. I can totally imagine a world where we have 12 (target) / 24 (max) or 48 (target) / 72 (max) the fee market will become much more reasonable and stable
imho the priority should be scaling and anything that could potentially harm scaling (high fees) should be avoided, and if the community still think blob fees are heavily undercharged, EIP-7762 would be better as a temporary mechanism

Author: benaadams
Date: 2025-04-15T21:53:41.521Z

niran:

That means setting the minimum blob fee to the L1 execution cost is too high and will reduce the number of blobs posted.


If an L2 cannot afford POINT_EVALUATION_PRECOMPILE_GAS of L1 gas (0.95% of calldata cost; a 99.05% discount) for it’s blob, then it probably shouldn’t be posting 128 kB of data (the size of a large L1 block, or several hundred txs) to L1? At that point they may want to reconsider how they are bundling tx related data.
That space would be better used to increase the L1 blockspace and reduce the L1 fees?

Author: aelowsson
Date: 2025-04-15T23:06:20.982Z

Thanks for your feedback.



 0x00101010:

1. when execution fee rises and continue to be high, even if blob capacity remains at target / below target, blob fee will continue to rise until it’s higher than execution fee
a. this is the most important drawback and it adds an unwanted worst case scenario that does not quite justify its benefit
b. This is bad since EVM execution congestion now negatively affects blob capacity, which is bad for scaling and negate the intention of multidimensional gas market


Note that this EIP does not stipulate that the blob base must be higher than the base fee. Figure 1 in this answer illustrates the relationship between the blob base and the base fee.
Blob consumers already have to pay the execution fee today—it does not go away under any proposal. There is already a worst-case scenario for blob consumers in terms of the execution fee they need to pay. For blob consumers relying on more gas-consuming blob-carrying transactions (the consumers most affected by execution costs), the blob base fee will be irrelevant at the point where the threshold kicks in (it can easily represent less than 1% of the tx cost). Thus, when the execution fee rises, these blob consumers remain completely unaffected by a rise in the cost of blobs.
EVM execution congestion will always negatively affect blob capacity, under any mechanism, and will always lead the demand curve to become perfectly inelastic. EIP-7918 is ideal in its ability to pinpoint where the fee markets can remain separate while remaining functional, and allows the fee markets to remain completely separate under such conditions. It is only by adapting with the execution base fee that we always hit the sweet spot of not affecting blob consumers more than necessary, while still ensuring a functioning fee market.



 0x00101010:


This affects rollup’s ability to correctly calculate L1 fees and charge users for it, users and developers now have to reason about 2 interacting base fees, imo this is unnecessary complexity.



Rollups already need to calculate their fees based on the base fee and the blob base fee, and these fees of course already interact, in more complex hidden ways. EIP-7918 simplifies their work by removing the necessity to also reason and estimate requirements on a third fee, the priority fee, which they currently must also rely on during times of blob congestion.



 0x00101010:


It is still too early to say that blob fee market does not work, there simply isn’t enough blobs and throughput for it to be working. I can totally imagine a world where we have 12 (target) / 24 (max) or 48 (target) / 72 (max) the fee market will become much more reasonable and stable



Demand for blobspace varies with execution costs and the blob base fee. It is already possible today to establish that the blob fee market does not account for both costs, leading to a dysfunctional fee update whenever the execution costs dominate. Given the inherent inelastic demand for the sold goods, EIP-7918 is particularly suitable for ensuring a functional fee market.



 0x00101010:


imho the priority should be scaling and anything that could potentially harm scaling (high fees) should be avoided, and if the community still think blob fees are heavily undercharged, EIP-7762 would be better as a temporary mechanism



EIP-7918 facilitates scaling by removing sustained periods of above-target blob consumption, stemming from the current mechanism being unable to raise the price fast enough when starting from a lower level. This will enable Ethereum to ship slightly higher targets overall. One of EIP-7918’s strengths is that it is not necessarily a temporary mechanism. It will adapt with scaling, ideally without any further adjustments needed. EIP-7918 is not specifically about charging L2s higher fees. Its top priority is a functional fee market.

Author: 0x00101010
Date: 2025-04-16T00:04:22.843Z

Thank you for responding so quickly and thoughtfully, would definitely love to learn more and discuss about this.



 aelowsson:

Blob consumers already have to pay the execution fee today—it does not go away under any proposal. There is already a worst-case scenario for blob consumers in terms of the execution fee they need to pay. For blob consumers relying on more gas-consuming blob-carrying transactions (the consumers most affected by execution costs), the blob base fee will be irrelevant at the point where the threshold kicks in (it can easily represent less than 1% of the tx cost). Thus, when the execution fee rises, these blob consumers remain completely unaffected by a rise in the cost of blobs.


Agree that under low blob fee situation, the increase does not matter. However the concern here is that under high execution cost (and maybe continuously rising) situation, blob fee has to rise with the execution cost (until its on par to switch back to the normal behavior). This creates a situation that it’s double worse for blob transactions when execution costs are high and going higher. It forfeits the capability for blob fee market to evolve independently.
There could be a situation that execution costs increases quite a lot due to Defi boom or hot airdrop or some other things, at that moment, it makes sense for execution cost to go up, however the DA resources at that time is mostly unaffected / unused or maybe under utilized, and with this change, we’ll still see exponentially rising blob fees, which puts unnecessary additional pressure on the DA resource.



 aelowsson:

Rollups already need to calculate their fees based on the base fee and the blob base fee, and these fees of course already interact, in more complex hidden ways. EIP-7918 simplifies their work by removing the necessity to also reason and estimate requirements on a third fee, the priority fee, which they currently must also rely on during times of blob congestion.



Not sure I follow the idea here, with this change, rollups still will need to care about priority fee in times of congestion?
rollups (at least for OP stack), the calculation is already somewhat complicated: https://docs.optimism.io/stack/transactions/fees#ecotone, and changing the excess calculation here will lead to potentially changing system contracts, fee calculation logic to reflect the proper fee structure.




 aelowsson:

Demand for blobspace varies with execution costs and the blob base fee. It is already possible today to establish that the blob fee market does not account for both costs, leading to a dysfunctional fee update whenever the execution costs dominate. Given the inherent inelastic demand for the sold goods, EIP-7918 is particularly suitable for ensuring a functional fee market.


The question here is that is it really dysfunctional due to fee market design? If we look at https://dune.com/hildobby/blobs, the blob base fees frequently goes higher to over 30 gwei. The main issue I see is with the consistency of the blobs being posted, for example, Base posts 5 blob per tx roughly every 1 minute, and if it changes to post 1 blob every block, it could smooth out the drop and potentially make the demand more consistent.
The argument here is that because 6 is such a small number and with the different posting strategies from different chains, sometimes the blob arrival / composition isn’t that consistent, so it could be like 0 blob, 0 blob, 6 blob, 6 blob situation. which isn’t super great for price discovery. However with higher blob numbers and limited blob number per transaction, I could actually see this problem go away. After all, we’re saturated at target for quite some time and there’s clear demand to higher blob targets.



 aelowsson:

EIP-7918 facilitates scaling by removing sustained periods of above-target blob consumption, stemming from the current mechanism being unable to raise the price fast enough when starting from a lower level. This will enable Ethereum to ship slightly higher targets overall. One of EIP-7918’s strengths is that it is not necessarily a temporary mechanism. It will adapt with scaling, ideally without any further adjustments needed. EIP-7918 is not specifically about charging L2s higher fees. Its top priority is a functional fee market.



EIP-7918 facilitates scaling by removing sustained periods of above-target blob consumption, stemming from the current mechanism being unable to raise the price fast enough when starting from a lower leve

My personal opinion is that this is actually a counter argument? sustained periods of above-target blob consumption isn’t bad necessarily as long as the protocol can handle it?

This will enable Ethereum to ship slightly higher targets overall

What do you mean by that? Higher fees means lower demands?

One of EIP-7918’s strengths is that it is not necessarily a temporary mechanism. It will adapt with scaling, ideally without any further adjustments needed

This is the part I’m not following, would love to understand deeper, why would it adapt with scaling? with higher blob numbers, it’s still dependent on execution costs rather than the target?

Author: benaadams
Date: 2025-04-16T00:35:14.007Z

0x00101010:

and changing the excess calculation here will lead to potentially changing system contracts, fee calculation logic to reflect the proper fee structure.


This calculation will need to be updated after Pectra goes live due to EIP-7623 which changes the calldata calcuation that would be applied

Author: undefined
Date: 2025-04-16T02:19:12.886Z

0x00101010:

It forfeits the capability for blob fee market to evolve independently.


As I understand the proposal, this is not by accident (and arguably already the case). Part of the motivation seems to be acknowledging that the markets are if not one then at least very much linked by their shared restricted underlying resources? This particular dynamic looks inherent to the proposal.
Which is not to say it isn’t worth exploring different scenarios and if particularly pathological cases or externalities can be mitigated.

Author: aelowsson
Date: 2025-04-17T15:33:26.552Z

0x00101010:

This is the part I’m not following, would love to understand deeper, why would it adapt with scaling? with higher blob numbers, it’s still dependent on execution costs rather than the target?


I will in this answer try to explain what adapting with scaling means and why it is necessary for a blob base fee threshold. First to briefly answer the question more directly: the if-clause depends on both execution costs and the targeted number of blobs. Therefore, if more blobs are targeted, the execution base fee must be higher to have an effect on the blob base fee.
There are essentially two different axes by which blob base fee thresholds can adapt: with the execution base fee and with blob quantity. This leads to a quadrant in scaling adaptation strategies, as outlined in Table 1.





Scaling adaptation paradigms





Quantity↓ Execution→
No
Yes


No
EIP-7762
EIP-7918E


Yes
EIP-7918Q
Full EIP-7918 (EQ)



Table 1. The scaling quadrant for blob fee thresholds. Full EIP-7918 adapts with both blob quantity and execution base fee, and EIP-7762 adapts with neither. Versions of EIP-7918 that only scale with execution base fee (E) or blob quantity (Q) are also reasonable to consider.
In general terms, the if-clause for an EIP-7918Q implementation looks like this:
if AGGREGATED_BLOB_BASE_FEE_THRESHOLD > BLOB_QUANTITY * get_base_fee_per_blob_gas(parent):

In this scenario, BLOB_QUANTITY can derive from the target number of blobs, and the AGGREGATED_BLOB_BASE_FEE_THRESHOLD will apply to an aggregation of the blob base fee over some stipulated blob quantity. The floor can be fixed to AGGREGATED_BLOB_BASE_FEE_THRESHOLD when the if-clause returns TRUE.
The if-clause for an EIP-7918E implementation looks like this
if TX_COST * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent):

When this if-clause returns TRUE, the blob base fee should rise smoothly according to:
return parent.excess_blob_gas + parent.blob_gas_used // 3

as in the original implementation. An EIP-7918E implementation was previously suggested by Ben Adams, relying on POINT_EVALUATION_PRECOMPILE_GAS to establish a neutral threshold.
Two reasons for adapting with blob quantity can be outlined:

Q1 – As DA scales, blob consumers can scale up consumption, allowing them to amortize their fixed execution costs (e.g., proof verification for ZK rollups, and batch posting costs for optimistic rollups) across more posted blob data.
Q2 – As DA scales, the upper end of the possible long-run ETH-denominated price per blob will fall.

The first reason (Q1) has been the main focus previously. As the targeted number of blobs increases, the fixed costs fall relative to the variable costs, and the blob fee market (which covers the variable costs) can then remain functional under a lower blob base fee, still influencing the quantity of blobs demanded. The second point (Q2) is however also important: as the quantity of blobs per block increases, the upper end of the long-run average income that Ethereum can expect to derive from each blob should fall.
First of all, technological progress generally brings down the unit cost of data services, as observed in many areas following Nielsen’s law and Moore’s law.
In the case of Ethereum’s DA services, there is also a specific reflexivity that is important to understand and that will now be explored further. Aggregate ETH-denominated income from DA affects the fiat-denominated value of the ETH token, reflexively bounding the possible long-run ETH-denominated income, thus bounding the per-unit price of blobs.
As an example, assume that technological progress allows Ethereum to scale both the execution layer and DA, with a target of 4000 blobs 10 hard forks from now. Further assume that 1/4 of Ethereum’s income (focusing here on burned ETH and ignoring MEV) derives from DA and 3/4 from the regular execution gas burn, and that there is a minimum blob base fee of 1 gwei. In this scenario, the burn rate would be a whopping 4.6%. The long-run burn rate cannot be too high for a PoS chain with a low issuance rate such as Ethereum, given a reasonable monetary premium and a “tech premium”. The token becomes too valuable to hold when accounting for “token buybacks”, use as money, and future prospects, and the price of ETH must rise, thus pushing the burn rate back down as the fiat-denominated cost facing the consumer becomes prohibitive. Figure 1 illustrates the relationship between the number of blobs per block sold at a 1 gwei blob base fee and the burn rate, with the burn rate specifically derived from blob base fees at various proportions.
Figure 12657×1623 208 KB
Figure 1. Relationship between the number of blobs per block sold at a 1 gwei blob base fee and the burn rate.
A burn rate of 4% is illustrated by a dashed line in the figure, corresponding to a ratio between market cap and annualized burn of 25. A fixed threshold such as 1 gwei explored in the figure would undeniably put a ceiling on the number of blobs that can be consumed on average in the long run. The threshold then effectively act as a cap on blob quantity, regardless of the specified target.
Such a threshold would however have detrimental effects at far lower blob targets. Figure 2 shows how the price of blob gas and execution gas varies across the day in a chronogram. During the overlap in business hours between Western Europe and the U.S., the gas price is on average the highest. The mean smoothed blob base fee varies by almost an order of magnitude (10x) across the day, and the median varies by around four orders of magnitude (10000x). Variation between different days is also substantial. Any threshold will particularly affect parts of the world doing business during a time in the day differing from Western Europe and the U.S. From a fairness perspective, it is therefore important to have a clear rationale for the threshold level, for example preserving a functioning fee market. Accounting for the execution costs when setting the threshold arguably also directly improves fairness: the threshold will then on average be lower outside of EU/U.S. business hours, since execution base fees (green line in Figure 1) naturally covaries with the blob base fees (blue line). It is also important from a fairness perspective to make the threshold adaptive, taking away the need for developers to re-adjust it as Ethereum scales.
Figure 22799×1650 438 KB
Figure 2. Fee chronogram illustrating how fees vary over the day.
When it comes to adapting with the execution costs, this is what allows (Q1) to be fully modeled. One hypothetical rationale for adapting only with execution costs and not with blob quantity is that execution gas limits and blob gas targets could evolve roughly in the same direction, such that the associated fall in the base fee for both matches. Full EIP-7918 can navigate such assumptions in two ways, either by in that scenario slowly subsiding (while still remaining relevant for several decades) as the fee market starts functioning better, or by imposing sub-linear adaptation strategies.

In conclusion, a fixed threshold would need to be re-adjusted by developers as Ethereum scales, at least if scaling is substantial. This sort of re-adjustment should be avoided. A particular strength of cryptoeconomics is the ability to encode promises that extend into the future, and EIP-7918 allows for this, by automatically adapting the threshold.

Author: benaadams
Date: 2025-04-20T17:24:13.907Z

What is really being compensated for here is there are buyers who operate on price; however the seller is price insensitive and only volume sensitive, so it isn’t an ideal auction market (or even an AMM style market). So the fixed value is the reserve auction price that the goods are unwilling to be sold below.



 aelowsson:

a fixed threshold would need to be re-adjusted by developers as Ethereum scales, at least if scaling is substantial


The developers are the ones doine the scaling so seems perfectly value to adjust the base price with it?
However I have proposed that it both has a floor price an obeys the min price for the execution cost POINT_EVALUATION_PRECOMPILE_GAS so a blob is not getting that execution cost cheaper than an L1 smart contract would

Author: aelowsson
Date: 2025-04-20T22:50:57.335Z

benaadams:

What is really being compensated for here is there are buyers who operate on price; however the seller is price insensitive and only volume sensitive, so it isn’t an ideal auction market (or even an AMM style market). So the fixed value is the reserve auction price that the goods are unwilling to be sold below.


Yes, the threshold can be thought of as fulfilling two functions:

Ensuring a functional fee market by always maintaining the blob base fee at a level where it influences demand (the main argument presented in EIP-7918). A similar, more general motivation is to ensure faster “price discovery” for blobs.
Setting the price of blobs sufficiently high that it is motivated to expend resources processing them, thus emphasizing the supply side.

Regarding (2), I am generally a bit hesitant, as I see low transaction costs on L2s as positive and believe we should only do blob target increases that can be handled under full throughput. However, below a certain price, expended resources will indeed no longer meaningfully reduce the fees on L2s, as other costs (such as tx costs)  become dominant for them. We have thus circled back to point (1). I believe that both perspectives can be applied to all proposals through different framings.



 benaadams:

The developers are the ones doine the scaling so seems perfectly value to adjust the base price with it?


Ideally, we should avoid giving developers influence over the price mechanism with every hard fork that increases blob throughput. To retain the same range between the maximum realistic average blob base fee and the floor, a reciprocal adjustment relative to the blob target is necessary. If developers are not going to follow a clear rule, the process may appear arbitrary to blob consumers paying for the sold goods, or they may find ways to influence the process in a way that is not beneficial to the community. If developers are going to follow a fixed rule, it is much better to encode it, which is what I suggest we do.



 benaadams:

However I have proposed that it both has a floor price an obeys the min price for the execution cost POINT_EVALUATION_PRECOMPILE_GAS so a blob is not getting that execution cost cheaper than an L1 smart contract would


Yes, I looked at both your proposals, thanks for these ideas! I consider the first one the most viable, given that it might adapt with scaling, assuming the execution layer scales as well. This is the type of mechanism I then called an EIP-7918E mechanism in the previous comment.
Regarding the second proposal, my contention is that scaling Ethereum’s execution layer will naturally drive down the execution base fee. Thus, over time, the fixed floor “min_price” will come to dominate, making the POINT_EVALUATION_PRECOMPILE_GAS check irrelevant. The same issues previously described then applies, with developers forced to make adjustments to the min_price (note that base_blob_fee in the second proposal is actually “blob_cost”, and cannot be compared with min_price).
I then also defined the opposite, an EIP-7918Q mechanism that only adapts with blob quantity and not with the execution base fee.  I will here specify a basic version so that all functions in the quadrant can be compared:
def calc_excess_blob_gas(parent: Header) -> int:
    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0
    if MIN_TARGET_BLOB_PRICE > TARGET_BLOB_GAS_PER_BLOCK * get_base_fee_per_blob_gas(parent):
        return parent.excess_blob_gas + parent.blob_gas_used // 3
    else:
        return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK

To have a 2**30 blob base fee threshold at a target of 6 blobs, the constant would thus be specified to:
MIN_TARGET_BLOB_PRICE = 2**30 * 6 * GAS_PER_BLOB

If preferred, the threshold can be specified to the blob base fee aggregated over target blobs. It is also possible to use an adaptive MIN_BASE_FEE_PER_BLOB_GAS constant:
+ MIN_BASE_FEE_PER_BLOB_GAS = 2**30 * 6 * GAS_PER_BLOB // TARGET_BLOB_GAS_PER_BLOCK
- MIN_BASE_FEE_PER_BLOB_GAS = 1

and then make sure to reset excess_blob_gas upon changes to the target.

Author: benaadams
Date: 2025-04-20T23:14:59.210Z

aelowsson:

    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0



Having the early exit check first means that blob fees will only respond to the new curve if over target, but still precipitously drop if below?

Author: aelowsson
Date: 2025-04-21T10:20:18.107Z

benaadams:

Having the early exit check first means that blob fees will only respond to the new curve if over target, but still precipitously drop if below?


The if-clause activates when the update would have reduced excess_blob_gas below 0. When pricing blobs, excess_blob_gas is the log-domain encoding of the blob base fee, where 0 corresponds to MIN_BASE_FEE_PER_BLOB_GAS (currently 1 wei). You could actually still consider moving the if-clause as you suggest. The reason for doing so would however be more obscure (yet theoretically sound): to allow a threshold just above MIN_BASE_FEE_PER_BLOB_GAS to influence excess_blob_gas, in the case where a reduction by TARGET_BLOB_GAS_PER_BLOCK  would have otherwise reduced excess_blob_gas below 0.

Author: aelowsson
Date: 2025-05-05T22:18:35.608Z

The main question was answered previously, but I will here address some other questions from your comment.



 0x00101010:

Agree that under low blob fee situation, the increase does not matter. However the concern here is that under high execution cost (and maybe continuously rising) situation, blob fee has to rise with the execution cost (until its on par to switch back to the normal behavior). This creates a situation that it’s double worse for blob transactions when execution costs are high and going higher. It forfeits the capability for blob fee market to evolve independently.
There could be a situation that execution costs increases quite a lot due to Defi boom or hot airdrop or some other things, at that moment, it makes sense for execution cost to go up, however the DA resources at that time is mostly unaffected / unused or maybe under utilized, and with this change, we’ll still see exponentially rising blob fees, which puts unnecessary additional pressure on the DA resource.


The price floor on the blob base fee imposed by EIP-7918 would initially be set approximately 40 times lower than the execution base fee, as illustrated in Figure 1 of this answer, and would then fall further. Over the last year, there have been a few spikes in the execution base fee, where it temporarily reached 40 gwei. Such a spike would lead to a temporary spike in the blob base fee floor to 1 gwei. But as illustrated in Figure 2 of this answer, the average blob base fee (over the last million blocks) has been higher than 1 gwei during all times of the day. The floor is very moderate, and it is moderate even during spikes, because buying many blobs (carrying potentially thousands of txs) costs as little as a simple ETH transfer.
The floor must specifically vary to maintain its relative relationship to the execution fee, but it should be noted that the blob base fee only rises when blobs are actually consumed, not automatically when the execution base fee rises (the fee evolution depends on blob consumption, but the fee is restricted from falling when below the floor).
Generally, there are many conflicting goals regarding blob pricing. We can identify two goals that should garner broad support because they follow Ethereum’s established approach to resource pricing:

ensure that the fee market can function properly,
do not impose unnecessary costs on users.

To ensure that the current blob fee update mechanism can function properly, the blob base fee must remain sufficiently high relative to the execution base fee. Otherwise, an increase in the blob base fee will not temper demand, leading to sustained periods of above-target consumption. To ensure that we do not impose unnecessary costs on blob consumers, the blob base fee must remain sufficiently low relative to the execution base fee. Otherwise (if not tied to the execution base fee), the fee increase imposed by the floor can come to substantially increase L2 tx costs. Note thus that the two goals are jointly resolved by establishing the floor relative to the execution base fee at some balanced point deemed to maximize utility. The suggestion in the EIP is to establish that point when a simpe tx costs as much as target blobs. But the exact point is subject to further discussion; for example, 20% of the cost is suggested in one of the answers. A ZK rollup buying one blob can however easily consume 100 times more execution gas than blob gas at the currently proposed point, and the blob fee update mechanism is already not particularly relevant then.



 0x00101010:

The question here is that is it really dysfunctional due to fee market design? If we look at https://dune.com/hildobby/blobs, the blob base fees frequently goes higher to over 30 gwei. The main issue I see is with the consistency of the blobs being posted, for example, Base posts 5 blob per tx roughly every 1 minute, and if it changes to post 1 blob every block, it could smooth out the drop and potentially make the demand more consistent.
The argument here is that because 6 is such a small number and with the different posting strategies from different chains, sometimes the blob arrival / composition isn’t that consistent, so it could be like 0 blob, 0 blob, 6 blob, 6 blob situation. which isn’t super great for price discovery. However with higher blob numbers and limited blob number per transaction, I could actually see this problem go away. After all, we’re saturated at target for quite some time and there’s clear demand to higher blob targets.


Yes, there is an issue with the fee market design. The demand for blobspace depends on both the blob base fee and the execution base fee. This leads the blobspace demand curve to bend, which should theoretically result in the sub-optimal fee evolution that has also been observed. While there could be many other intertwined reasons for the observed fee evolution, the model is theoretically sound. The blob base fee indeed frequently goes higher than 30 gwei, but when demand rises, it can take several hours until such a market-clearing blob base fee is reached, which is not desirable. I recently published a children’s book on this theme that you may find interesting.



 0x00101010:

My personal opinion is that this is actually a counter argument? sustained periods of above-target blob consumption isn’t bad necessarily as long as the protocol can handle it?

This will enable Ethereum to ship slightly higher targets overall

What do you mean by that? Higher fees means lower demands?


Assume that the protocol can handle some specific blob throughput for a sustained period. Under the current fee mechanism, we must set max blobs to that level because the protocol can experience several hours close to max blobs even under very reasonable demand curves (due to the influence of execution costs causing the demand curve to bend). With EIP-7918, we could instead set target blobs closer to that manageable throughput, given that there cannot be sustained periods above the target under reasonable demand curves (since the fee update mechanism is not operating in the bent region of the demand curve).

Author: benaadams
Date: 2025-05-10T01:47:46.497Z

aelowsson:

Regarding the second proposal, my contention is that scaling Ethereum’s execution layer will naturally drive down the execution base fee. Thus, over time, the fixed floor “min_price” will come to dominate, making the POINT_EVALUATION_PRECOMPILE_GAS check irrelevant. The same issues previously described then applies, with developers forced to make adjustments to the min_price (note that base_blob_fee in the second proposal is actually “blob_cost”, and cannot be compared with min_price).


POINT_EVALUATION_PRECOMPILE_GAS is 50,000gas; base tx cost is 21,000gas; each blob is doing a POINT_EVALUATION_PRECOMPILE equivalent so why do they get a 29,000 gas discount per blob vs a smartcontract in its pricing considerations?