Update EIP-7742: update the required EL headers and the gas fee mecha…

[g11tech]

from: ethereum/execution-apis#574 (comment)

we might need to add baseFeePerBlobGas in beacon's execution header and hence the api field, because the blob gas price can't just be now : minFee* e^(ecessBlobGasg/blobGasPriceUpdateFraction) since blobGasPriceUpdateFraction (for limiting change 1+-1.125 factor) could change block to block.

so we should return to the normal pricing mechanism like basefee, so blobBaseFee = parent.blobBaseFee * e^((blobGasUsed - targetBlobGas)/blockAdjustedTargetFraction))

where blockAdjustedTargetFraction makes sure fee doesn't "change" by 1.125 either direction and is calculated block to block.

so in EL block header, we now remove excessBlobGas and add three fields: baseFeePerBlobGas, targetBlobGas and maxBlobGas (since we don't want this to be a hardfork based setting anymore as well, and don't want to keep a static fraction between target and max for better control over the blob throughput and bandwidth params), and beacon execution header we just add baseFeePerBlobGas

if it makes sense i could update the EIP 7742 with the gas calc changes and introducing the new fields

(I am ok to replace target gas/max gas with target count/max count in the EL header and gas calcs, whatever seem more convenient)

[eth-bot]

File EIPS/eip-7742.md

Requires 1 more reviewers from @ralexstokes

[bkellerman]

@g11tech @ralexstokes
Reverting to the old fee mechanism(getting rid of excessBlobGas) removes the possibility of jumps larger than +=12.5% when changing target/max(even when updating the update fraction to account for new target/max).

The excessBlobGas is an accumulator of raw error and when changing the target/max drastically, the errors based off the old target/max can cause large jumps. Demonstrated here

A different issue is the problem of price jumps when setting a non-symmetrical target, like you alluded to.

Let $target_{bg}=4$ and keep $max_{bg}=6$, a currently proposed initiative.

Under these parameters w/ existing $updatefraction$, this will produce fee responses of 8.2% and -14.5%, for full and empty blocks respectively.

One solution to make things cleaner is to use relative error instead of raw error.

$basefee = e^{((blobGasUsed - targetBlobGas)/targetBlobGas)/updateFraction)}$

Then, we can select a single $updateFraction=3338477/393216$ that works for all target/max.

Since relative error is bounded at -1, but unbounded above, the zero blob space response works exactly as before.
For any target <= max, zero blob space will result in the original EIP-4844 $0.\overline{8}$ multiplier.

Full Blob Space will have a different response than before, but proportionate to the relative error and still appropriate imo.

For any target >= max/2, full blob space will result in lt the EIP-4844 $1.125$ multiplier, but that's okay since the target is already high so a full response is not necessary.
For any target < max/2, output will be gt the intended $1.125$ and should thus be limited to $1.125$

[siladu]

@bkellerman can you open permissions to you hackmd post please?

[g11tech]

The excessBlobGas is an accumulator of raw error and when changing the target/max drastically, the errors based off the old target/max can cause large jumps.

correct, thats why we need block by block updates and simple excessGas accumulation will not work because CL can possibly alter target block by block

One solution to make things cleaner is to use relative error instead of raw error.

b a s e f e e = e ( ( b l o b G a s U s e d − t a r g e t B l o b G a s ) / t a r g e t B l o b G a s ) / u p d a t e F r a c t i o n )

Then, we can select a single u p d a t e F r a c t i o n = 3338477 / 393216 that works for all target/max.

so we accumulate not excess gas but "normalized excess gas": ((blobGasUsed-targetBlobGas)/targetBlobGas) * C (some factor) , to have a uint field and then we exponentiate it as e^(excessGas/C*normalizedUpdateFraction)

this way we accumulate a normalized excess gas doesn't matter if target even changes block to block, which we must assume it can

[bkellerman]

@siladu it's open now

[bkellerman]

@g11tech

Here's a candidate

1. Let relativeErrorModified = ((used-T)/T + 1) *100E6
2. Let updateFraction = 849018702
3. Then we can use multiplier = 1/1.125 * exp(relativeErrorModified/updateFraction)

This multiplier function meets the needs of
f(empty blob space) = 0.8888
f(target) = 1
f(full blob space) = 1.125

Edit: Since full blob space can theoretically create relative error > 1(if target < max/2), we bound the raw relative error to 1 or bound the multiplier afterwards.

[g11tech]

@g11tech

Here's a candidate

1. Let `relativeErrorModified = ((used-T)/T + 1) *100E6`

2. Let `updateFraction = 849018702`

3. Then we can use `multiplier = 1/1.125 * exp(relativeErrorModified/updateFraction)`

This multiplier function meets the needs of f(empty blob space) = 0.8888 f(target) = 1 f(full blob space) = 1.125

Edit: Since full blob space can theoretically create relative error > 1(if target < max/2), we bound the raw relative error to 1 or bound the multiplier afterwards.

we don't need to add 1 and then divide multiplier by 1.125 since normalizedExcessGas would be accumulator >0 since we don't wanna drop below min, i.e. multiplier >=1 at all times i.e. normalizedExcessGas>=0 (as is the current mechanism)

since normalizedExcessGas_N = max(normalizedExcessGas_N-1 + (used-T)/T * Factor, 0)
and then multiplier = exp(normalizedExcessGas/normalizedUpdateFraction)

right?

[bkellerman]

right?

I thought we preferred to get rid of the excess accumulator and "return to the normal pricing mechanism like basefee"?

The implementation I posted above operates on a single block's error and applies the resulting multiplier to previous base fee. It doesn't use an excess accumulator.

My personal intuition is to remove the excess and have the explicit base fee, which is much better for dev UX and resilient across parameter changes.

Edit: But we can make a version that accumulates the normalized error if needed.

Edit: I added the 1 above since you said we needed the norm. error to be uint

[bkellerman]

For an excessNormBlobGas accumulator:

updateFraction=3338477/393216

Then accumulate raw norm error. Raw norm error having the range [-1, 1]

So

baseFee = minBaseFee * exp(excessNormBlobGas/updateFraction)

where
excessBlobGas = max(sum((used-T)/T), 0)

If we want updateFraction to be an integer, then we have to scale the numerator and denom like before.

updateFraction=3338477/393216*100E6=849018605

excessBlobGas = max(sum((used-T)/T)*100E6, 0)

wdyt?

[g11tech]

For an excessNormBlobGas accumulator:

updateFraction=3338477/393216

Then accumulate raw norm error. Raw norm error having the range [-1, 1]

So

baseFee = minBaseFee * exp(excessNormBlobGas/updateFraction)

where excessBlobGas = max(sum((used-T)/T), 0)

If we want updateFraction to be an integer, then we have to scale the numerator and denom like before.

updateFraction=3338477/393216*100E6=849018605

excessBlobGas = max(sum((used-T)/T)*100E6, 0)

wdyt?

yes this is what i finally suggested:
The reason I like this better is that it introduces minimal change in the current codebase

[g11tech]

i have pushed an alternate PR @bkellerman : #8994 as per our last discussion

[g11tech]

closing in favor of #8994