Pre-PIP Discussion: Addressing Reorgs and Gas Spikes

Polygon Improvement Proposals Proposal Ideas
5

@pgo You nailed it. You’re correct about my comment on legacy gas pricing being somewhat informal. It’s actually a topic that I don’t have a high-conviction opinion on one way or the other, but I do enjoy discussing it and I do believe that the matter isn’t as “settled” as many others believe. This probably isn’t the place for it, but if you’re curious and have some free time then maybe we could connect in telegram (@thogard) or discord (thogard#3282) and go over some of the more nuanced elements of that EIP and some issues I’ve found in the studies conducted on it.

Regarding the proposed changes:
My own mental model is still stuck on the mechanism by which decreasing the baseFee’s rate of change (delta) will lead to more reliable estimates from wallets. I’m going to lay out my thoughts, along with some formulas, below. I assume you’re familiar with most of this but am going to be thorough for the sake of other readers.

The criteria we’re evaluating is a wallet’s capacity to provide an estimate for gas parameters that will place the transaction in a block within the next ten seconds or so.

In EIP-1559, there are two market forces at play:

  1. The base fee
  2. The priority fee (EffectiveGasTip)

By decreasing the max delta of the base fee, it feels like a wallet should be able to provide a more reliable estimate… but once we look at how these numbers are calculated then I’m not sure that’s actually true.

Under the hood, a Type 2 transaction has two “gas price” parameters: maxFeePerGas and maxPriorityFeePerGas. The two parameters are exactly what their names imply - maxFeePerGas is the maximum (capped) total gas price, and maxPriorityFeePerGas is the maximum (capped) miner tip. While the wallet is responsible for providing an estimate for these two parameters, it’s important to note that the wallet does not set a “base fee” parameter. In fact, transactions don’t even have a baseFee parameter – the baseFee exists solely in Bor/Geth’s miner/worker process (it’s not even accessible inside the EVM).

But the baseFee is still factored into how much the user actually pays in gas fees: it is the mining parameter through which the difference between maxFeePerGas and maxPriorityFeePerGas manifests. The formula is:

GasPrice = minimum(maxFeePerGas || baseFee + maxPriorityFeePerGas)
(Note that maxPriorityFeePerGas cannot exceed maxFeePerGas)

also note its sister-formula:
EffectiveGasTip = minimum(maxFeePerGas - baseFee || maxPriorityFeePerGas)
and therefore
EffectiveGasTip = GasPrice - baseFee

So with that in mind, here’s why I’m struggling to understand why decreasing the base fee’s max delta will help the wallet estimators:

  1. If a user’s transaction fails to be included in a block, it’s because their GasPrice was too low.
  2. GasPrice is the lesser of two separate parameters (maxFeePerGas and baseFee + maxPriorityFeePerGas).
  3. The only scenario in which lowering the max baseFee delta would allow an otherwise excluded transaction into a block is when the baseFee would have otherwise increased above the user’s transaction’s maxFeePerGas.

But this is actually the exact scenario which EIP-1559 was designed to handle. User’s can safely set an exorbitantly high maxFeePerGas (and a low maxPriorityFeePerGas) and rest assured that not only would the scenario above be prevented, but if the baseFee actually drops then their effective GasPrice will also drop (because it’s de-facto pegged to the baseFee in this scenario) and the user will save money. The only downside to setting a high maxFeePerGas is that the user may have to actually pay it if the baseFee increases enough to warrant it… but they can rest assured knowing that if they do have to pay a high maxFeePerGas then that means there was no other way to be included in the block. In fact, this potential for confidence in savings is one of the strongest arguments in support of EIP-1559.

The other side…

My concern with decreasing the max baseFee delta is the potential side effect it will have on EffectiveGasTip needed for block inclusion. If a spike in GasPrice does happen, any users who are priced out of the network due to their wallet using a low maxPriorityFeePerGas estimate could have their tx delay increased. This is because:
(For reference: EffectiveGasTip = minimum(maxFeePerGas - baseFee | maxPriorityFeePerGas))

  1. It will take longer for the baseFee to rise
  2. It will therefore take longer for maxFeePerGas - baseFee to become less than maxPriorityFeePerGas (and therefore become the EffectiveGasTip)
  3. It will therefore take longer for an erroneously low maxPriorityFeePerGas parameter to become irrelevant to the miner.

In general, though, I’m just very skeptical that during high-demand time periods we won’t see an artificially reduced baseFee manifest itself via supply and demand as an artificially increased EffectiveGasTip… and I believe the the latter is harder to control / plan for than the former, specifically when accounting for the changes introduced by EIP-1559 that were specifically added to help control these scenarios.

Some thinking out loud (low conviction thoughts):
The more I think about it, the more I want to gather some data on “stuck” transactions. It would be relatively straightforward to ascertain which of the two transaction parameters (maxFeePerGas or maxPriorityFeePerGas) is responsible… Or if both being too low is actually the most common cause for delay. Furthermore, we could fairly easily simulate exactly what would happen if we decreased the max baseFee delta.

I’d also propose that if the majority of “stuck” transactions are “stuck” due to a low maxPriorityFeePerGas estimate then it might be worth considering moving the opposite direction and actually increasing the max baseFee delta.

Would love to hear your thoughts on this or any clarifications/corrections if I’m missing something.

Side note: I can’t help but think that changing the blockchain’s block construction process to accomodate the inaccuracies in the estimates of third party programs is kinda backwards. Perhaps approaching the wallets / gas price oracles directly would be a simpler solve? I’m also curious to see if there are any strange interactions between gas price estimators and the 30gwei price floor.

3 Likes