test: add debug_traceTransaction with opcode logger tests

[natanasow]

Description:

Recently, the mirror node web3 added a debug opcodes endpoint which is utilized in the relay as well but there is no testing coverage yet.

Related issue(s):

Fixes #783

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[github-actions]

Test Results

  16 files  +1    77 suites  +2   7m 18s ⏱️ +11s
254 tests +3  247 ✔️ +3  7 💤 ±0  0 ❌ ±0 
263 runs  +3  255 ✔️ +3  8 💤 ±0  0 ❌ ±0 

Results for commit 5bb40fe. ± Comparison against base commit 80c2027.

♻️ This comment has been updated with latest results.

[Nana-EC]

LG but mostly questions

[Nana-EC]

Q: why do we need to run besu again.
Is it that the @OpcodeLogger tests rely on comparing outputs from besu and local node?

[natanasow]

Some of them (tagged with 'besu comparison') - yes, and that's the reason. Another possible question could be:

Why just don't hardcode the besu's responses in a JSON and compare against it?

Every time we change a solidity's compiler version in the hardhat.config.js, we will have to locally run these tests against besu to generate a new hardcoded JSON which will be used for further comparison. That should be needed because let's get for example changes from solidity 0.8.23 and 0.8.24. Contracts compiled with the older version will not include EIP-5656 (for mcopy opcode) and EIP-1153 (for tstore and tload opcodes) and debug_traceTransaction will return opcodes based on the contract's bytecode. When we change a solidity version to 0.8.24 in hardhat.config.js, contracts will be precompiled and the new opcodes (from EIP-5656 and EIP-1153) will be introduced in the contracts bytecodes, so when we run the tests and compare debug_traceTransaction responses with the hardcoded ones (generated with contracts compiled with solidity 0.8.23) they will differ.

Based on the info above, we have two possible approaches:

• skip the besu flow in the ci, generate a hardcoded json with responses from the besu beforehand, and rely on developers to keep the hardcoded besu responses up-to-date with the solidity version defined in hardhat.config.js
• stick to this CI where on each run we generate a json for comparison based on the current solidity version in hardhat.config.js

I prefer the second approach because it's not binding to the developers and we shouldn't take extra care if the solidity version is bumped.

Hope that clears some of the things out. I'm open to changes if you find something disrupting or not right.

[Nana-EC]

Gotcha. I'd like this called out in some doc somewhere so people understand the flow

[Nana-EC]

Q: Is there a README that should be updated and explains how besu is being used here?

[natanasow]

I missed adding a README, it's my mistake. Maybe a better idea is to remove this from the npm scripts section and just move the docker run command into the opcode-logger-testing.yml only? In that way, we'll not confuse the developers with this specific besu testing flow. Or it's better to add a descriptive README for besu:start npm script?

[Nana-EC]

Add a README to be more descriptive for this flow.
Approach makes sense, just explain it somewhere so it's an easy reference