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:
- The average block capacity is around 10M, compared to 20M earlier. This means that, at an average, the network throughput is around half.
- 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.
-
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.
-
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.
-
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.
-
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).
