[evm-tracing-0-1] add debug e2e tests logic implementation

[dmitrylavrenov]

The example list of different existing debug RPC methods for Ethereum:
- https://therpc.io/docs/ethereum/debug-methods/debug_traceCall
- https://www.chainnodes.org/docs/ethereum/debug_traceCall
- https://docs.chainstack.com/reference/ethereum-tracecall
- https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug#debugtracecall

The team has agreed on using moonbeam as a base code for implementing EVM tracing related tests.

The following basic tests have been implemented:

• trace_filter
• debug_traceCall
• debug_traceTransaction
• debug_traceBlockByNumber and debug_traceBlockByHash

Tested over moonbeam-peer in dev mode with moonbase-runtime-3800-substitute-tracing.wasm overrides

[dmitrylavrenov]

@MOZGIII Please, check the example list of debug RPCs for Ethereum in the PR's description. There are some differences between them in implementations: request/response types, supported tracers, even disable/enable terminology usage like disableMemory vs enableMemory.

The question is: should we take into account current Moonbeam implementation for e2e test logic to avoid "possible" incompatibility (otherwise, not sure if everything will work as expected without additional moonbeam ported code changes due to having different debug RPC implementations) ?

Another idea - just refer to geth source code and do everything according to this implementation later fixing moonbeam ported code if it would required.

[MOZGIII]

For the E2E, let's try to write up a clear spec and test cases, with comments on what options are available and what we base them on; it is unclear as to what exact tracer format we'd want to use - so I suggest we simply use implement multiple E2E tests checking all variants.
Then, we would have a clear spec, with examples organized universally and all in once place. This would be a good thing to start from, as then we can check what moonbeam supports, and select an optimal strategy for our implementation. For instance, we could start with a simple port of moonbeam code first - with an clear understanding of what portion of our spec that will cover exactly (because we see the tests pass); then we may take some more time to alter the implementation and adjust our code.

In essence, the main differences are often at the RPC formats, and there's no reason why we couldn't do some smart translation at struct parsing to support all variants, as in disableMemory / enableMemory.

[MOZGIII]

Essentially, the scope of the implementation for something like this should be defined here - at the test.

I propose the we cover the following basic APIs:

• debug_traceCall - https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug#debugtracecall
• debug_traceTransaction - https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug#debugtracetransaction
• debug_traceBlock - https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug#debugtraceblock

The idea would be to have this loosely - reasonably loosely - follow the geth implementation; pretty sure the is the same goal that moonbeam had for their design.

The way we can test this, in practice, in via a block explorer - like blockscout. This could be a good addition to the e2e tests - as essentially this is what we want to support (one of the main use-cases).

In the e2e tests, we should capture the request / response of the corresponding calls made to the geth node, and base our test scenarios on that (i.e. for the same contracts / calls the outputs should be the same, excluding things like block number, time and random stuff)

[MOZGIII]

The question is: should we take into account current Moonbeam implementation for e2e test logic to avoid "possible" incompatibility (otherwise, not sure if everything will work as expected without additional moonbeam ported code changes due to having different debug RPC implementations) ?

We could borrow the moonbeam end-to-end test scenarios / scenario ideas if it is hard to make up our own. Whether we should take their request/response samples instead of creating our own - that's debatable. I wouldn't trust they did it correctly in the first place.

Another idea - just refer to geth source code and do everything according to this implementation later fixing moonbeam ported code if it would required.

I think we should look at both places, and everywhere else; but most of all - what the consumers of these APIs usually expect.
As in, blockscout actually depends on javascript support at tracing APIs - this is something that is not really supported at moonbeam afaik, but they hacked in the emulation if the support - they check if the requested javascript snippet matches the blockscout-used code, and if it does they run custom rust code to match what that javascript would do.
We should do the same.

What matters is that we make the API usable, in the sense that real users can rely on it. It's not our API design, it is a compatibility layer - so we don't have to design the interface, just implement (a subset of) it.

[MOZGIII]

Seems like the hooks fail... I wonder why is that.

[dmitrylavrenov]

Seems like the hooks fail... I wonder why is that.

What do you mean by the hooks fail? It should fail until we merge the rest PRs

[MOZGIII]

Seems like the hooks fail... I wonder why is that.

The tests wait for a condition that never happens? Shouldn't they just fail immediately after an assertion fails? I.e. when an RPC request fails with an error?

[dmitrylavrenov]

Seems like the hooks fail... I wonder why is that.

The tests wait for a condition that never happens? Shouldn't they just fail immediately after an assertion fails? I.e. when an RPC request fails with an error?

The tests wait for a condition that node is running. The current version doesn't have evm tracing related cli params. So, the node pid is not available to continue tests logic.

It happens with any tests if we pass invalid cli params. Maybe, we should restrict it somehow at e2e tests logic ?

[MOZGIII]

I see; if we pass invalid cli args and the node crashes we probably should abort the test and mark it as crashed; I'll implement it

[quasiyoke]

Reviewed and ran tests. Took runtime overrides from the Docker image moonbeam-tracing. Node launch arguments had to be changed:

args: [
  ...
  "--wasm-runtime-overrides=<OVERRIDES_DIR>",
  "--public-addr=/ip4/0.0.0.0/tcp/9944",
],

Also changed the chain ID:

defineChain({
  id: 0x501,

Launched with the following command:

HUMANODE_PEER_PATH=<PATH> ./run-tests evm-tracing

Sources — LGTM.