Official ethereum/tests StateTests execution

[adria0]

Integrate the "official" EVM tests located in https://github.com/ethereum/tests

Since we are running our own geth executor to generate the traces, we are using the /src folder and not the retesteth filled tests (located in /BlockchainTests and /GeneralStateTests).

The basic roadmap for this PR is

• parse a basic .yaml tests
• test StateTests, check results
• compile LLL via docker
• pass the first basic existing test we also have some dependencies
  • feat: add sstore circuit #383 feat: bus mapping for sload and sstore #436
  • op CALLDATALOAD #346 Implement Calldatacopy::gen_associated_ops #443
  • Implementation ExecutionState::STOP #419
  • Implementation ExecutionState::CALL #278
• add more tests about the current implemented opcodes
• compile YUL via docker
• use the json spec (is not clear that is going to be needed, since EF tests team is moving all tests from .json to .yaml)

Note for reviewers

You will find in this PR:

• A binary in evm-testvectors/src/main.rs that

  • scans all the tests from the evm-testvectors/test folder that is a git submodule
    • there are two types of files to scan: json and .yaml
  • compiles the code inside the tests if not found in the code.cache file
    • this is executed via docker (see docker folder)
  • runs the test if not found in the results.cache file, but skips some tests
    • which ones contains unimplemented opcodes (defined in the OPCODES_UNIMPLEMENTED const) via scanning the geth trace
    • which ones uses too much gas or a maximum of steps (see StateTestConfig)
    • which ones the geth trace is too big ; I had to modify geth-utils/lib/lib.go to skip very big traces (geth crashed)
    • others ( see FILE_IGNORE_LIST)
  • writes the result in the results.cache file

• Enrich Bytecode by adding a disasm() -> String method as also an iter() that generates an iterator over the bytecode Opcodes. From my previous experience running those tests there are is a lot of cases that you have to analyze and test the code, and I created a small command line tool for generating on-the-fly tests using assembly/bytecode as also to parse bytecode (see --raw option in main.rs)

• note that this is a first version, probally this is going to change, and eventually we have to move this into a specific repo, but for the moment I prefer to merge this to not having code far from origin/main

• note2 this code is not critical at this point, so a light review could be done IMO

[ChihChengLiang]

Do we intend to check in code.cache and result.cache? Or should we ignore them?

[adria0]

Do we intend to check in code.cache and result.cache? Or should we ignore them?

Hi @ChihChengLiang, I absoutely forgot to anwser you comment, sorry!

Those files are just kept to speed up testing process and to check diffs between executions. Maybe we could make a quick meeting with you and @ed255 about how we can improve and make this tests better before a review, starting september? Happy to share some ideas I have :)

[ChihChengLiang]

@adria0 Yeah, sure. We can have a meeting when you and Edu are back.

[ed255]

Those files are just kept to speed up testing process and to check diffs between executions. Maybe we could make a quick meeting with you and @ed255 about how we can improve and make this tests better before a review, starting september? Happy to share some ideas I have :)

Sounds good to me!

[adria0]

replaced by #748