debug_traceTransaction RPC method support

[tgmichel]

This PR adds optional replaying and tracing capabilities for Ethereum transactions through debug_traceTransaction, and provides support for Blockscout tracer.

• Support for additional methods in the debug namespace are not included in this PR.
• Support for Javascript-based tracing support is not included in this PR - instead a tailored Blockscout tracer is included, coded in Rust.

The components included are:

• RPC.
• Runtime API .
• pallet-evm Runner extension.
• EVM stack executor wrapper.

RPC

Single method is included in this PR - debug_traceTransaction. It accepts an Ethereum transaction hash and an optional tracer property. It can be enabled by running the node with --ethapi debug.

Originally in Geth, this property's value is evaluated as a Javascript expression in Go and used to format the tracing output. We don't support this and instead we use it to identify if Blockscout tracing is part of the request - a.k.a. instead evaluating the JS expression we execute a stepping routine that will provide an output that satisfies Blockscout's requirements.

Runtime API

Interfaces the RPC with the Runtime, sets the required intermediate state and calls the Runner extension for either create or call transactions.

The intermediate state is calculated by applying all previous extrinsics - substrate or ethereum specific - that happened prior to the targeted transaction in that block, using the parent block as the initial state.

Runner extension

Additional methods to interface RPC requests with our executor wrapper.

EVM stack executor wrapper

Wraps an EVM's StackExecutor in a custom HandlerT implementor called TraceExecutorWrapper. It replaces the normal evm::runtime opcode recursive execution with opcode stepping. This allows us to capture the state between each step's execution and format a response.

Included in this PR there are two possible responses:

• Raw: opcode-level response. A sequence of opcode objects with depth, gas, gasCost, memory, op, pc, stack and storage properties:

...
{
       "pc": 229,
       "op": "SWAP1",
       "gas": 62844,
       "gasCost": 3,
       "depth": 1,
       "stack": [
         "00000000000000000000000000000000000000000000000000000000398f7223",
         "0000000000000000000000000000000000000000000000000000000000000087",
         "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6",
         "0000000000000000000000000000000000000000000000000000000000000006",
         "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6",
         "0000000000000000000000000000000000000000000000000000000000000000",
         "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6"
       ],
       "memory": [
         "0000000000000000000000000000000000000000000000000000000000000000",
         "0000000000000000000000000000000000000000000000000000000000000000",
         "0000000000000000000000000000000000000000000000000000000000000080"
       ],
       "storage": {
         "0000000000000000000000000000000000000000000000000000000000000000": "0000000000000000000000000000000000000000000000000000000000000000"
       }
     },
     {
       "pc": 230,
       "op": "SSTORE",
       "gas": 62841,
       "gasCost": 20000,
       "depth": 1,
       "stack": [
         "00000000000000000000000000000000000000000000000000000000398f7223",
         "0000000000000000000000000000000000000000000000000000000000000087",
         "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6",
         "0000000000000000000000000000000000000000000000000000000000000006",
         "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6",
         "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6",
         "0000000000000000000000000000000000000000000000000000000000000000"
       ],
       "memory": [
         "0000000000000000000000000000000000000000000000000000000000000000",
         "0000000000000000000000000000000000000000000000000000000000000000",
         "0000000000000000000000000000000000000000000000000000000000000080"
       ],
       "storage": {
         "0000000000000000000000000000000000000000000000000000000000000000": "0000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e6"
       }
     }
...

• Blockscout: a compact sorted view of call/create contract interactions:

[
 {
   "type": "call",
   "callType": "call",
   "from": "0xfe2882ac0a337a976aa73023c2a2a917f57ba2ed",
   "to": "0x3ca17a1c4995b95c600275e52da93d2e64dd591f",
   "input": "0x398f72230000000000000000000000001416aa2a27db08ce3a81a01cdfc981417d28a6e60000000000000000000000000000000000000000000000000000000000000006",
   "output": "0x",
   "traceAddress": [],
   "value": "0x0",
   "gas": "0xf9be",
   "gasUsed": "0xf9be"
 },
 {
   "type": "call",
   "callType": "call",
   "from": "0x3ca17a1c4995b95c600275e52da93d2e64dd591f",
   "to": "0x1416aa2a27db08ce3a81a01cdfc981417d28a6e6",
   "input": "0xfd63983b0000000000000000000000000000000000000000000000000000000000000006",
   "output": "0x000000000000000000000000000000000000000000000000000000000000000d",
   "traceAddress": [
     0
   ],
   "value": "0x0",
   "gas": "0x9b9b",
   "gasUsed": "0x4f6d"
 }
]

Is there something left for follow-up PRs?

• Support for the remaining functionality of the debug namespace is to be determined.
• Generic support for Javascript based tracing is to be determined.

What alternative implementations were considered?

• Use an optional hook to the EVM instead a custom executor wrapper. We may go with this approach in further iterations, although impact on non-tracing executions to be determined. Compatibility with the tailored Blockscout is to be determined.
• Applying the intermediate state for replaying using execute_block instead apply_extrinsics. The result is the same in both cases, I decided to go with the latter.

What value does it bring to the blockchain users?

The ability of replaying transactions and tracing intermediate state enables detailed indexing of the network.

Checklist

• Does it require a purge of the network?
• You bumped the runtime version if there are breaking changes in the runtime ?
• Does it require changes in documentation/tutorials ?

[notlesh]

Looks good so far. Do you plan to support higher level stepping (e.g. step over or step out)?

[tgmichel]

@notlesh As I mention to @nanocryk, and because I don't know the status of our frontier branch notlesh-moonbeam-v0.7 (I don't want to give you headaches :)), I didn't updated it. That's why the CI here is failing with note: perhaps two different versions of crate "evm" are being used?.

Solution is as simple as pinning the same evm commit here in moonbeam and in the frontier branch:
https://github.com/rust-blockchain/evm?branch=master#317b82b5660150a37f84da6d7d570b52ad8f23a4

Sadly is not part of any release yet, but should be sufficient to get going.

[JoshOrndorff]

Here's some stuff that stood out to me when giving the code a look. I'm far from an expert on this work.

[tgmichel]

Here's some stuff that stood out to me when giving the code a look. I'm far from an expert on this work.

Thanks for taking some time to look at this! I pushed some corrections, please let me know.

[JoshOrndorff]

Looks good as far as I can tell. Thanks for the docs and addressing my thoughts.