8

Parity implements a really useful trace module for deep diving into blocks and transactions.

One particular method trace_transaction allows you to investigate the EVM execution paths of a transaction.

It is not however clear in the documentation what the various response values represent.

Most of the values are (I believe) fairly obvious. The ones that are confusing me are gas within the action property of the result, and gasUsed within the result property.

I assume that they represent the maximum gas available at that given step, and the amount of gas used by that step respectively BUT a the initial gas value does not equal that sent with the transaction and a summation of the gasUsed values does not equal the value for gasUsed returned by a call to getTransactionReceipt.

An example.

This (random) transaction on the Ropsten testnet.

The first call has a gas value of 576552 whereas the transaction was submitted with a gas limit of 600000.

The summation of gasUsed values is 102979 whereas a call to getTransactionReceipt returns a total gas used of 93518.

The Geth debug modules also shown a difference of 93518 between the first and last EVM commands.

Can anyone clear up what these values actually represent?

Improve this question

1 Answer 1

Reset to default
12

Having heard nothing from anyone working at Parity I went ahead and investigated this further.

The gasUsed property returns the amount of gas utilized by that step. The first trace (that with a null traceAddress) represents the user submitted transaction. All other traces are sub traces e.g the function you called calling another function.

The gasUsed for the initial trace does not include the default transaction cost of 21000 OR the input data costs of 4 for zero byte data and 68 for non-zero byte data. This is outlined in the yellow paper (page 20).

If you take the gasUsed value of the initial trace, add 21000, and then calculate the input data costs then you do get the gas used value returned by getTransactionReceipt.

Whilst I am here, to calculate the input data cost, remove the 0x prefix, and split the hex input data every two characters (each hexadecimal character is 4 bits).

0xa600bc is made up of three bytes of data: a6, 00, and bc. That is two non-zero bytes and one zero byte.

This does not explain why Parity return the gasUsed in this manner. It could really do with being documented.

Improve this answer
3
  • 2
    This is absolutely excellent. Thanks so much for posting it. I am going to go off now and double check that what you're saying is correct. If I never return, then assume I found that the above answer is correct. If I find it is incorrect, I promise to return and let you know. (April 23, 2018) I agree it needs to be documented. Also, geth and parity should agree on what traces look like.
    – Thomas Jay Rush
    Apr 23, 2018 at 13:13
  • Hello, could anyone post a "workable" command line of the trace module? Do I need to first "sync" the blocks locally and then use this command?
    – lllllllllllll
    Nov 29, 2018 at 14:39
  • The documentation outlines how you can make a trace call from the command line using CURL. You do need the blocks to be synced.
    – Thomas Clowes
    Nov 29, 2018 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.