Parity-ethereum: Trace bug?

[fanatid]

Parity version: 1.7.8
OS: Ubuntu 16.04
How installed: from sources
Options: --geth --chain foundation --pruning archive --tracing on

In transaction trace I see call with non-zero value, but address balance is not changed. Or I interpret trace not right?

For example address 0xf7cbc0eee75f9c3b0acdd5c8d7c0312095188e24, transaction 0xebb49b894685a52ab85406987bc3d45d4bddc294333074ce5800bd7cd6feba9d was made in block 0x4475bf, but balance was not changed.

$ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xf7cbc0eee75f9c3b0acdd5c8d7c0312095188e24", "0x4475be"],"id":0}' http://localhost:8545
{"jsonrpc":"2.0","result":"0x2c68af0bb140000","id":0}

$ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xf7cbc0eee75f9c3b0acdd5c8d7c0312095188e24", "0x4475bf"],"id":0}' http://localhost:8545
{"jsonrpc":"2.0","result":"0x2c68af0bb140000","id":0}

$ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xf7cbc0eee75f9c3b0acdd5c8d7c0312095188e24", "0x4475c0"],"id":0}' http://localhost:8545
{"jsonrpc":"2.0","result":"0x2c68af0bb140000","id":0}

$ curl -H "Content-Type: application/json" -X POST --data '{"method":"trace_transaction","params":["0xebb49b894685a52ab85406987bc3d45d4bddc294333074ce5800bd7cd6feba9d"],"id":1,"jsonrpc":"2.0"}' http://localhost:8545 | python -m json.tool
...
            "action": {
                "callType": "call",
                "from": "0x08f5876c07585d788a5e0faeb6c6cb92c217ba1a",
                "gas": "0x5d03",
                "input": "0x",
                "to": "0xf7cbc0eee75f9c3b0acdd5c8d7c0312095188e24",
                "value": "0x38d7ea4c68000"
            },
            "blockHash": "0x5d6a3099cb1d0fcb1c96f027393407599e0138c70d87ab167e9256e029852a4e",
            "blockNumber": 4486591,
            "result": {
                "gasUsed": "0x10f",
                "output": "0x"
            },
            "subtraces": 0,
            "traceAddress": [
                1
            ],
            "transactionHash": "0xebb49b894685a52ab85406987bc3d45d4bddc294333074ce5800bd7cd6feba9d",
            "transactionPosition": 27,
            "type": "call"
...

you can see full trace here: https://etherscan.io/vmtrace?txhash=0xebb49b894685a52ab85406987bc3d45d4bddc294333074ce5800bd7cd6feba9d&type=parity

[iFA88]

7109

[fanatid]

@iFA88 I think there is other case, in transaction above no error fields at all.

[iFA88]

I think its the same, the parity trace have 'forgot' to append the error key to the failed trace. I think this is because the revert opcode.
This transaction was success but a sub call was reverted. check this: geth trace

[fanatid]

I hope they not and there will not [email protected] 🤣
But things definitely were better before Byzantium HF... before HF my algorithm for calculating balances from transaction trace was wrong for ~6 contract addresses, right now (block 4668018) number is 30 addresses.

[fanatid]

@iFA88 reread and rethink you comments, probably your right, revert opcode revert transaction changes, but trace did not display it :(
I hope devs will answer here :(

[fanatid]

For possible acceleration of resolving this issue, let's set bounty: 1000$ (will be paid in ETH).
Will be paid to developer who will provide explanation why transaction trace have item with callType = call, but balance is not changed.

[iFA88]

@fanatid I think if you check the Receipt status you can decide that the transaction was reverted or not. In your situation the transaction is reverted, so your processor should not transfer anywhere anything during the trace.transaction. What do you think? I have soon recoded my processor to do that, but still syncing :)

[fanatid]

status for this transaction is 1:

$ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xebb49b894685a52ab85406987bc3d45d4bddc294333074ce5800bd7cd6feba9d"],"id":0}' http://localhost:8545 2>/dev/null | jq .result.status
1

[iFA88]

Oh yeah, you have right, this is not enough.. :(

[iFA88]

I will increase your bounty with 0.5 ETH.

[iFA88]

I will increase your bounty @fanatid with another 0.5 ETH. (SUM: 1 ETH)

[fanatid]

@tomusdrw @debris can you explain how #7412 fix this issue? What was the problem?
In which version #7412 will be included?

[tomusdrw]

In our intepreter implementation the execution may either exit correctly (Ok) or Error (Err variant). Before revert Err signified a failed call. Revert is special in a way that it is a correct end of execution (Ok), but the apply_state flag is set to false (so the state changes done by the execution should not be commited).
The change traces a failed call in case it's a revert operation (so Ok with apply_state=false) as expected in that issue.

[iFA88]

When will you release it for linux binary? I would like to test it :)

[5chdn]

In which version #7412 will be included?

1.9.0 and 1.8.6 :)

[jprichardson]

On behalf of @fanatid and @tomusdrw, a 1 ETH bounty was sent to MyEtherWallet. @tomusdrw specified paying the bounty to a good cause in the Ethereum community. @fanatid thought of MEW. Excellent suggestions.

Donation made: https://etherscan.io/tx/0x8d66bb374077e47bb93c1f24aeaf10a4f47e6cfe0a950110c9554fa5e1b50261

[iFA88]

For my part, if I have the released party and everything works as expected the I would send the transaction. My 1 ETH donate should I send to 0x7cB57B5A97eAbe94205C07890BE4c1aD31E486A8 @tomusdrw ?

[iFA88]

@fanatid Do you have something like this https://github.com/paritytech/parity/issues/7109#issuecomment-356362601 ? For me is that new error.

[fanatid]

@iFA88 1.7.12 not include patch for this bug.
I build parity with #7412 and at least transaction above ^^ is fixed (synced from scratch).

[iFA88]

Maybe i'm wrong but there https://github.com/paritytech/parity/compare/v1.7.12...master I can see the commit for fixing this issue ( 6a01113 ).

@fanatid please let me do a favor and upload to pastebin the trace result of 0xa6f84aae7731f783c08aafcf402fe5ba46acbd5dfecc7267e37fb70d29f74ee6 transaction. Thank you :)

[5chdn]

Maybe i'm wrong but there v1.7.12...master I can see the commit for fixing this issue ( 6a01113 ).

Because you are seeing everything that is not in 1.7.12 :)

This fix will be available in 1.8.6 once our CI is done.

[fanatid]

@iFA88 https://gist.github.com/anonymous/22c78acc143332c3df2448cc8087e8ae

[iFA88]

@fanatid Thank you.
This trace has still the bug what i'm saying.
A address calls B address and inside in this the A address uses delegatecall? This should be impossible.