Calling a non-view function within a contract in order to estimate gas for its execution

[miguelmtzinf]

Hi,

I am using hardhat-ethers plugin for hardhat and facing some problems with gas estimates while executing transactions within a contract (mainnet). I am facing some problems estimating the gasPrice for the transaction. Hardhat execute an eth_estimateGas to my node in order to calculate the gasLimit of the tx but the gasLimit calc provided by my node is awful...

So, I am searching for alternatives to calculate my tx gasLimit and I wonder if calling the non-view function with a simple call could be the way.

I know this is the ethers.js repo, so my question is, how can I make a simple call to a non-view function within a contract?

Using vanilla ethers it could be done creating a contract factory with no wallet (only provider), am I right?
Using hardhat-ethers and getContractFactory helpers, is it possible to do it? (as signers are included by default).

Thanks in advance,

[zemse]

I am facing some problems estimating the gasPrice for the transaction. Hardhat execute an eth_estimateGas to my node in order to calculate the gasLimit of the tx but the gasLimit calc provided by my node is awful...

Can you please provide more info on this? Like what problems are there with eth_estimateGas on hardhat.

how can I make a simple call to a non-view function within a contract?

I guess you mean a STATICCALL (view/pure like call) to a non-view method. In that case you can use contractInst.callStatic.methodName(). (docs). But I don't know how this would help you to calculate gasLimit, maybe this is not what you're asking. I'm not aware of any other handy way, other than eth_estimateGas rpc. Though it is possible to calculate the gas the way EVM does in js, if your contract code is simple, you could at most guess it if you know the ops that would take place and it's cost (e.g. 3 SLOADs + 2 SSTOREs), it'd be a super rare case if one would use this way.

[miguelmtzinf]

@zemse thanks for your reply

Basically, I do not get an accurate gasLimit from my provider when using eth_estimateGas, so when I execute the transaction I got an OOG exception spending all my gas fee... I think the eth_estimateGas did not work well since my geth node was not able to estimate the gas correctly due to complex/external calls involved in the execution. What is your opinion about this? An alternative to this is give a surplus of gas to the estimated gasLimit provided and give a try.... but I would not like to get an OOG again as you may guess.

Well, my thought was using STATICCALL in order to simulate an execution of the function and in this way, get a manual gas estimate, but I am not sure that this way can work (neither the staticcall can give me this type of information). Any insight about this?

Thanks in advance

[zemse]

I think eth_estimateGas is a variation of STATICCALL that returns the gas it consumed instead of return value in the call.

Due to the complex txs, if the estimate is going to be different everytime, you can try taking multiple estimates and the max of these estimates could be a number that would probably be close to the longest execution path. More the tries, more it will be closer. You can make the final gasLimit a bit higher than the largest gasUsed with a guess. If accuracy is important here, you can use the existing tries vs gasUsed data to extrapolate gasUsed for infinite tries. Does this make sense?

Edit: Also, you mentioned that you use geth. Is that correct or do you use the evm that comes with hard hat? Just asking because I am suspecting some issues with estimate gas in hardhat evm.

[miguelmtzinf]

Thanks for your tips @zemse ! I will go for it and get back to you with some feedback!

Edit: Also, you mentioned that you use geth. Is that correct or do you use the evm that comes with hard hat? Just asking because I am suspecting some issues with estimate gas in hardhat evm.

I am using my own geth, but yes, I am afraid something is wrong with hardhat gas estimate config...

[ricmoo]

@zemse suggestions are spot on.

One additional thought I have is that Hardhat might use ganache under the hood, which may be part of the problem.

Otherwise maybe your contract uses now which makes for unpredictable execution costs. You might want to try hard-coding a value for the gas limit you know will always work. This will bypass estimateGas entirely. Remember it doesn’t hurts to provide a gasLimit which is too high, as you will be refunded for any gas that is not used. You do have to have enough funds to cover that limit though, so there is a UX reason to not make it unnecessarily high though.

If you find a gas limit that works well, you can add it to the ABI. For a JSON ABI, use the property gas on the method. For Human-Readable ABI, add it with an @ symbol, like "function transfer(address to, uint amount) @5000. In either case, the transaction’s intrinsic cost will be added to this value for you. That may sound complicated, but you shouldn’t have to worry about it too much; the intrinsic cost is usually around 21000, so if you find a hard-coded value that works, just subtract 21000 from it and add it to the ABI. Or just leave the 21000-ish as a buffer.

I personally usually just pick some large value like 500k gas. Once the execution is successful for a few different runs, I look at the actual gas used and pick a value higher than the worst case that looks nice. For example, if I see 55678, 67332 and 67312 gasUsed, I would probably pick 85000 as a hard-coded gas limit in the ABI.

It does depend a bit on the code though. If there are arbitrary loops or external calls you may want to make something more parameterized...

[ricmoo]

Did that work for you? If so I'll close this issue. :)

[miguelmtzinf]

Yes, sorry of the silence.

As you both said, the interaction with complex contracts made difficult to estimate the tx gasLimit. So, my best option was to perform multiple tries to estimateGas, and I was thinking about the possibility of sending a trial tx to a mainnet-fork network in order to make sure the gasLimit is high enough.

Nevertheless, IMO the easiest workaround here is to provided a large amount of gas (as much as your wallet can provide).

Thanks guys @zemse @ricmoo