feat(test): test opcode programs in different scenarios

[winsvega]

🗒️ Description

Conversion of opcode diff places tests by ori.
A test defines series of test scenarios that are run on each parametrized opcode sequence.
Then we check if the sequence worked as expected in a given scenario.

I think this is a powerful method to template test any new given opcode.
we already have pre defined scenarios. then we just add one more parameter with what we want to test, and it will be covered on all the cases automatically.

Cases can be like:
callcode->staticcall-> [opcode]
create2-> [opcode]
[opcode] -> revert

check it out. so we can define opcode programs and scenarios. then the test will put each opcode program in each scenario and verify that it's result is the same (perhaps result will be complex depending on context and fork)

the idea is so far to have a template test and then we can easily just add opcode programms and it will be run in all crazy combinations.
likce call delegate call suicide revert and so on

This is still WIP.

🔗 Related Issues

#184
ethereum/tests#1490

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[chfast]

Can you give it any better name? The "opcode diff places" has no meaning.

[winsvega]

it translates as opcode in different (logical) places

[marioevz]

A few suggestions after a quick review. I haven't checked files in the ./scenarios/ scenarios/ folder, but will do on the re-review.

[winsvega]

Since it is unreasonable to have all scenarios in one transaction (millions of gas and huge debug trace)
I now put 1 scenario into each separate block. making it a blockchain test.
(it is impossible to generate 1 state test per each scenario as pytest collect fixtures at compile time and scenarios depend on fork dynamically)

so here what it does.
for each user created byte sequence (program)
puts it into user created scenarios (like call -> callcode -> program, or create -> init code program, or call->program, suicide)
and verifies the expected result.

so if we test something like selfbalance == actual selfbalance, we create bytecode
Op.MSTORE(0, Op.SELFBALANCE) + Op.RETURN(0, 32),
and the result

ProgramResult(result=ScenarioExpectOpcode.SELFBALANCE, from_fork=Istanbul),

then scenarios will make sure that this bytecode return value is equal to scenario expected selfbalance (which is calculated at scenario code) for each scenario situation. like when we call delegatecall->program, delegatecall->call->program
this way we automatically test selfbalance opcode in all call combinations.
and inside create/create2 init code (this are basic examples of possible scenarios)

then we can add a scenario of eof code. and it will verify program value inside eof code.
automatically for each program.

this was one of the first ethereum tests. a simple verification that a bytecode like add(1,1) really returns 2 in all contexts.

1 coverage line is lost because it's no longer a state test, besides that line reffers to pre state check in test.

Also original tests were a little faulty, some cases didn't do what they were intended to do.

[marioevz]

I think there are a lot of anti-patterns used here, each program can be a separate python test file to make them simpler and more atomic.

The problem with putting so many verifications into a single test is that it's going to be difficult to client developers to debug in the case they find issues with one of these tests.

[winsvega]

Missing coverage 3 lines are Prague evm init and state test loader check for a storage of pre.account having value of x:0.

[marioevz]

I've rebased and deleted the static test files that this PR supersedes.

I also disabled this test in executed because it requires accurate value of Op.GASPRICE which is unpredictable in devnets (we need a way to pass this to the tests somehow perhaps via a fixture).

[marioevz]

Verified the coverage files:

• case EVMC_PRAGUE is running the case in Prague, which the coverage script does not fill for.
• if (is_zero(value)) is not covered because the new tests do not pre-set the storage of the contracts it deploys.

[winsvega]

I've rebased and deleted the static test files that this PR supersedes.

I also disabled this test in executed because it requires accurate value of Op.GASPRICE which is unpredictable in devnets (we need a way to pass this to the tests somehow perhaps via a fixture).

I am aming ro make it execute compatible.
I have gashash contract to solve that.
If gasprice is unpredictable I call gashash contract with the value of op.gasprice that shall produce unique gas used so that others running the test can agree on gas used value without tests knowing which value is it