# On the EIP-7918 `return` statement When the `if`-clause in [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918) evaluates to true, the fee update is operating in the thresholded regime, and should not decrease the blob base fee further. The function then returns: ```python return parent.excess_blob_gas + parent.blob_gas_used // 3 ``` This produces a positive linear response in `blob_gas_used` that has the same maximum increase as when the `if`-clause evaluates to false. Two alternatives will be outlined here. ## Incorporating `max` blobs in the equation As previously mentioned, computing `// 3` ensures that the maximum increase stays the same as in the regular update. Specifically, `// 3` compensates for the fact that `1/3` of the max blob gas remains after subtracting `TARGET_BLOB_GAS_PER_BLOCK`. This is expressed as the equation: `(max - target) / max = 1/3`. It would be convenient to encode the relationship, which is easily achieved if the EL has access to `blobSchedule.target` and `blobSchedule.max` from [EIP-7892](https://eips.ethereum.org/EIPS/eip-7892). In this case, the `return` statement can be modified to: ```python return parent.excess_blob_gas + parent.blob_gas_used * (blobSchedule.max - blobSchedule.target) // blobSchedule.max ``` If EIP-7892 is confirmed for Fusaka with accessible constants, this `return` statement could be pursued. ## Bounding return at `0` A proposal by [Ansgar Dietrichs](https://x.com/adietrichs) instead changes the logic of the return statement. The idea is to take the original computation `parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK` and impose that the change is at least `0` by computing the `max`: ```python return parent.excess_blob_gas + max(0, parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK) ``` This means that whenever less than `TARGET_BLOB_GAS_PER_BLOCK` is used, there is no change in `excess_blob_gas`, and that the shift otherwise is the same as in the original return statement. The main benefit is to not require the division `// 3`, in the case that `blobSchedule.max` cannot be used. The proposal also stays close to the original return statement in the sense that a simple bound is applied to it. The main drawback is that the update to `excess_blob_gas` becomes non-linear, meaning that the blob base fee is affected by the distribution of blobs in consecutive blocks. If three consecutive blocks have {6, 6, 6} blobs, the blob base fee does not rise, whereas if three blocks have {0, 9, 0} blobs, the blob base fee rises, eventhough there were just half as many blobs. ## Comparison Figure 1 compares the options. The green line shows how the fee market operates regularly as well as in EIP-7918 when the `if`-clause evaluates to `false`. The dark yellow line indicates the design in EIP-7918 for how to update the blob base fee when the `if` clause evaluates to `true`, and the mechanism thus operates in the thresholded regime. This is also the outcome when incoprorating the `max` blobs in the return statement. The blue dotted line instead shows the return bounded by 0.  **Figure 1.** Comparison of blob base fee update mechanisms, illustrating the standard operation (green line), the EIP-7918 thresholded regime design (dark yellow line), and an alternative thresholded regime with the return bounded by zero (blue dotted line).