PIP-58: Increase BaseFeeChangeDenominator to 64

[jerry]

Abstract

This proposal seeks to increase the BaseFeeChangeDenominator (the maximum rate at which the base fee can be adjusted between blocks) on the Polygon PoS network from 16 to 64. Increasing this value will reduce the volatility of gas prices during periods of high demand.

Motivation

Polygon PoS chain introduced EIP-1559 as part of the London Hardfork, although this upgrade has significantly reduced the occurrence of gas spikes, certain network conditions can still lead to significant increases in gas in a fairly short timeframe.

The initial parameters of EIP-1559 were changed in the Delhi hardfork with the BaseFeeChangeDenominator increased from 8 to 16.

Polygon PoS has 2-second block times, so currently with the BaseFeeChangeDenominator set to 16, the base fee can increase by up to 6.25% per block, leading to a 1000% increase in 80 seconds.

Specification

We propose increasing the BaseFeeChangeDenominator from its current value of 16 to 64. This change will halve the maximum base fee change per block, smoothing out gas price volatility.

Pre and Post-Change Values

• BaseFeeChangeDenominatorPre = 16
• BaseFeeChangeDenominatorPost = 64

Updated Logic

func BaseFeeChangeDenominator(borConfig *BorConfig, number *big.Int) uint64 {
    if borConfig.IsUpgradeBlock(number) {
        return BaseFeeChangeDenominatorPostUpgrade
    } else {
        return BaseFeeChangeDenominatorPreUpgrade
    }
}

Backwards Compatibility

This change is not compatible with the protocol’s existing consensus checks and will require a hardfork. On the infrastructure level, this change is fully backward-compatible with existing wallet and applications. The core functionality of EIP-1559 will remain intact, and no modifications are required on the part of users or applications.

Security Considerations

This change does not introduce new security risks. The adjustment only alters the rate of base fee changes, ensuring smoother fee dynamics without affecting consensus or transaction validity.

In the long term, this could lead to increased strain on node hardware as this change in effect reduces a countermeasure (gas fees) to short-term capacity spikes.

Copyright

All copyrights and related rights in this work are waived under CCO 1.0 Universal.

[jerry]

In order to illustrate the impact of modifying the BaseFeeChangeDenominator, we simulated the evolution of the base fee during a recent surge. The simulation compares how the base fee would have behaved if the denominator were set to different values (e.g., 32, 64, or 128). The accompanying chart shows that during a 40-minute period—from block 67469896 to 67470907—the base fee increased from 132 Gwei to 35,535 Gwei. In contrast, with a BaseFeeChangeDenominator of 64, the base fee would have peaked at only 591 Gwei.

[diminiko]

I like that smoother fee adjustments improve the user experience, but I worry that the slower ramp-up might give people an easier way to spam the network.

[jerry]

Although the base fee will increase less rapidly after this change, it would still be expensive for spammers to attack the network. For instance, if all blocks are full in a span of 10 mins (300 blocks), the base fee would increase 100x.

>>> (1+1/64) ** 300
104.7164227408616

[0xD0A4004d1916C0F93D]

On Immutable zkEVM we configured the rate of change denominator to be 50. This gives a base fee maximum rate of change of 2% per block. Given a 2 second block time, this approximately matches Ethereum’s rate of change, if viewed from wall-clock time. We figured giving people and software more time to back off submitting transactions, and a time that matched what people were accustomed to on Ethereum, was a good idea.
I support the move to 64.