-
Notifications
You must be signed in to change notification settings - Fork 20.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The gasUsed of each EVM call is not clear. #28074
Comments
The trace you posted doesn't seem to match the transaction hash. The input is different on etherscan. But it's strange that the |
Thank you for your correction. I have edited the comment and post the correct transaction trace. I have found many transactions like this. And I really curious about the reason. |
Strangely enough what's wrong is the gasLimit, not gasUsed. What's reported in the trace doesn't match tx's gas limit. But this doesn't seem to be happening for all the txes. Trying to figure out in which case this happens. |
Can you please find a recent tx (last 128 blocks ideally) for me to reproduce locally? Also which version are you running on? |
I could explain the difference between transaction gaslimit and trace limit. The trace limit is calculated by the transaction gas limit minus accessList gascost, calldata gascost and 21000 (transaction base cost). |
I think you can try the transaction hash: |
The gas limit issue was fixed 5 months ago #27029. I think Alchemy hasn't updated their nodes. But you said there's something else? |
Thanks for your introduction. But my question focus on the gas refund. I notice that transaction remaining gas is higher than the last call remaining gas. |
According to this https://etherscan.io/vmtrace?txhash=0x3200bdf43b3f7290181da46b9996e09c2135625dd3d9358adc0e2b5aa5029e07&type=parity that's not the last call. The last call has 62635 gas and usage of 534 which turns out to be 62101 remaining gas. |
Yes. But please notice the action[9]. The gas is 76550 and gasused is 22433. You mentioned is the last subcall. I used the last topcall to calculate. Is there any mistake? |
Ah of course you're right, my bad. To see the refund you can do
Yes it includes. |
Oh! Thanks. And I want ask if there is any rpc to get the debug.traceTransaction('txhash') result for gasrefund. Again, I want to ask if I want to simulate the trx locally, Can I get the trace information about gasrefund and how. |
Yes there's an RPC method with the same name. |
Really thanks for your help. And I want to if you know some ways to get trace for those transactions that I want to send (I want to check the gas_refund) using any framework. I am using hardhat for testing, but it seems its 'debug_transaction' rpc method will not return gasrefund result. |
AFAIK, the opcode tracer will return the results by each op, I don't think there's any way yet to extract the callTracer's refund gas. Maybe we can make this happen after #27629 got merged |
supertracer FTW |
It does give you the current stand of the refund counter at each opcode. It should be enough to get an idea. Here is the refund value for the last opcodes in the trace. The last stand was 22700. But that doesn't mean all of it will be necessarily refunded. The refunds are capped to
Yes you will need a geth node. I can't help with hardhat unfortunately. |
Closing the issue. Please re-open if you think the remaining gas value is incorrect. |
Sorry I want to ask what is supertracer, I do not find any information about it. |
Sorry, it was a joke comment. There is a proposed change to go-ethereum, #27629, that would make it possible to create traces during processing of blocks. It could help with your problem if we had that change in, that's why I wrote the comment. |
I am analysing the gas used distribution in a transaction. Here is a trace example and my analysis result. I am curious about why the calculated remaining gas is larger than the gas after the final call. (40554 > 36662)
Does any gas refund that I do not consider. How can I correctly get the gas used in each evm call.
The text was updated successfully, but these errors were encountered: