Parity TraceTransaction – Understanding Response Values

contract-debuggingevmparity

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?

Best Answer

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.