# 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%.
![image](https://hackmd.io/_uploads/BkH7BSoVA.png)
**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)