# Improving EIP-4844 blob pricing with proportional control
## Overiew
We will show equivalence between the EIP-4844 fee mechanism and PID control and then explore improving the EIP-4844 fee mechanism.
## EIP-4844 Fee Mechanism
From [Dankrad Feist's Explainer](https://dankradfeist.de/ethereum/2022/03/16/exponential-eip1559.html), the formula for the blob gas price at block $n$.
$b_{n} = b_0 \exp\left(\frac{1}{TA}\left(\sum_{i=0}^{n-1}g_i - nT\right)\right)\space\space\space\space\space\space$ **(1)**
where:
$g_i$ is blob gas used at block $i$
$T$ is the target blob gas used
$A$ is a constant that produces changes in blob gas that are equal to EIP-1559, $\pm12.5\%$ when blob space is full or empty.
Let's rewrite this in a different form.
In **(1)**, bring $T$ back into the summation:
$b_{n} = b_0\ exp(\frac{1}{TA}\sum_{i=0}^{n-1}(g_i - T))$
In feedback control terms, the difference between the measured value(blob gas used) and the target(blob gas used) is the error, $e$.
So let $e_i = g_i -T$
$b_{n} = b_0\ exp(\frac{1}{TA}\sum_{i=0}^{n-1}e_i)$
and since $b_0=1$
$b_{n} = \ exp(\frac{1}{TA}\sum_{i=0}^{n-1}e_i)\space\space\space\space\space\space$ **(2)**
This is an equivalent version of the EIP-4844 equation.
### PID Control
It turns out the EIP-4844 mechanism is a type of PID Controller.
First,
"A PID controller continuously calculates an error value
${\displaystyle e(t)}$ as the difference between a desired setpoint (SP) and a measured process variable (PV) and applies a correction based on **P**roportional, **I**ntegral, and **D**erivative terms (denoted P, I, and D respectively), hence the name."
Source: https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller
A PID controller is a common feedback control mechanism and has the following *continuous* form.
$u_t = K_pe_t + K_i\int_{0}^{t} e_t \,dt + K_d\frac{d}{dt}e_t$
Blob gas price control operates in discrete time, so consider the discrete PID form. The below form uses [right riemann sum](https://en.wikipedia.org/wiki/Riemann_sum#Right_Riemann_sum) approximation of the continuous integral.
$u_t = K_pe_t + K_i\sum_{i=0}^{t-1}e_i dt + K_d\frac{e_{t}-e_{t-1}}{dt}$
In addition to being discrete, control of blob gas prices is done on a fixed interval(every block). So we can let $dt = 1$ block and simplify this further.
$u_n = K_pe_n + K_i\sum_{i=0}^{n-1}e_i + K_d(e_{n}-e_{n-1})$
Setting $K_p =K_d = 0$, and $K_i = \frac{1}{TA}$ provides the final form of a discrete, fixed interval Integral-only controller.
$u_n = \frac{1}{TA}\sum_{i=0}^{n-1}e_i\space\space\space\space\space\space$
Take $ln$ of both sides of the existing EIP-4844 mechanism, **(2)**
$ln(b_{n}) = ln(\ exp(\frac{1}{TA}\sum_{i=0}^{n-1}e_i))$
Since $ln(exp(x)) = x$
$ln(b_{n}) = u_n = \frac{1}{TA}\sum_{i=0}^{n-1}e_i\space\space\space\space\space\space$
We see *the existing blob price control mechanism is an integral-only controller of $ln(b_n)$*. $\blacksquare$
### Non-negative integral
The sum in **(2)**, aka `excess_blob_gas`, is rightfully not allowed to go negative per [EIP-4844 spec](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md), but the canonical PID formula doesn't expressly stop this.
This bounded constraint on the integral is common in PID control and is called *integral clamping*. It's used when a natural bound has been reached on the controller's output, and further accumulating the integral cannot affect the process under control. For example, a tank being filled is not yet full, but the fluid valve is already completely open. There is no benefit to further accumulating the integral and it can even be detrimental to stability in some scenarios.
In the case of EIP-4844, the `MIN_BLOB_GAS_PRICE` has already been reached when `excess_blob_gas=0`, so there is no need to keep accumulating negative errors. Thus, the integral is required to be non-negative.
## Framing Blob Pricing as PID Control
Since we've established the existing mechanism is an Integral controller, we can use well known methods of classical control to guide how think to about it and improve control of $ln(blob\ gas\ price)$
![PID discrete](https://hackmd.io/_uploads/Bk_2KoU9a.png)
Source: modified from https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller
<br>
| Variable | Name | EIP-4844 |
| -------- | -------- | -------- |
| $e(t)$ | error, $r(t) - y(t)$ | $blob\_gas\_used - target$ |
| $r(t)$ | target | $393216$ |
| $u(t)$ | control variable | $ln(blob\_gas\_price)$ |
| $y(t)$ | process output | $blob\_gas\_used$ |
| $\sum_{i=0}^{n-1}e_i$ | integral | $max(excess\_blob\_gas, 0)$ |
| $K_i$ | integral gain | $\frac{1}{TA}$ |
## Adding Proportional Error
The Proportional term in a PID controller considers the current error of the system, in this case $blob\_gas\_used - target$.
Adding this term to the current Integral-only mechanism should produce fees that are more responsive to current demand.
### Blob Price PI Controller
Adding $K_pe_{n-1}$ to the exponent of the existing controller will produce a PI controller of $ln(b_n)$.
$b_{n} = \ exp(K_pe_{n-1} + K_i\sum_{i=0}^{n-1}e_i)\space\space\space\space\space\space$
## Blob Price PI Simulations
Below are some simulations of this controller under some scenarios of blob demand. What is not being simulated below is the controlled process(blob demand). This visualization purely shows how the controller reacts to specific demands and does *not* simulate blob demand reaction to the pricing mechanism.
We can see the proportional term of the PI controller(yellow) in action. Compared to the existing mechanism(red), it produces higher prices during demand and lower prices when demand subsides. As expected, it is more reactive to current demand.
**Note**: The following $K_i$ $K_p$ are *not recommended prod parameters*, but are chosen to visualize behavior.
### Sim #1: Demand shock
40 full blocks, 10 empty blocks
1) $K_p = K_i = \frac{1}{TA}$
![image](https://hackmd.io/_uploads/r14eYr_9T.png)
2) $K_p = 5 * K_i$
$K_i = \frac{1}{TA}$
![image](https://hackmd.io/_uploads/BJqFcru96.png)
### Sim #2: Demand shock then plateau
20 full blocks, 10 half-full(target) blocks, 10 empty blocks.
1) $K_p = K_i = \frac{1}{TA}$
![image](https://hackmd.io/_uploads/Sy_s6Bd5p.png)
2) $K_p = 5 * K_i$
$K_i = \frac{1}{TA}$
![image](https://hackmd.io/_uploads/ryv6pBd9a.png)
### Sim #3: Demand oscillation
20 full blocks, 10 empty blocks, then 20 full blocks.
1) $K_p = K_i = \frac{1}{TA}$
![image](https://hackmd.io/_uploads/HJAjRBOcp.png)
2) $K_p = 5 * K_i$
$K_i = \frac{1}{TA}$
![image](https://hackmd.io/_uploads/H17FCBu5p.png)
## Future Work
### Blob Price Bounds
The above parameters will produce blob price changes outside the current EIP-4844 range of $(0.\overline{888}, 1.125)$. Ideally, we find parameters that:
1) stay within a certain fixed bound
2) have appropriate and useful proportions between $K_i$ and $K_p$.
### Tuning for EVM Pricing
We should also consider this mechanism for EVM pricing in lieu of EIP-1559. EIP-1559 on mainnet takes a lengthy amount of time to return to equilibrium after demand spikes. Adding the proportional term would improve usability of the network in this case.
The EVM market and parameters will require different values for $K_i$ and $K_p$.
### Use Relative Error
#### Deficiences of the EIP-4844 mechanism
1. Setting $e_i = g_i - T$ makes the $K_i, K_p$ parameters brittle to increases of `MAX_BLOB_GAS_PER_BLOCK`.
2. Historical blob gas prices cannot be derived solely from on-chain data.
Explanation:
An error of 3 blobs above the target of 3 is substantial now, when there is a max of 6 blobs allowed. If the max blobs is later increased to 24, with a target of 12, having 3 blobs over target shouldn't generate the same pricing response.
Solution:
Using $e_i = \frac{g_i - T}{T}$ would make the system resilient to changes in `MAX_BLOB_GAS_PER_BLOCK`
As-is, under EIP-4844, the blob gas price will experience some level of discontinuity when `MAX_BLOB_GAS_PER_BLOCK`is increased.
### Experiment with a Derivative Term
The derivative term would allow the mechanism to detect changes in demand faster, but adds more complexity. This would need tuning to ensure it's not overly sensitive to noise.
### Consider Incentive Compatibility
Does this mechanism introduce new manipulation techniques or attack vectors?
-Bert Kellerman, Head of Research @ blocknative.com

Floating peg

8/6/2024COIN 1-Page

6/24/2024Deficiences of the EIP-4844 Mechanism

6/4/2024This post will detail a nuance in how the RAI system controller calculates the redemption rate and will propose a slight change. The system currently uses the absolute error of the market price to compute rates, but using the percent error will produce consistent rates under RAI/USD price changes. For a refresher on how the RAI controller works, go here. Rate Calcuation The mainnet RAI controller is currently only a P-controller, so the redemption rate is calculated as: $redemption_rate = Kp * (redemption_price - market_price)$ where:

1/5/2022
Published on ** HackMD**

or

By clicking below, you agree to our terms of service.

Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet

Wallet
(
)

Connect another wallet
New to HackMD? Sign up