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
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.
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
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?
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.
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.
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.
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.
Thank you for responding so quickly and thoughtfully, would definitely love to learn more and discuss about this.
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.
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.
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.
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?
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.
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:
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 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 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.
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.
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
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.
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.
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:
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:
There needs to be some sort of floor on fees. Fees only influence demand to a certain extent; nobody expects to be able to make a million dollar transfer for 5 cents. In fact I’d be highly sceptical and questioning security if that were the case. In addition what’s the incentive for those running validators? Because such low fees cause ETH inflation and nobody wants their money inflated away otherwise we’d just hold fiat cuckbucks.
We need to have the input of ordinary, practical minded people such as myself here not just big-brain ivory tower types that just want to build, build, build like it’s a research project. This is a real world, live ecosystem. Think of in-vivo vs in-vitro!
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.
