Impact of EIP1559 and Future Possibilities

Impact of EIP1559 and Future Possibilities

On January 18, 2022, at block number 23850000, London fork was activated on Polygon Mainnet. Among the various EIPs that were part of the fork, the most significant change came in the form of EIP1559, which aimed to change the on-chain gas price dynamics.

The Polygon PoS chain has a block time of 2 seconds and had a gas limit of 20M before the fork. Given the network conditions, average node infrastructure and state bloat, we think the network might face issues to generate >20M sized blocks for sustained periods of time. Also, most of the analysis on EIP1559 has been done for the symmetric case, where the gas target is half of the block gas limit. Keeping all these in mind, we had set the gas target to 10M and the limit to 20M.

The impact of the fork has been that users have higher gas prices. The main reasons were:

  1. The average block capacity is around 10M, compared to 20M earlier. This means that, at an average, the network throughput is around half.
  2. During high demand, the baseFee rises around 2x in ~12 seconds. This results in poor UX. The gas predictability that was one of the promises of the EIP was still true, but the short block time made the predictions more erratic in practice.

The way forward

Following are the different options we can move forward for EIP1559. We want community’s feedback and thoughts on feasible options.

  1. Increase gas limit

    In the short term, we can suggest validators to increase the block gas limit to 30M or upwards. This would make the average block size around 15M, alleviating some of the impact. However, during periods of high activity, 30M sized blocks will be generated. Validators might not be able to process 30M gas in 2 seconds, resulting in empty blocks, which in turn increases the demand and hinders the fee mechanism. However, we have not yet noticed this case.

    Note that this is not a consensus change and does not require a hard fork. Moreover, validators are free to choose gas limits based on their infrastructure.

  2. Change the baseFee change rate

    Currently, the maximum change in baseFee is 12.5% or 1/8. This means that six consecutive full blocks result in >100% increase in baseFee. This is the same timespan as one Ethereum block time. Hence, we can scale the rate to 1/48 to make sure the rate of rise and fall of baseFee matches that of Ethereum. The change would limit baseFee fluctuations. However, it is worth noting that the time it takes to reduce baseFee during periods of low activity would also increase, meaning that some users might still be priced out although there is not enough transaction load.

    Note that these changes require another hard fork to implement.

  3. Alternative update mechanisms

    The current implementation is symmetric, in the sense that gas limit and empty block are both equidistant from the target. This also means that the rate of increase of baseFee is the same as decrease. This case has been analyzed in detail and most systems use this in practice. However, if we break the symmetry and set the target close to the limit, then the average block size can be set close to 20M. This improves the throughput, without changing the existing block gas limits. However, this also means that the rate of decrease will be slower than the increase, which might result in longer durations of high baseFee.

    To elaborate with an example, if the limit is 20M and target is 18M,

    • A 20M block results in baseFee increase of 12.5%.
    • A 18M block keeps the baseFee same.
    • A 0M block results in baseFee decrease of 12.5%.
    • A 16M block results in decrease of 1/(8*9) times baseFee.

    Another option is to modify the baseFee update rule altogether. Current EIP1559 implementation updates the baseFee at a fixed rate. There has been studies on variable learning rates which have been shown to have better results on simulated environments. However, we need to deeper analyze the results to know its applicability on our chain.

    Both the above options are largely untested and might be risky to deploy on production systems. More research needs to be done to ascertain the effectiveness of such mechanisms on our PoS chain.

  4. Make target as same as max gas limit

    The last option which remains is to disable the EIP and rollback to pre-EIP fee mechanism. However, we would want to still support Type-2 transactions. One simple way to achieve both is to set the target equal to the limit at 20M. This would break the EIP and ultimately make the baseFee constant (min fee set by protocol).

10 Likes

Thanks for the post @prabal! It seems a combination of mitigations 2. and 3. would be good steps towards achieving what I see as ideal gas price behavior, in order of importance:

  1. Nearly-constant priority tip fees, since overpayments do not get refunded
  2. Relatively steady base fees, since overpayments do get refunded (can set base fee to a multiple of the current block’s to ensure mining)
1 Like
  1. During high demand, the baseFee rises around 2x in ~12 seconds. This results in poor UX. The gas predictability that was one of the promises of the EIP was still true, but the short block time made the predictions more erratic in practice.

Just want to correct a possible misunderstanding here. A rapidly rising base fee isn’t bad for UX, the core issue here is that Polygon blocks easily drop into the thousands of wei for extended periods of time (e.g. https://polygonscan.com/block/24423730), making it very difficult for the base fee to respond quickly to surges in demand. Under these conditions, the base fee change rate is actually too low.

See here:

With the base fee this low, the system devolves into pre-EIP-1559 incentivation, where users must now compete against each other purely on the basis of priority fees (and very little of the Matic token supply is burned). If anything, the base fee change rate should be increased in order to respond to volatile changes in demand, or a minimum floor on the base fee should be imposed.

1 Like
  1. seems to be a good choice, considering the recent network congestion and high gas fee issue caused by the sunflower farming dapp (expected to be a DDOS attack), since such events may occur in future as well and soar the gas prices to the highest possible. Increasing the block limit wont be of great help, as it can result in the empty blocks production during high traffic.
    Option 4 can be considered too (if polygon community supports it).

If I could make a suggestion, I think it’s a bit difficult to reason about the possible options and how they’ll actually affect the behaviour of the network. Maybe a good thing to try is to model the system, and simulate how the different changes affect various metrics such as average transaction confirmation time under different network conditions (low vs high utilization). It would require more effort, but having concrete data to make the decision would be better than choosing an option, and then potentially having to hard fork again if more improvements are needed (imho).

Not sure I understand the history but am confused why EIP1559 was deployed on Polygon PoS as it was designed for a PoW network (ETH 1.0). Stable and low gas combined with a reliable network are what made Polygon popular so I vote for #4 until alternatives are proven ready to scale. This said, I agree with naivesheep that it is difficult to reason through these options and the implication of changes so take my advice with caution.

Hi guys,

Where can we found in Polygon documentation about what was selected ? I see EIP1559 in application but nothing that explain what was done on Polygon ?

Hi. You can see the available documentation in the [wiki] in terms of sending transactions under EIP-1559(How to Send EIP1559 Transactions | Polygon Wiki).
As for the EIP implementation, based on my understanding is exactly the same as Ethereum.

Yeah I saw this page but it just say how to make a type2 transaction. About the EIP implementation, I thought the gas limit for a block on Ethereum was constant (30milion gas) but for Polygon it seems to vary over blocks.