[SDK] Calculation of the required gas estimateGas

[RomanYarinski]

Environment

Mainnet

Acknowledgement

• I understand that issues are expected with the Go SDK as they are being updated.

Issue Description

There is a dependence of transaction cost estimation on the gas limit.
It turns out that if you use the standard gas estimate, the user will see highly inflated values of transaction cost.
But underestimating the gas limit can be dangerous, because the gas in the zkSync network is not static and can change due to network or L1 load. And if we set the gas limit too low, then the user will not be able to complete the transaction and pay the fee for nothing.

For this reason, there are questions:

1. How can we estimate the gas more accurately so that the user can see a more accurate estimate in Metamask?
2. Can we safely underestimate the resulting estimate to show the user a closer approximation of transaction costs. If we can, by what percentage? Since a transaction that by standard methods is valued at 4.2 million gas actually runs at a gas limit of 200,000.
3. Are there any practices to correct this?
4. Also wondering why the final transaction cost to the user will eat into what gas limit to set? For example, I set the gas limit as estimateGasValue * 0.7 and everything works fine and the transaction is much cheaper for the user after the refund compared to just estimateGasValue. In general, is this logic acceptable, how risky is it and what reduction coefficient can be used?

Expected Behavior

Estimation of gas showing a close estimate of gas to the actual value so that a user in metamask doesn't see $13 instead of 5 cents of the real value.

Code Example

With zkSync SDK

  const provider = new Provider(chain.rpcUrls.default.http[0])

  const data = encodeFunctionData({
    abi,
    functionName,
    args,
  })

  const zkSyncGas = await provider.estimateGas({
    to: toAddress,
    data,
    value: 0n,
  })

with Viem

const gas = await publicClient.estimateContractGas({
    address: toAddress,
    abi,
    functionName,
    args,
    account,
  })

Equally inaccurate

Repo Link (Optional)

No response

[RomanYarinski]

Thanks for the reply, are there any examples of gas estimation algorithms that have proven to work well?

Maybe there are clearer tips from the zkSync team on how to deal with this problem?

Possibly there is some other discussion of this issue that I can read?

[StanislavBreadless]

@RomanYarinski Note, that since state diffs are used, the subsequent transactions in a batch can have smaller fee due to the fact that they reused the state storage slots. So depending on the sort of the contract you are calling you can get very different cost of the first and the second call, but when estimating gas we never know whether your transaction will come as one of the first ones in a batch (and will have to pay the full price) or it will continue receiving the benefits of the previous transactions in the current batch that have already paid for the state changes.

Also, the calculations in the table seem to be a bit off. On the 23rd of February the gas price on zksync was around 0.1 gwei, in other words 4200000 gas would probably cost around 4200000 * 0.1 * 3500 / 1000000000 = $1.47 (I took the numbers from my head, but most certainly the price wasn't much different from this number), which is still off from the final gas used, but not by the large margin that is provided in the table