Author: Zsolt Felfoldi (zsfelfoldi@ethereum.org)
This proposal describes an EIP-1559 compatible priority fee suggestion scheme that can be considered a generalization of the current "gas price oracle" implemented in Geth. We define minReward for each block so that it is either the smallest effective miner reward paid in a given block or a low (user specified, cca 5-10%) percentile of tx miner rewards in ascending order, weighted by gas used. The latter option is slightly more complex to calculate but also more reliable because it can't be distorted by miner created transactions where the paid priority fee is not really meaningful.
Instead of suggesting a single priority fee value based on the minReward of a fixed number of recent blocks, this scheme has a positive integer parameter i which means the API can choose to display a series of values which might also be more informative to the user. Using a single value of i is also possible, a value of 3 or 4 yields a behavior similar to the current GPO. suggestPriorityFee(i) is defined as the second lowest minReward of the last i+1 blocks. The rationale behind this is that though with EIP-1559 it's still possible to experience first price auction situations with the tip, these "tip peaks" are always expected to be short (proportional to the logarithm of the base fee increase ratio). Therefore in a congestion the short term past history of miner rewards is a good indication for the short term future while the longer term past is a good indicator for the longer term future. The parameter i can be explained as an "urgency parameter" that is not a direct indication of the expected number of blocks needed to include the tx but still it's more or less proportional to the actual expectations (a smaller number indicating an earlier inclusion).
The UI can present suggestPriorityFee(i) as a bar graph or piecewise linear monotonically decreasing curve, allowing the user to choose a speed vs cost tradeoff (thoguh it's important to note that sending in the transaction with a low priority fee might not necessarily yield a lower overall cost because of the baseFee increase; in this case waiting out the peak might be a better option). Such a graphical representation would also serve as a congestion indicator. If it's close to flat then no high priority fees were used recently and we can assume that a similar low fee will be sufficient. If there is a huge spike for the first few i values then the user can decide between trying to offer a similar large priority fee and get in early or wait out the congestion. Drawing the recent history of baseFee values could also help with this decision, though I don't think we should try to algorithmically predict future of base fees. So the suggested maxFeePerGas can simply be the suggested priority fee plus 2* the current baseFee.
open