# EIP-1559 Time-Based Base Fee Adjustments

## Motivation

- current EIP-1559 base fee adjustment: based on block gas usage
- in effect, control loop that targets stable throughput per block
- not ideal under PoW under two aspects:
- block time variability:
- block gas usage tries to measure demand at current base fee level, but gas usage is proportional to block time, introducing noise to the used signal
- block time variability => "incorrect" demand signals => "incorrect" base fee adjustments => increased base fee volatility
- reduced throughput during consensus issues:
- if chain forks, block times go up for a while, before difficulty is adjusted
- gas limit elasticity would give us the capability to compensate for this throughput reduction to some extent
- also not ideal under PoS:
- missed slots:
- while general block times become regular, occasionally slots are missed, doubling the block time for the next block (or more, if that slot is also missed)
- missed slots still send incorrect signal (demand looks 2x as high as it is), leading to base fee spikes after missed slots
- incentive to attack network via block proposer DOS, as each missed slot directly reduces network throughput
- consensus issues:
- worse than under PoW, as longer time for self-healing (several weeks for inactivity leaks as opposed to several hours for difficulty adjustments)
- gas limit elasticity would again give us the capability to compensate for this throughput reduction to some extent

## Proposal
- include block time in base fee adjustment: make "block gas target" proportional to block time
- results in control loop that targets stable throughput per time
- addresses problems listed above:
- reduces / removes base fee volatility inroduced by PoW block time variability
- reduces / removes base fee volatility inroduced by PoS missed slots
- reduces incentive to DOS block proposers
- reduces / removes impact of chain forks on throughput
- drawback: during demand spikes under PoS, missed slots can delay base fee increase

#### Current EIP-1559 Update Rule

$b_{n+1} = b_n * (1 + \frac{1}{8}\frac{g_n-G_n}{G_n})$, where:

$b_n$ : base fee at block $n$
$\frac{1}{8}$ : maximum base fee change rate
$g_n$ : gas used by block $n$
$G_n$ : gas target for block $n$

#### Block Time Based Update Rule

$b_{n+1} = b_n * (1 + \frac{1}{8}\frac{g_n-G_n\frac{t_n}{T_n}}{G_n})$, where:

$t_n$ : block time for block $n$, i.e. `block.timestamp - parent.timestamp`
$T_n$ : block time target

#### Capped Block Time Based Update Rule

In practice it is sensible to introduce an upper limit to the block time used by the update rule:

- during chain forks, block gas targets above 50% reduce the ability to pick up on demand increases
- in the extreme, with 50%+ of proposers offline, the base fee could not increase at all
- fee market would revert to a first-price auction on top of the current base fee level
- base fee would even leak downwards due to small residual fee block space (<21k)
- alternative: bound block gas target to below elasticity limit

$b_{n+1} = b_n * (1 + \frac{1}{8}\frac{g_n-G_n\frac{\text{min}(t_n, T_{\text{max}})}{T_n}}{G_n})$, where:

$T_{\text{max}}$ : maximum block time to consider (e.g. 23s or 24s for PoS)

### Specification

The relevant part of the pseudocode specification of EIP-1559 is:

BASE_FEE_MAX_CHANGE_DENOMINATOR = 8




parent_gas_target = self.parent(block).gas_limit // ELASTICITY_MULTIPLIER
parent_gas_limit = self.parent(block).gas_limit
parent_base_fee_per_gas = self.parent(block).base_fee_per_gas
parent_gas_used = self.parent(block).gas_used

if parent_gas_used == parent_gas_target:
    expected_base_fee_per_gas = parent_base_fee_per_gas
elif parent_gas_used > parent_gas_target:
    gas_used_delta = parent_gas_used - parent_gas_target
    base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1)
    expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta
else:
    gas_used_delta = parent_gas_target - parent_gas_used
    base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR
    expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta

This update would only require changes to lines (2, 3, 5), 6, 15, 19:

BASE_FEE_MAX_CHANGE_DENOMINATOR = 8
BLOCK_TIME_TARGET = 12
BLOCK_TIME_CONSIDERATION_CAP = 23

parent_considered_block_time = min(self.parent(block).timestamp - self.parent(self.parent(block)).timestamp, BLOCK_TIME_CONSIDERATION_CAP)
parent_gas_target = self.parent(block).gas_limit * parent_considered_block_time // ELASTICITY_MULTIPLIER // BLOCK_TIME_TARGET
parent_gas_limit = self.parent(block).gas_limit
parent_base_fee_per_gas = self.parent(block).base_fee_per_gas
parent_gas_used = self.parent(block).gas_used

if parent_gas_used == parent_gas_target:
    expected_base_fee_per_gas = parent_base_fee_per_gas
elif parent_gas_used > parent_gas_target:
    gas_used_delta = parent_gas_used - parent_gas_target
    base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta * ELASTICITY_MULTIPLIER // parent_gas_limit // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1)
    expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta
else:
    gas_used_delta = parent_gas_target - parent_gas_used
    base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta * ELASTICITY_MULTIPLIER // parent_gas_limit // BASE_FEE_MAX_CHANGE_DENOMINATOR
    expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta

## Future Changes

- exponential base fee update
- more elegant properties
- slightly more involved change to include efficient deterministic exponentiation
- variable block gas limits (dependent on block times)
- feasible to the extent the bottleneck for block gas limits is state growth, not networking / computation