Add EIP: Dynamic target blob count

Merged by EIP-Bot.

EIPS/eip-7788.md

@@ -0,0 +1,104 @@
+---
+eip: 7788
+title: Dynamic target blob count
+description: Target blob count changes dynamically to aim for constant blob costs
+author: Marc Harvey-Hill (@Marchhill)
+discussions-to: https://ethereum-magicians.org/t/eip-7788-dynamic-target-blob-count/21399
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-10-15
+requires: 7742
+---
+
+## Abstract
+
+This EIP proposes to make the target blob count adjust dynamically up to a safe maximum target. This adjustment will target a constant price in ETH for blobs, aiming for consistent costs of L2 transactions.
+
+## Motivation
+
+Ethereum currently uses a target of 50% capacity for blob count, with [EIP-1559](./eip-1559.md) smoothing out short term spikes and pushing average throughput towards the target. A dynamic target is orthogonal to EIP-1559, tweaking the target itself over a longer timescale to aim for some desired blob cost.
+
+With static targeting the target may be higher than the actual demand, causing the protocol to undercharge for blobspace. This decreases the amount of fees burned, negatively affecting the price of ETH and total network security.
+
+As an example, consider what would happen if there was a large increase in max blob count due to DAS implementation but the target remained at 50%. It is unlikely that demand would immediately jump to anywhere near the target, and so for months or years the protocol would effectively charge nothing for L2 transactions. With a dynamic target, the target blob count would drop until the cost of blobspace for an L2 transaction approximated some affordable constant value. In this way, some fees are still burned by the protocol, but new L2s are not discouraged from using Ethereum blobspace, knowing that the target will increase in response to an increase in demand and blob fees will remain reasonably consisent.
+
+While the max blob count and max target are hard constraints based on resource utilisation limits, setting the target itself is far more subjective. A dynamic target can optimise for constant and affordable L2 transaction costs without requiring regular intervention by core developers to make tweaks based on changes in demand.
+
+## Specification
+
+### Parameters
+
+| Parameter | Value |
+| - | - |
+| `FORK_TIMESTAMP` | TBD |
+| `TARGET_BLOB_COUNT_CHANGE_RATE` | `1` |
+| `MIN_TARGET_BLOB_COUNT` | `1` |
+| `MAX_TARGET_BLOB_COUNT` | `3` |
+| `BLOB_COST_CHANGE_MARGIN` | `2^48` |
+| `TARGET_BLOB_COST` | `2^49` |
+
+### Dynamic targeting
+
+The target blob count changes each epoch based on the mean blob cost over the previous epoch. If the average cost exceeds the desired amount beyond some margin then the target is increased; likewise if it is below the desired amount by some margin the target will decrease. The target can increase up to `MAX_TARGET_BLOB_COUNT`, which is deemed to be a safe average throughput for the network, and down to a minimum of `MIN_TARGET_BLOB_COUNT`.
+
+Calculating targets:
+
+```python
+blob_cost_diff = mean_blob_cost - TARGET_BLOB_COST
+target_change_direction = -1 if blob_cost_diff < -BLOB_COST_CHANGE_MARGIN else (1 if blob_cost_diff > BLOB_COST_CHANGE_MARGIN else 0)
+next_epoch_blob_count = max(min(MAX_TARGET_BLOB_COUNT, previous_epoch_blob_count + (target_change_direction * TARGET_BLOB_COUNT_CHANGE_RATE)), MIN_TARGET_BLOB_COUNT)
+```
+
+### Engine API change
+
+The Engine API is extended to provide the `mean_blob_cost` for the current epoch when the CL requests it from the EL. The CL requests this at the end of an epoch to set the target for the next epoch (depends on [EIP-7742](./eip-7742)).
+
+## Rationale
+
+### Constant blob cost target
+
+A constant blob cost target can keep L2 transaction costs affordable for end users. Volatility in the price of ETH would affect affordability, but is unlikely to be significant compared to normal fluctuations in blob gas costs due to spikes in activity. In future the costs could be adjusted in the case of changes in the order of magnitude of ETH price.
+
+An alternative approach would be to track a target blob cost in fiat. However, chosing a specific fiat currency is not credibly neutral, and introducing exchange rate oracles into the protocol could be an attack vector.
+
+Yet another alternative is to have validators vote on the target blob cost, but they may have conflicts of interest (for example if they operate a rollup) so again this is not credibly neutral.
+
+### Target block gas
+
+The same logic could be applied to the target block gas, but generally blockspace is in high demand so arguably gas costs are never too low. The target should be set to the maximum average throughput that the network can safely handle, a dynamic target is not necessary.
+
+### Parameter choices
+
+`TARGET_BLOB_COST` is chosen so that the system targets affordable L2 transactions. Assuming that the theoretical compressed size of a simple transfer is 23 bytes, this gives a blobspace cost for L2 transactions of:
+
+```
+(23 / 125000) * TARGET_BLOB_COST ≈ 104 gWei
+```
+
+At todays prices, $1 would cover blobspace for around 3700 simple transfers on L2. The blob cost target should be chosen with extensive community involvement. Note that this is the cost of blobspace for an L2 transaction; the total cost will be more due to rollup execution costs.
+
+`TARGET_BLOB_COUNT_CHANGE_RATE` is chosen as a compromise between the system being reactive to changes in demand, and not having large jumps in average throughput. `BLOB_COST_CHANGE_MARGIN` is set such that target blob count will stay static when blob costs are within a range ±50% of `TARGET_BLOB_COST`.
+
+`MAX_TARGET_BLOB_COUNT` is set to `3` to match the current static target. This value should be increased in future when it is deemed to be safe to increase average blob throughput.
+
+## Backwards Compatibility
+
+N/A
+
+## Test Cases
+
+N/A
+
+## Reference Implementation
+
+N/A
+
+## Security Considerations
+
+<!-- TODO -->
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).