# Improving the Blob Base Fee Mechanism

While the EIP-4844 fee mechanism is an improvement of the EIP-1559 mechanism, there are a few nuances/shortcomings everyone should be aware of.

## Shortcomings of the current EIP-4844 Mechanism

#### 1. Calculating historical blob base fees requires tracking off-chain data

The `blob_base_fee` is not stored on-chain, but it derived from `excess_blob_gas`. To derive `blob_base_fee`, the off-chain client value of `BLOB_BASE_FEE_UPDATE_FRACTION` must be known. If `BLOB_BASE_FEE_UPDATE_FRACTION` was going to be a constant for the life of this mechanism, this wouldn't be a big deal when fetching/calculating historical `blob_base_fee` values

However, *`BLOB_BASE_FEE_UPDATE_FRACTION` must be changed whenever `MAX_BLOB_GAS_PER_BLOCK` is updated.*

As Ethereum scales and the number of blobs per block is increased, devs/UIs must keep track of the values of`MAX_BLOB_GAS_PER_BLOCK` for different block ranges to correctly calculate `blob_base_fee`.

---

#### 2. Changing `MAX_BLOB_GAS_PER_BLOCK` requires network coordination

Unlike the execution `gas_limit`, an individual node is not free to increase `MAX_BLOB_GAS_PER_BLOCK` on its own.

A change of`MAX_BLOB_GAS_PER_BLOCK` is not represented in the execution header. So if a client decides to increase this value, there would be no indication in the header and the resulting block validation on `excess_blob_gas` could fail.

In comparison, the block `gas_limit` is present along with the final `base_fee_per_gas`, so there is no ambiguity in block validation.

If we are worried about aggressive increases, there can be a safety built into the clients that only allow increases within a certain proportion, like clients do for `gas_limit`

-----

#### 3. When `MAX_BLOB_GAS_PER_BLOCK` is changed, discontinuities in the blob gas price can happen.

`excess_blob_gas` represents a non-negative accumulation of error, where `error = blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK`

As `TARGET_BLOB_GAS_PER_BLOCK` and `BLOB_BASE_FEE_UPDATE_FRACTION` change, the previously accumulated errors stored in the `excess_blob_gas` represent the old target and can produce inappropriate prices. This might be a minor issue, as the market will quickly correct, but one we should be aware of.

**Blob Base Fee Discontinuity Visualized**

In the chart below, the `blob_base_fee` is represented under a constant `blob_gas_used` of 786432.

However, at the peak of the `blob_base_fee` in this chart below, `MAX_BLOB_GAS_PER_BLOCK` is increased by a factor of 5x.

Because of this increase, the `blob_base_fee` falls by 67%, much more than 12.5%.


**This discontinuity does not happen when using relative error.**

If Ethereum wants to avoid price discontinuities when increasing `MAX_BLOB_GAS_PER_BLOCK` it will have to perform a transformation of `excess_blob_gas` every time or avoid this entirely by using the solution below.

### Solution: Relative Error

Switching from absolute error to relative error, allows nodes some freedom to change `MAX_BLOB_GAS_PER_BLOCK` and makes the mechanism resilient to these increases in regards to historical fetching and price continuity. It solves issues **1**,**2**, and **3**.

#### Existing EIP-4844 Mechanism

$b_{n} = b_0\ exp(\frac{1}{TA}\sum_{i=0}^{n-1}e_i)$

where:
$e_i = g_i -T$

$TA = BLOB\_BASE\_FEE\_UPDATE\_FRACTION = 3338477$, dependent on `MAX_BLOB_GAS_PER_BLOCK`

#### Proposed EIP-4844 Mechanism, using relative error

$b_{n} = b_0\ exp(\frac{1}{TA}\sum_{i=0}^{n-1}e_i)$

where $e_i = (g_i -T)/T$

$TA = BLOB\_BASE\_FEE\_UPDATE\_FRACTION = 3338477/393216$, a constant for all `MAX_BLOB_GAS_PER_BLOCK` values

### The effect of relative error

#### 1. As Ethereum scales, $TA$ remain a constant, creating less complexity in client upgrades.

#### 2. Since $TA$ is constant, the calculation of `blob_base_fee` from `excess_blob_gas` will remain unchanged throughout the history of `MAX_BLOB_GAS_PER_BLOCK` increases.

Devs don't need to maintain historical update fractions for specific block ranges to calculate blob gas prices.

#### 3. There will be no price discontinuities when `MAX_BLOB_GAS_PER_BLOCK` increases.

#### 4. A change of units for`excess_blob_gas`

`excess_blob_gas` would not longer represent raw excess gas, but relative excess, and thus not a whole number. It could possibly still be implemented as an integer if rounded and scaled.

References:

[Original Twitter Post](https://twitter.com/BertKellerman/status/1754215281293996360)

[PID Derivation of EIP-4844](https://hackmd.io/w2s_nSM0SEqz3iEgnf_NSw)