Inconsistent trace_decoder output from Jerigon payload

[Nashtare]

Shared below are two block payloads that have been generated with a Jerigon node running on commit 83e0f2fa8c8f6632370e20fef7bbc8a4991c73c8 for which zk_evm develop branch at commit 52ab1aa is failing to parse properly.

I've attached the corresponding retrieved header files for easy comparison via the trace_decoder consistency test added by Marko. This may be a Jerigon issue, similarly to #421 (cc @cffls).

b20472591_main_header.json
b20472591_main.json

b20472570_main_header.json
b20472570_main.json

[Nashtare]

What may be the cause of the issues is that both blocks have a reverted transaction, though Jerigon eth_getWitness should handle this properly:

https://etherscan.io/tx/0x1f93d33225f68083551a443e15253fca3478ae84fd2b96183b8da8d72e4e7d72
https://etherscan.io/tx/0x98a0c9b85689a4cde94930c3eda69cb65421a68ab5a673329e1c7532f01f039d

[Nashtare]

So regarding this, the issues are actually related to the combination of CREATE2 + SELFDESTRUCT within the same transaction on existing accounts.

More specifically, I thought this was being fixed by #487 but it seems the error actually didn't lie in an erroneous interpretation of EIP-6780 but in a malformed Jerigon payload instead.
Regardless of if an account has a pre-existing balance, we should delete it upon encountering a SELFDESTRUCT following a contract creation targeting this address occurring on the same transaction.

As per EIP-6780:

A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract’s new address it is still considered to be a contract creation.

This is more clearly visible on block 20472570, which suffers from this issue on this particular transaction:

• addr: 0xBb2ac47b1924d2a6b04E650cA559031CCFB00298
• state key 4960e439ccb1796693051b77b2a068e61ccf075b91bfb8f0d7f5cdc970fc366f

I've attached below both the final trie obtained by the decoder post b20472570 txn processing, and the initial trie for the next block, where I forced the inclusion in the trie witness of all touched addresses of the previous block for proper comparison.

Calling the diff tool on these, the only discrepancy is in the mentioned account that should have been deleted:

➜  zk_evm git:(develop) trie_diff b20472570_end.json b20472571_start.json
Trie hashes: a: 0x7417c2a8d30275edd4eba5cb62be0fc36a6b2e60ffc6bcc54019613cc1ab85e0, b: 0x2dc9451455bbc38576167482f7a8221e88843d01e64e87ce905ed8997c36a7e0

A: AccountRlp { nonce: 1, balance: 0, storage_root: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421, code_hash: 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 }
Point Diff {
  depth: 0,
  Path: (Branch(4) --> Branch(9) --> Branch(6) --> Branch(0) --> Branch(14) --> Branch(4) --> Branch(3) --> Branch(9)),
  Key: 0x4960e439,
  A info: (
    key: 0x4960e439ccb1796693051b77b2a068e61ccf075b91bfb8f0d7f5cdc970fc366f
    Value: 0xf8440180a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421a0c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470,
    Node type: Leaf Trie hash: cf74f1365103c3b69014331a725b4a9e91b5786a05cb6a1274d5ff80d3611a78)
  B info: (
    key: 0x4960e439
    Value: N/A,
    Node type: Empty Trie hash: 56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421)
}

Source of the error

The Jerigon payload for b20472570 on this specific txn calling CREATE2 + SELFDESTRUCT is including a state_access for the to-be-deleted contract account, cf:

                    "traces": {
                        "0xbb2ac47b1924d2a6b04e650ca559031ccfb00298": {
                            "balance": "0x0",
                            "nonce": "0x1"
                        },

as we need to drain the funds following the SELFDESTRUCT. But the decoder has no way to know it should be actually deleting the account at the end of this transaction, as it only does so when the trace for a given address is empty.
@cffls I think the simplest, given this seems to have been the cause of different issues, is to have a new, explicit field in the Jerigon traces that highlights for each txn the accounts that are expected to be deleted at the end.

b20472570_end.json.zip
b20472571_start.json.zip