-
Notifications
You must be signed in to change notification settings - Fork 107
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
feat(tests) Precompile Checks #1120
base: main
Are you sure you want to change the base?
Conversation
4ade831
to
ccb6574
Compare
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.
Gave this one a quick look and I wrote one comment.
We also have this similar test over here: https://github.com/ethereum/execution-spec-tests/blob/main/tests/frontier/precompiles/test_precompile_absence.py
["address", "exists"], | ||
[ | ||
("01", True), | ||
("02", True), | ||
("03", True), | ||
("04", True), | ||
("05", True), | ||
("06", True), | ||
("07", True), | ||
("08", True), | ||
("09", True), | ||
("0A", True), | ||
("0B", False), |
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.
This list would only be valid for Cancun, but we could use this marker @pytest.mark.parametrize_by_fork
to dynamically generate this list by fork.
I would also reduce the amount of cases to the first exists=False
fork.
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.
yes. but what if we will have gaps? like new precompiles defined 0x20, 0x21, 0x22 but not at 0x1f, 0x1e
ccb6574
to
473e19f
Compare
Those tests are very similar. Do you think it's still worth migrating these tests? |
dfbf4c6
to
f78c534
Compare
@winsvega @marioevz now I have the data (precompile address) being sent into the transaction. It looks like all tests are returning 0 however. Is there something I may have missed with the logic in the contract? In the original test, the gas cost difference is found based on a condition that the precompile gas is greater than the gas for the call at the address |
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.
added comments
d2cab4a
to
e43edba
Compare
@marioevz @winsvega Latest revisions are creating parameterized tests for each fork with valid precompiles as well as a single invalid precompile. I noticed the gas cost is slightly higher than what the original tests were using. Instead of the gas being compared with This however fails with Byzantium and Constantinople for precompile 5 and I'm not sure why. |
I think the tes was not designed for that forks. Check in ethereum/legacytests if it has a revision for other forks. But yes, need to understand what's going on |
9372ea0
to
cc74bbb
Compare
""" | ||
supported_precompiles = fork.precompiles() | ||
|
||
for address in range(1, len(supported_precompiles) + 2): |
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.
why +2
and what if precompiles are ranges [1..to 11], [100 to 112]
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.
I can extract this into a variable to describe it a little better. The range is set to include the first address where a precompile does not exist. That will cover what @marioevz mentioned in #1120 (comment)
To support disjointed ranges, perhaps this should be changed to some maximum and ignore most addresses that do not have a supported precompile address. This would effectively be the inverse of the "precompile absence" tests:
for address in range(1, UPPER_BOUND + 1): |
gas_10000 = 0x20 | ||
|
||
account = pre.deploy_contract( | ||
Op.MSTORE(gas_test, Op.GAS) |
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.
@marioevz it works Op.GAS
as well as Op.GAS()
?
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.
I've seen this in a few places like
Op.GAS |
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.
when implementing test for the first time, we, actually take our understanding of vm for granted, but newcomers must use vmtrace. and it always good to use vmtrace to see what is actually happening. (yes by now we have little compiler in our head)
I remember the first year I was using vmtrace all the time, it is essential to get an idea of what is going on and how your code is executed.
saying that we might want to use/develop better tools for vmtrace visualizing and debugging. and manuals.
Contract compares gas cost for each precompile. Only checks a single unsupported precompile address.
cc74bbb
to
474d1c1
Compare
env = Environment() | ||
|
||
account = pre.deploy_contract( | ||
Op.MSTORE(0x00, Op.GAS) |
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.
yes now 0x00 can become a variable like
slot_precompile_call_gas = 0x00
slot_empty_address_call_gas = 0x20
it is not a contradiction to previous comment ) this values are reused a lot )
to your liking
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.
I like the descriptive names, good idea!
+ Op.CALL(address=address) | ||
+ Op.MSTORE(0x00, Op.SUB(Op.MLOAD(0x00), Op.GAS)) | ||
+ Op.MSTORE(0x20, Op.GAS) | ||
+ Op.CALL(address=0x10000) |
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.
usually we use input 0, length 32 output 32 length 32 or so. thats why ori marked this args as 0xff to not confuse the memory. because call can touch our memory if we are not careful.
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.
Thinking this should be explicit so that defaults are overridden, I probably don't need variables for these though. Is this what you are saying?
+ Op.CALL(address=0x10000) | |
+ Op.CALL( | |
address=address, | |
value=0, | |
args_offset=0, | |
args_size=32, | |
output_offset=32, | |
output_size=32, | |
) |
|
||
# A high gas cost will result from calling a precompile | ||
# Expect 0x00 when a precompile exists at the address, 0x01 otherwise | ||
post = {account: Account(storage={0: "0x00" if precompile_exists else "0x01"})} |
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.
here I don't clearly understand why abs(empty_call_gas - precompile_call_gas) < 0x1a4 means this logic.
if you can rewrite it more clean like
if precompile_exists then precompile_call_gas is x else y
if it is possible.
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.
I'm not clear on this, since the actual gas value varies by precompile call. I'm not sure what logic could be set outside of the contract code. Could you explain a bit more on this?
elif num_unsupported > 0: | ||
# Check unsupported precompiles up to NUM_UNSUPPORTED_PRECOMPILES | ||
yield (hex(address), False) | ||
num_unsupported -= 1 |
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.
what if precompiles are [1-15], [20-25] then 17,18,19 won't be checked for not being a precompile ?
its not the case, just analyzing. I see the original test verified first 0xff addresses. so if a fork will define precompiles with gaps could be an issue here.
I think now we have separate range of special addresses starting from 0x100 too.
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.
Since there are other tests for no precompile in test_precompile_absence
, having those checks here as well would be redundant. I think that's why @marioevz said we should just check the first address that a precompile does not exist. I could change the upper bound to 0xff if need be, but I think the fork.precompiles
for the forks being checked in this test are mostly just 0x1 - 0x9, and for cancun it includes 0xa as well.
I think now we have separate range of special addresses starting from 0x100 too.
Should the fork that supports this be included here? I don't see those specific ranges in the fork classes.
coverage of the precompiles does not work as its a third party lib in evmone not included in coverage |
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.
I think now it covers the original test. a little optimised with undefined precompiles check.
just a few notes if we can now make it even better
🗒️ Description
Add tests to check each precompile at specific addresses.
Tests from: https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stPreCompiledContracts/idPrecompsFiller.yml
Removed in:
ethereum/tests#1444
🔗 Related Issues
✅ Checklist
mkdocs serve
locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.