-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Precompile modexp test cases #364
Precompile modexp test cases #364
Conversation
Fixed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jochem-brouwer, thanks for contributing!
Despite draft status, I think it's worth mentioning that a test can't call state_test
multiple times within one test function execution (the framework should really test for this and raise an error if this condition is violated - I just created #365 to address this).
Instead, you can parametrize the test using pytest with the test vectors defined in data. Then the test function will get executed multiple times, once for each test vector. See jochem-brouwer#1.
Parametrize test function using pytest.mark.parametrize
β¦wer/execution-spec-tests into precompile-modexp-test-cases
@danceratopz Thanks for the follow-up PR π Although I have not added all cases from the EIP test file, I think this is ready for review. If you want, I can also add the remaining tests from the EIP. |
Note: I can not set labels for the PR, and I am assuming that if this gets merged, it will be merged via a squash-and-merge. I have not yet ticked those boxes. |
I have updated and also added the 2 remaining cases in the EIP. |
Happy new years everyone π Could someone take a look at this PR? I think it is ready-to-merge, except this spell issue (see my comment here: #364 (comment)) |
Happy New Years @jochem-brouwer! Yup, will do! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jochem-brouwer sorry for the delay!
This is looking really good, below are a few suggestions.
After you've looked at these comments, I might make a suggestion how to change the test IDs to make them more compact and re-usable in the console. Currently, they're a little bit messy to copy-paste and use them in the console due to the single quotes and spaces:
tests/byzantium/precompiles/test_05_modexp.py::test_modexp[fork_Byzantium-input_['', '', '02']-output_['0x01', '0x01']]
tests/byzantium/precompiles/test_05_modexp.py::test_modexp[fork_Byzantium-input_['', '', '0002']-output_['0x01', '0x0001']]
tests/byzantium/precompiles/test_05_modexp.py::test_modexp[fork_Byzantium-input_['00', '00', '02']-output_['0x01', '0x01']]
This is very pytest specific though, so happy to take care of that, if that's ok.
The other suggestion I'd make would be to move the tests:
- From:
tests/byzantium/precompiles/test_05_modexp.py
- To:
tests/byzantium/eip198_modexp_precompile/test_modexp.py
as precompiles were introduced over several forks, for consistency in our repo, I think it's better to organize by the EIP that they were added. We can make discovering and executing precompiles more convenient by adding pytest marks to the tests (e.g., @pytest.mark.precompile_test
, see fill --markers
, if you you're interested, it's like tagging tests with metadata).
Co-authored-by: danceratopz <danceratopz@gmail.com>
Regarding the test names, do you mean something like this?: 460bf35 (I am resolving the latest comment as we speak π ) |
I'm not sure, how do I run |
If I rename to fe4c0a8
REFERENCE_SPEC_GIT_PATH = "EIPS/eip-198.md"
REFERENCE_SPEC_VERSION = "9e393a79d9937f579acbdcb234a67869259d5a96" To the test (which I did). However now the documentation fails to build and I don't know why (just checked, CI passes if I rename it back https://github.com/ethereum/execution-spec-tests/actions/runs/7480915178/job/20361369965?pr=364 ). How should I fix this? It seems it can't find some files
But I don't see anything in the other EIP tests which gives me a hunch what the problem could be π€ Besides this I think the PR is done :) Have addressed all feedback. |
Never mind, I forgot to rename the @danceratopz ready for re-review π |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing! This looks really nice! Thanks for all your work on this.
Regarding the test names, do you mean something like this?: 460bf35
Yes that's one approach (and I like it a lot), but I was originally hoping to use auto-generated names, but make them more compact.
In the end I decided to refactor how we write the parameter values using dataclasses in the hopes of making the code more readable. What do you think?
I made two PRs, one with manual ids only (closer to this PR as it currently stands) and one which generates ids from the parameters. We should pick the one we like most and merge that πΊ - let me know what you think.
cc @marioevz @spencer-tb please also say which of the following you like more... I'm really torn π And what do you think about the dataclass usage? I think the overhead makes sense for these tests.
I personally like this one better jochem-brouwer#2 since it is more descriptive. (I had thought of creating those manually, but indeed creating those using autogen is better π ) Let me know if you need anything from my side π π |
Also regarding the new classes: that definitely makes it more readable! |
Big fan of 2) for the maintainability :D - will be a nice structure to follow for similar tests in the future |
refactor(tests): express test parameters as dataclasses (v1 - verbose autogen'd ids with param values)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again @jochem-brouwer! Nice edition.
Can you just check the comment below? Otherwise, LGTM!
Co-authored-by: danceratopz <danceratopz@gmail.com>
@danceratopz I have just manually checked, the EIP has 5 test cases. I manually also checked that the test cases from the EIP match the test cases as written down in this PR. So from my side also: go ahead and merge, thanks a lot π π |
ποΈ Description
This adds a few test cases for the ModExp precompile introduced in Byzantium.
Tested with:
evm version 1.13.4-stable-3f907d6a, solc version 0.8.23+commit.f704f362.Linux.gpp
π Related Issues
Part of these test cases where consensus bugs found in EthereumJS, see the issue: ethereumjs/ethereumjs-monorepo#3168 and the PR: ethereumjs/ethereumjs-monorepo#3169
β Checklist
mkdocs serve
locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.