GasEstimation: improvements, research, and next steps

[arajasek]

Our current approach to gas estimation is broken into two pieces:

• Ethereum-style estimateGas: simulate the transaction in question on a node, and use the result
  • We do this for the consensus chain and Arbitrum
  • This is arguably more accurate, but slower and buggy when we need to send out many txs at once
• Naive method: estimate a number locally based on known constants and the advertised gas limits of XMsgs
  • We do this for all other chains
  • This works well for the chains we use it for, but might be brittle due to differences b/w testnets and mainnets, changing gas costs, any drawbacks to overestimations.
  • We also use this to solve the knapsack problem (fitting as many XMsgs as possible while respecting the block gas limit)

While no work is necessary today (this is not a blocker), some concrete steps we can take include:

• Improving the Naive method: can we expand to perhaps a table of constants, or factor in dynamic L2 gas pricing to get satisfactory correctness with this approach?
• Research: what, if anything, are the costs to overestimating gas? What happens if we just always set a very high number close to the block gas limit?
  • Quick research suggests the only problem is that message selection logic might avoid such messages (since the gas rewards earned by miners is reduced), but we don't really know yet.
• Research: Is our approach to the packing (knapsack) problem okay?
  • How are block gas limits set in our supported chains? (is it just a constant?)
  • If they're dynamic, does our approach safely (if conservatively) split up into small batches?

[arajasek]

Assigning this to Mainnet V1, as we can improve the relayer's performance, costs, etc. by doing this. We will get more info as we are on Public Omega with more real-world data.