gas_used/gas for the root trace should use tx's

[jsvisa]

Describe the bug

For this tx 0x00f139f7deb8b18d27bbed972720ba4e8a3b7d9806b186bdb29cdbfff3b95a9e,

we request the result as:

{
  "jsonrpc": "2.0",
  "method": "trace_transaction",
  "id": 67,
  "params": [
    "0x00f139f7deb8b18d27bbed972720ba4e8a3b7d9806b186bdb29cdbfff3b95a9e"
  ]
}

the response is:

{
  "id": 67,
  "jsonrpc": "2.0",
  "result": [
    {
      "action": {
        "callType": "call",
        "from": "0x93f3ef9fa5e668b0ccf5ad93e53f991aaea6131c",
        "gas": "0x1068",
        "input": "0x",
        "to": "0x28c6c06298d514db089934071355e5743bf21d60",
        "value": "0x12134e80a17c78e"
      },
      "blockHash": "0x92486dfdb758642482f94049048abbef3d6c6aeaeaac30df0e005473d6a83f05",
      "blockNumber": 17626652,
      "result": {
        "gasUsed": "0x0",
        "output": "0x"
      },
      "subtraces": 0,
      "traceAddress": [],
      "transactionHash": "0x00f139f7deb8b18d27bbed972720ba4e8a3b7d9806b186bdb29cdbfff3b95a9e",
      "transactionPosition": 349,
      "type": "call"
    }
  ]
}

The gas and gas_used are incorrect, these two values should be taken out of the transaction structure, see more in this pr ethereum/go-ethereum#27029

Steps to reproduce

⬆

Node logs

No response

Platform(s)

Linux (x86)

What version/commit are you on?

1330fc1

What database version are you on?

No response

If you've built Reth from source, provide the full command you used

docker build

Code of Conduct

• I agree to follow the Code of Conduct

[mattsse]

hmm,
I thought I added this

#3594

need to double-check what I'm missing

not sure why this is even 0, perhaps some price snafu

EDIT:
comparing this to geth isn't really helpful, because geth doesn't have this endpoint, how does erigon behave her @jsvisa ?

[jsvisa]

Erigon’s response is also incorrect. You can use debug_traceTransaction api?

[mattsse]

You can use debug_traceTransaction api?

can you elaborate?

[jsvisa]

You can use debug_traceTransaction api?

can you elaborate?

this API?

{
  "jsonrpc": "2.0",
  "method": "debug_traceTransaction",
  "id": 67,
  "params": [
    "0x00f139f7deb8b18d27bbed972720ba4e8a3b7d9806b186bdb29cdbfff3b95a9e",
    {
      "timeout": "120s",
      "tracer": "callTracer"
    }
  ]
}

by the way, I think the refund's logical is too complicated. IMO, for the root trace, the gas and gas_used use the transaction's is a simple implementation.

[mattsse]

there's no real spec for any of this, I can see the argument for using the tx's values for the root call trace, but imo that should represent the root call, but I'm also not entirely familiar with evm internals here

need to think about this

[jsvisa]

@mattsse thanks for it.

BTW, May I ask if Reth generates and stores traces to the database during synchronization? If so, this means the RPC requests directly read traces from the database instead of replaying to generate them like Geth does.
If that is the case, then for traces with flawed generation logic - even if the bug is fixed, because the data will not regenerate, the RPC will still get incorrect data since it is reading the old faulty data from the database. So for this case #3427 (comment), I did need to resync the reth node

[mattsse]

if Reth generates and stores traces to the database during synchronization?

it does not, traces are generated entirely by replaying the transaction on the fly

[jsvisa]

if Reth generates and stores traces to the database during synchronization?

it does not, traces are generated entirely by replaying the transaction on the fly

thanks, but for the Genesis accounts, I did need to resync?(because the bug I raised was not fixed)

[mattsse]

thanks, but for the Genesis accounts, I did need to resync?

yes

because the bug I raised was not fixed

which one?

[jsvisa]

which one?

#3427 (comment)