[Dev Tools] Discrepancy between gas cost computed inside paymaster and from tx response

[cesarenaldi]

Team or Project

No response

Environment

Testnet

Select the Dev Tool you are using

Hardhat Plugins

Provide the version of the tool (if applicable)

No response

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

I am running HardHat test against our Paymaster implementation.

I am seeing a discrepancy between the gas cost computed inside our paymaster:

uint256 gasCost = transaction.gasLimit * transaction.maxFeePerGas;

and the one computed in the same way from the tx response (ethers.js):

const gasCost = response.gasLimit * response.maxFeePerGas!;

The outer one is slightly more. This is with the era in-memory node.

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

It appears you are encountering a discrepancy in gas cost calculations between your Paymaster implementation in Solidity and the transaction response handled by ethers.js. This issue might be due to several factors:

1. Gas Estimation Differences: The gas cost computation within the Paymaster and the transaction response might differ due to how gas estimation is handled by the Ethereum client and the Hardhat environment. The in-memory node used by Hardhat might simulate gas costs differently compared to actual on-chain execution.

2. Transaction Parameters: Ensure that the transaction.gasLimit and transaction.maxFeePerGas in your Solidity code exactly match those used in the transaction sent via ethers.js. Any slight variation in these parameters can cause discrepancies in the computed gas costs.

3. Hardhat Environment: The Hardhat in-memory node might not fully mimic the gas pricing mechanics of a live Ethereum network, especially if it involves complex interactions like those with a Paymaster.

4. Solidity and JavaScript Precision: Differences in how Solidity and JavaScript handle arithmetic operations, especially with large numbers, might also lead to slight discrepancies.

To further investigate and resolve this issue, consider the following steps:

• Double-check the transaction parameters (gasLimit and maxFeePerGas) to ensure they are consistent across your tests.
• Review the Hardhat configuration for any settings that might affect gas estimation.
• Consider deploying and testing against a public testnet node to see if the discrepancy persists outside the Hardhat environment.

For more detailed discussions and support, you might want to visit the ZKsync developers discussions on Github.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[kaymomin]

Hi @cesarenaldi, could you please provide the paymaster contract source code you are using to reproduce the error?

[cesarenaldi]

Would this be enough?

https://block-explorer.testnet.lens.dev/address/0x115B6D4aED14AD0F900a20819ABDAf915111bf50#contract

[cesarenaldi]

Implementation: https://block-explorer.testnet.lens.dev/address/0x534B89ea1ce82b2953F0eA662b42fDAcF03D4F0B#contract

[kaymomin]

Thanks! Passing this along to the team to take a look.

[kaymomin]

Hi @cesarenaldi - The discrepancy you're noticing is expected behavior when interacting with a paymaster. Paymaster txs typically consume more gas than standard txs due to additional computations and operations involved in the process.

For a detailed explanation of how gas estimation works with paymasters, check out the documentation here: Estimating Gas with Paymasters.

Let me know if there's anything I can clarify!

[cesarenaldi]

Sorry I don't understand. We do follow the mentioned guide and during estimation we handle the magic return value so that the same exact code that runs during estimation runs when executing the transaction.

So, AFAIK, the gas estimated within the paymaster Transaction are accurate.

What I don't understand is how the actual gas used can be higher. I also double checked with the paymaster balance before and after the transaction and indeed we spent more gas than estimated.

[cytadela8]

Hi @cesarenaldi I checked the code you provided in private, but could not reproduce this issue. Based on my test run response.gasLimit * response.maxFeePerGas! is equal to the value used internally by the Sponsorship contract. Let's discuss this on Slack unless you can give me some publicly available example to reproduce this.

[cytadela8]

I think I understand the discrepancy. It comes from:

function balanceOf(address account) external view returns (uint256) {
        if (_isOwner(account)) {
            return address(this).balance - _grantsBalance();
        }
        return grantReserves[account];
    }

When checking balance of "deployer"/"owner" you are not checking the internal accounting, but the actual balance of paymaster. This mismatches. The change in balance of paymaster is not response.gasLimit * response.maxFeePerGas!, but generally less than this value (gasPrice may be lower then max and gas usage may be lower then limit). When fetching "balanceOf(deployer.address)" you are fetching the actual balance of paymaster account minus all the internally accounted grants. Thus after each transaction "balanceOf(deployer.address)" will increase by the difference between response.gasLimit * response.maxFeePerGas! and the actual fee.

I would recommand rewritting your smartcontract to avoid updating grantReserves after/during each paymaster transaction. I would only account the fee spending periodicaly when performing other actios by subtracting the difference between expected paymaster balance and actual balance. A pseudo code of this would look something like this:

modifier beforeGrantChanges {
        uint feesSinceLastUpdate = grantsTotal - this.balance;
        _deductFromGrantReserves(feesSinceLastUpdate);
        grantsTotal -= feesSinceLastUpdate;
    }

[cesarenaldi]

Thank you for the detailed explainer and for taking the time to make changes to investigate.

The change in balance of paymaster is not response.gasLimit * response.maxFeePerGas!, but generally less than this value

This makes sense, still what I reported does not contradict your statement. What I am experiencing is a larger value from the tx response vs. the one during gas estimation.

Said that, once we clarify the source of the discrepancy, we should have a more accurate accounting of gas spent. Would the postTransaction function be of any help here to know the more accurate gas used at contract level?

[cesarenaldi]

Oh yes, you are correct! Since I am checking the remaining balance it's ok to see more balance than actually estimated.

So now, my second question is even more valid. Is it possible, maybe through refund mechanisms (?), to infer how much was actually spent from within the contract?

[cytadela8]

Hi, there is a good answer for a similar problem here. Basically, you cannot unfortunately get an exact fee paid by a paymaster during paymaster execution in the transaction. You can improve your estimation by using _maxRefundedGas in postTransaction as explained in that discussion.

I would recommand going with the approach I proposed above and avoid accounting the spending immediately during the transaction. I would observe the difference between the last recorded paymaster balance and the current balance during each operation where funds are moved (deposited or withdrawn) outside of a paymaster transaction. This way you can accurately and in bulk account the transactions. As an additional benefit, you would lower the gas usage during paymaster transactions.

[cytadela8]

I want to add that postTransaction is not guaranteed to be executed after each transaction. It will not be executed, for example when the transaction runs out of gas. You can read more about this here.

I'm going to close this as answered for now. Please don't hesitate to mark it as unanswered if you have any more questions.