EIP-7788: Dynamic target blob count

Target blob count changes dynamically to aim for constant blob costs

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 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

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:

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).

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

Needs discussion.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Marc Harvey-Hill (@Marchhill), "EIP-7788: Dynamic target blob count [DRAFT]," Ethereum Improvement Proposals, no. 7788, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7788.