Inconsistent gasUsed field in flatCallTracer

[MqllR]

Describe the bug

When using the flatCallTracer, the resulting gasUsed field in a debug method seems inconsistent. Discrepancy detected between geth and reth payload but also when comparing callTracer output and flatCallTracer on the same reth node.

Steps to reproduce

Compare Geth vs Reth:

cast rpc debug_traceBlockByNumber 0x14de141 '{"tracer": "flatCallTracer"}' --rpc-url <gethendpoint> | jq '.[0].result[0]' > geth.json
cast rpc debug_traceBlockByNumber 0x14de141 '{"tracer": "flatCallTracer"}' --rpc-url <rethendpoint> | jq '.[0].result[0]' > reth.json
diff -u *eth.json
```

Will give:

```
--- geth.json   2025-02-26 13:53:41.999310647 +0100
+++ reth.json  2025-02-26 13:57:26.203167278 +0100
@@ -1,7 +1,7 @@
 {
   "action": {
-    "callType": "call",
     "from": "0x58e327d64fc77fa36f698989623c3e4f058c8a89",
+    "callType": "call",
     "gas": "0x7bdf0",
     "input": "0x9c078d2d000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000007391425ca7cee3ee03e09794b819291a572af83e0000000000000000000000000000000000000000000000000010f5082795260100000000000000000000000000000000000000000000000000000000693e5c260000000000000000000000000000000000000000000000000ebf7757cf8a199200000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000003127564a6da025bba44e1e4ac296e800d5afbda7000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000e6f8e488012db4daa15eeffea09dbdc61bd53d365b3159f9c97bb0110909f4910c0ea05c28ed31c18f016aa01b9452c397756a44122e0c4aec64d7d3c7f57948fa3080947391425ca7cee3ee03e09794b819291a572af83e94c02aaa39b223fe8d0a0e5c4f27ead9083c756cc28c012b52037b6de459140d29eb880181abdde23a21f6a0440000000000000000000000000000000000682c5b180000000000000000000080a0c49f7d4d5249c000b9b99efad914a9f0d75554adb564b6a11b575858f72c3ab7a0522b171d6d3d48c17fa0e440c0fd96e3e4cf95e9edede9a3f42b107cf0a2779900000000000000000000000000000000000000000000000000000000000000000000000000002dd766542b06450605da0b7dd99ed35d5424b04300000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000186f901838b0d291589e966616bb3280086010222f8bc0194c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2947391425ca7cee3ee03e09794b819291a572af83e9497b617da8396c5cc368f2f85209ee5e3df80b76c94000000000000000000000000000000000000000087b1a2bc2ec500008b52b7d2dcc80cd2e40000009da4000000a4000000a4000000a400000000000000000000000000000000b8a4bf15fcd8000000000000000000000000303389f541ff2d620e42832f180a08e767b28e10000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000242cc2878d0067d5211e0000000000000097b617da8396c5cc368f2f85209ee5e3df80b76c00000000000000000000000000000000000000000000000000000000b8415aad75050a16c4bd4a9c823af287c8dff78e6474eacfdffde32d3636456ea51d6008d4b26ec63a3939c2b9258ff74d8d4c6fdf665f7701596042c58e7cf30fe61b800000000000000000000000000000000000000000000000000000",
     "to": "0x00000000000ba9cd9f5175108141a82b6c24d727",
@@ -10,7 +10,7 @@
   "blockHash": "0xf33b6e3ed70b28978ad0369823682bcbd631e317dc1f7bcb5bf6fd10fc0b6718",
   "blockNumber": 21881153,
   "result": {
-    "gasUsed": "0x56083",
+    "gasUsed": "0x530b3",
     "output": "0x000000000000000000000000000000000000000000000000000b4e056fb8c4000000000000000000000000000000000000000000000000000000000000000000"
   },
   "subtraces": 1,
```

Using the `callTracer` on reth will also correctly give `"gasUsed": "0x56083"`

```
cast rpc debug_traceBlockByNumber 0x14de141 '{"tracer": "callTracer"}' --rpc-url <rethendpoint> | jq '.[0].result' | head
{
  "from": "0x58e327d64fc77fa36f698989623c3e4f058c8a89",
  "gas": "0x7bdf0",
  "gasUsed": "0x56083",
  "to": "0x00000000000ba9cd9f5175108141a82b6c24d727",
  "input": "0x9c078d2d000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000007391425ca7cee3ee03e09794b819291a572af83e0000000000000000000000000000000000000000000000000010f5082795260100000000000000000000000000000000000000000000000000000000693e5c260000000000000000000000000000000000000000000000000ebf7757cf8a199200000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000003127564a6da025bba44e1e4ac296e800d5afbda7000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000e6f8e488012db4daa15eeffea09dbdc61bd53d365b3159f9c97bb0110909f4910c0ea05c28ed31c18f016aa01b9452c397756a44122e0c4aec64d7d3c7f57948fa3080947391425ca7cee3ee03e09794b819291a572af83e94c02aaa39b223fe8d0a0e5c4f27ead9083c756cc28c012b52037b6de459140d29eb880181abdde23a21f6a0440000000000000000000000000000000000682c5b180000000000000000000080a0c49f7d4d5249c000b9b99efad914a9f0d75554adb564b6a11b575858f72c3ab7a0522b171d6d3d48c17fa0e440c0fd96e3e4cf95e9edede9a3f42b107cf0a2779900000000000000000000000000000000000000000000000000000000000000000000000000002dd766542b06450605da0b7dd99ed35d5424b04300000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000186f901838b0d291589e966616bb3280086010222f8bc0194c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2947391425ca7cee3ee03e09794b819291a572af83e9497b617da8396c5cc368f2f85209ee5e3df80b76c94000000000000000000000000000000000000000087b1a2bc2ec500008b52b7d2dcc80cd2e40000009da4000000a4000000a4000000a400000000000000000000000000000000b8a4bf15fcd8000000000000000000000000303389f541ff2d620e42832f180a08e767b28e10000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000242cc2878d0067d5211e0000000000000097b617da8396c5cc368f2f85209ee5e3df80b76c00000000000000000000000000000000000000000000000000000000b8415aad75050a16c4bd4a9c823af287c8dff78e6474eacfdffde32d3636456ea51d6008d4b26ec63a3939c2b9258ff74d8d4c6fdf665f7701596042c58e7cf30fe61b800000000000000000000000000000000000000000000000000000",
```

### Node logs

```text

```

### Platform(s)

Linux (x86)

### Container Type

Docker

### What version/commit are you on?

1.2.0

### What database version are you on?

Current database version: 2
Local database version: 2

### Which chain / network are you on?

Eth mainnet, sepolia... same behavior

### What type of node are you running?

Archive (default)

### What prune config do you use, if any?

_No response_

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

_No response_

### Code of Conduct

- [x] I agree to follow the Code of Conduct

[mattsse]

ah this is main callframe gas used vs tx gas used again

there's no clear spec on any of this but because flatcalltracer is just parity (trace_) traces this uses the main call gas used

this inconsistency is only on the first entry, right?

reth/crates/rpc/rpc/src/debug.rs

Lines 792 to 797 in a450370

	let (res, (_, tx_env)) =
	self.eth_api().inspect(db, evm_env, tx_env, &mut inspector)?;
	let frame: FlatCallFrame = inspector
	.with_transaction_gas_limit(tx_env.gas_limit())
	.into_parity_builder()
	.into_localized_transaction_traces(tx_info);

[MqllR]

this inconsistency is only on the first entry, right?

@mattsse no, not only for the first entry but for several of them. Here are few examples for the same block:

• tx hash: 0x221ec7115c3e629391b4c175406bb1257ceb2dced8f2c5f0273db73a711d54f5

       {
         "action": {
-          "callType": "call",
           "from": "0x9938b504bc088df8d5831cd53073f94333c24358",
+          "callType": "call",
           "gas": "0x2934b",
           "input": "0x000000000000000000000000000000000000000000000000000000000000000067b5f13
b0000000000000000000000002982d3295a0e1a99e6e88ece0e93ffdfc5c761ae00000000000000000000000077e06
c9eccf2e797fd462a92b6d7642ef85b0a44000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c7
56cc200000000000000000000000000000000000000000000000000000006bc56b4070000000000000000000000000
000000000000000000000003d4134dab8b43504000000000000000000000000000000000000304d27ddddf33400000
0000000000000000000000000000000000000000000000000000000000000000000000000",
           "to": "0xeff6cb8b614999d130e537751ee99724d01aa167",
@@ -1350,7 +1349,7 @@
         "blockHash": "0xf33b6e3ed70b28978ad0369823682bcbd631e317dc1f7bcb5bf6fd10fc0b6718",
         "blockNumber": 21881153,
         "result": {
-          "gasUsed": "0x1981a",
+          "gasUsed": "0x13e12",
           "output": "0x"
         },

• tx hash: 0x489b6bc447f62b0ba7cb54032c1d24eeb90182f634aa1ce143ac8df52ab94fb7

         "blockHash": "0xf33b6e3ed70b28978ad0369823682bcbd631e317dc1f7bcb5bf6fd10fc0b6718",
         "blockNumber": 21881153,
         "result": {
-          "gasUsed": "0x1b025",
+          "gasUsed": "0x16101",
           "output": "0x0000000000000000000000000000000000000000000000000000000000000020000000
0000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000
00000000000002a98146bf7890000000000000000000000000000000000000000000000006743bd06c10fe1366e9"
         },

But since you mentioned that flatCallTracer is just parity traces, I compared a trace_block against reth vs erigon and both answer with the same payload.

What remains weird is the callTracer inconsistency.

[github-actions]

This issue is stale because it has been open for 21 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.