`debug_traceBlockByNumber` gives a `0x00..00` transaction hash on pre-bedrock blocks

[sbvegan]

This issue was reported to me and I'm relaying it here.

System information

Archive node op-node: v1.3.2 op-geth: v1.101304.2 l2geth: ethereumoptimism/l2geth:0.5.31

Expected behaviour

Return the actual transaction hash that is reported by l2geth and block exploreres.

Actual behaviour

When running debug_traceBlockByNumber on some pre bedrock blocks and are getting this transaction hash: 0x0000000000000000000000000000000000000000000000000000000000000000, but they're seeing the actual transaction hash on block explorers.

Steps to reproduce the behaviour

To get the 0x00..00 txns hash, make the following request on op-geth

curl NODE-URL/AUTH-KEY -X POST -H "Content-Type: application/json" --data '{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "debug_traceBlockByNumber",
    "params": [
        "0x73706",
        { "tracer": "callTracer", "timeout": "60s", "tracerConfig": { "withLog": true, "onlyTopCall": false } }
  ]
}' | jq

Result:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": [
    {
      "txHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "result": {
        "calls": [
          {
            "calls": [

Tracing the txn for block 0x73706 but from the txn hash from the explorer

curl NODE-URL/AUTH-KEY \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"debug_traceTransaction","params":["0xdcd888c5364c8292e308b64acf48aa9ba7d2b67c7e10504d086b5d51fdd7a824", {"tracer": "callTracer", "timeout": "60s", "tracerConfig": { "withLog": true, "onlyTopCall": false } }],
"id":1,"jsonrpc":"2.0"}' |
Some additional info:
when we do eth_getBlockByNumber for the same problematic block we get the correct txn hash but with debug_traceBlockByNumber it gives 0x00…
curl http://localhost:8545/ \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x73706", true],"id":0}' | jq -r '.result.transactions[].hash'

0xdcd888c5364c8292e308b64acf48aa9ba7d2b67c7e10504d086b5d51fdd7a824 

Additional Information

• When making the request directly to l2geth or op-erigon you get the expected result.
• @mslipper has a hunch that there was a change in how the JSON was represented between l2geth and op-geth