[General] RPC Gas Estimates are inflated

[jayantk]

Team or Project

Pyth Network

Environment

Testnet

L2 block number

No response

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

I am developing the Pyth Entropy random number generator on Abstract Testnet. This is a follow-up to the previous discussion here: #877

I am still having problems with the RPC gas estimates, which now dramatically overestimate the gas used by the transaction. The gas estimates routinely seem to overestimate the gas used by a factor of 5 to 10. For example this transaction had a gas estimate of 800k, but only used 90k.

https://explorer.testnet.abs.xyz/tx/0xabae5b8807b1efc3c4f55b63565e5c52f0b50d12ed63b010ec7e0e8e91ffccb2

I think the fix to the prior issue changed the gas estimate to correspond to the amount of gas necessary to get the transaction to land on the blockchain (as opposed to the amount the tx actually uses).

If I had to choose, I would prefer the previous behavior over the new behavior. The previous behavior was easy to work around with a gas escalator to land transactions, whereas the new behavior makes it very difficult to predict gas usage.

Repo Link (Optional)

No response

Additional Details

No response

[popzxc]

Hello! The fix that was done changed the fee configuration parameters. In short, the system works as follows:

There are two main "weight" factors: compute_overhead and pubdata_overhead. The sum of those parameters must equal 1, and if compute_overhead is higher, the model prioritizes the compute component of the transaction execution, while with pubdata_overhead dominating, the model prioritizes covering the published pubdata.

In practical terms, in the first case we will have higher values for gas_per_pubdata and thus overall gas limit. In the second case, gas_per_pubdata will be lower, but the compute will be more expensive. Prior to the fix, the fee model on Abstract was biased towards pubdata costs, which made it sensitive to the L1 gas price changes.

Now, it's biased towards the compute costs, and matches configuration from Era testnet/mainnet.

However, there is one more component to the fee model: we use pubdata compression, and slots that were touched multiple times are "aggregated" into one state change, and the refund is issues for the data we no longer have to publish.

If you look at the transaction you linked, you can see in the fee details:

• Initial: 0.00004378575 ETH
• Refunded: 0.000041395725 ETH

So, the estimate was correct; it's just most of the fee was refunded. The impact of the refund became more noticeable, since the amount of gas per pubdata increased.

Note that we have a trade-off here: if we increase the "compute" part, the users will be charged more for spending L2 gas on calculations, where no refunds are available, making the fees higher on average (with some assumptions), although the fees will become more predictable (because there are no refunds for computation). For users, having high "pubdata" component appears to be desirable, since it lowers the fees thanks to the refunds.

The decision on what to prioritize in the fee model configuration should be made by the Abstract team, I will pass this request to them.