core/stateless, eth: add debug_executionWitnessByHash + debug_executionWitness

[gballet]

This is a request by @kevaundray.

This PR adds a new system call, which re-executes a block with stateless mode activated, so that the witness data are collected and returned.

This has some differences with the reth equivalent (list will likely :

1. The returned block header is json-encoded and not rlp-encoded
2. nil codes aren't added
3. the keys field is present but is always empty - this is an agreement with Kev, that will be done in a later PR. The role of this PR is to find the disagreements with reth.

Note that, besides these issues, I still do find some differences with what reth returns, which is why this PR is in Draft mode.

[s1na]

I checked the difference in witness between geth and reth for block https://etherscan.io/block/23174550.
Find the results here: geth-witness-550-sorted.json
reth-witness-550-sorted.json

Apart from the differences noted above:

• codes field seems to have a minor difference:
  • First, reth produces a duplicate code in 0x363d3d373d3d363d7f360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc545af43d6000803e6038573d6000fd5b3d6000f3
  • Geth returns 2 less codes. One is 0x. The other is a big contract 0x6080604052600436106100745760003560e01c8063ad5c46481161004e.... It seems wasteful to include an empty code so I'd say that should be changed in reth. But why the second code is missing is an interesting question.

In addition, good to clarify these in the spec:

• Name of the method debug_executionWitness vs debug_executeWitnessByHash.
• We only take block hash as parameter, reth only takes block number. Both are weird imo we should take block num or hash or go for 2 methods.

[jsign]

We only take block hash as parameter, reth only takes block number. Both are weird imo we should take block num or hash or go for 2 methods.

@s1na, reg this, Reth has both.

[rjl493456442]

Does anyone know what Keys refers to?

[rjl493456442]

keys: this is a list of all the keys present in the state. It is particularly ordered first by address and then storage slot keys. e.g.,

<address1><address2><slot-1-address2><slot-2-address2><address3><sloat-1-address3>. etc.

[s1na]

I checked the difference in witness between geth and reth for block https://etherscan.io/block/23174550.
Find the results here: geth-witness-550-sorted.json
reth-witness-550-sorted.json

For the same block I realized that the are differences also in the trie nodes. Namely reth and geth share 8536 nodes in common, but reth has an extra 52 not present in geth response, and geth has 4 nodes not present in reth response. The list of these nodes is available on request.

One of those nodes that reth includes extra is 0x80. Probably shouldn't be there.

[gballet]

I checked the difference in witness between geth and reth for block https://etherscan.io/block/23174550.
Find the results here: geth-witness-550-sorted.json
reth-witness-550-sorted.json

For the same block I realized that the are differences also in the trie nodes. Namely reth and geth share 8536 nodes in common, but reth has an extra 52 not present in geth response, and geth has 4 nodes not present in reth response. The list of these nodes is available on request.

One of those nodes that reth includes extra is 0x80. Probably shouldn't be there.

yeah could you please share them?

[s1na]

Here you go:

geth_only_states.txt
reth_only_states.txt

[s1na]

Please rename to ExecutionWitnessByBlockHash and add in ExecutionWitness (takes number) for consistency with reth.