Trace value is wrong in debug_trace* method for blocks in archive

[drt02]

System information

Bor version: v1.4.1
OS & Version: linux-amd64
Environment: Polygon Mainnet
Type of node: Archive

Expected behaviour

To retrieve correct trace value data in debug trace methods.

Actual behaviour

The trace value is wrong from debug_trace* methods.

Steps to reproduce the behaviour

Run this below cURL, please replace with a valid URL:

curl "http://localhost" \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"debug_traceBlockByNumber","params":["0x3a82e03", {"tracer": "callTracer"}],"id":1,"jsonrpc":"2.0"}'| jq '.result[156].result.calls[-1]'

You will see a value “0x4b6b9da129be47" which is wrong. The correct value is 0x4bb14a51cadc37.
Associated transaction on Polygon scan is here.
The value shown in the scan was validated with the balance change of address 0xb3afb6db38a8e72905165c1fbb96772e63560790 at block 61353475(0x3a82e03). Therefore, the scan value is assumed to be correct.

[alessandromazza98]

https://app.blocksec.com/explorer/tx/polygon/0x11d3a43d5f2f6750f221a8ed3e986829fb49b6a0c3c93ae05a899ceece264b77?line=85

actually here it shows the same value you're getting with rpc. so it can be polygon scan to be wrong. or at least it can be wrong. One of them is wrong.

0x4B6B9DA129BE47 = 21228948011204167 (in decimal) and that is 0.021228948011204167 of matic tokens being transfered

[drt02]

@alessandromazza98
But if we get the balances of address 0xb3afb6db38a8e72905165c1fbb96772e63560790 in blocks 61353474 and 61353475 by RPC, the balance change is 2396304001264716.
If we break down that value into:

1. transaction fee 0x11d3a43d5f2f6750f221a8ed3e986829fb49b6a0c3c93ae05a899ceece264b77 with value 18909252009979883
2. The value on which we have differences

So if we add the transaction fee to the balance change, we get the other value that the address received (2):
2396304001264716+18909252009979883= 21305556011244599 (value that corresponds to what appears on the scan)
So it looks like the scan has the correct value.

[alessandromazza98]

@alessandromazza98 But if we get the balances of address 0xb3afb6db38a8e72905165c1fbb96772e63560790 in blocks 61353474 and 61353475 by RPC, the balance change is 2396304001264716. If we break down that value into:

1. transaction fee 0x11d3a43d5f2f6750f221a8ed3e986829fb49b6a0c3c93ae05a899ceece264b77 with value 18909252009979883
2. The value on which we have differences

So if we add the transaction fee to the balance change, we get the other value that the address received (2): 2396304001264716+18909252009979883= 21305556011244599 (value that corresponds to what appears on the scan) So it looks like the scan has the correct value.

ok got it, it makes sense. So yes I'd agree rpc response is not correct. Btw I'm also getting different of these kind of issues too with other transactions

[marcello33]

Hey @drt02 can you try with latest version and let us know? Thank you

[drt02]

Hi @marcello33,
I tried with the latest version v1.5.2 and it still returns the same value.

[sam-iamm]

I'm having a related issue. The receipt status for a transaction indicates failure but the call and opcode trace indicate success.

Transaction hash: 0x2de3852334e48b28d71d7a66467a19b9a2953ae08143c641062c8e254ade71a0

The receipt shows status == 0, but the call trace contains no revert reason. You can easily see the difference by comparing Polygonscan which uses receipts and Blocksec's explorer which uses call traces:

Polygonscan: https://polygonscan.com/tx/0x2de3852334e48b28d71d7a66467a19b9a2953ae08143c641062c8e254ade71a0

Blocksec Explorer: https://app.blocksec.com/explorer/tx/polygon/0x2de3852334e48b28d71d7a66467a19b9a2953ae08143c641062c8e254ade71a0

[manav2401]

Hi @drt02, thanks for reporting the issue.

I tried running the debug trace against a public rpc and an internal bor archive node (running on v1.5.0). The public rpc one gives the wrong value and it matches your hypothesis. But our internal node gave the results similar to polygon scan i.e. it gave correct results. This is weird given what you mentioned in this comment. Can you confirm again if you got wrong results even after upgrading? Or maybe can you try it on bor v1.5.0 once (IMO bor v1.5.0 and v1.5.2 are very close and doesn't change tracing in any way but still to be rest assured)?

I am also confirming against an erigon node to see if the results match or not. My initial plan is to narrow down the issue before actually looking into the code. Will keep you posted.

[sam-iamm]

I'm having a related issue. The receipt status for a transaction indicates failure but the call and opcode trace indicate success.

Transaction hash: 0x2de3852334e48b28d71d7a66467a19b9a2953ae08143c641062c8e254ade71a0

The receipt shows status == 0, but the call trace contains no revert reason. You can easily see the difference by comparing Polygonscan which uses receipts and Blocksec's explorer which uses call traces:

Polygonscan: https://polygonscan.com/tx/0x2de3852334e48b28d71d7a66467a19b9a2953ae08143c641062c8e254ade71a0

Blocksec Explorer: https://app.blocksec.com/explorer/tx/polygon/0x2de3852334e48b28d71d7a66467a19b9a2953ae08143c641062c8e254ade71a0

@manav2401 do you see a revert reason or error field on the call trace for this transaction? my node is on 1.5.2 but the call trace does not contain an error or revert reason, it indicates success (similar to Blocksec's explorer)

[drt02]

Hi @manav2401,
This is my client version: bor/v1.5.2/linux-amd64/go1.22.6. It still returns the same wrong value.
Actually I tried with two different nodes (same version) and I got the same value.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.