Skip to content
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

Add EXTCODEHASH tests #544

Merged
merged 6 commits into from
Nov 13, 2018
Merged

Add EXTCODEHASH tests #544

merged 6 commits into from
Nov 13, 2018

Conversation

ajsutton
Copy link
Contributor

@ajsutton ajsutton commented Nov 12, 2018

  • a contract execute EXTCODEHASH of itself
  • a contract execute EXTCODEHASH with address being a dynamic argument
  • a contract execute EXTCODEHASH of itself during the init code

I figured small batches was a good balance between review size and amount of time spent wrangle git branches but I'm happy to create separate PRs for each of these if that's easier.

},
"transaction": {
"data": [
"0x000000000000000000000000deadbeef00000000000000000000000000000001"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be extended (just by adding more data elements) to dynamic argument to be

  1. non existent account
  2. precompiled account
  3. empty account / no code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. I've added these cases - actually 2 cases for precompiles, one where it exists as an account and one where it doesn't. I believe we have PRs to add tests specifically for these cases as well, do we want both dynamic and static versions or is the dynamic case enough?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think dynamic case is enough. also try not to use <=Byzantium expect section as it multiplies the amount of tests. and extcodehash not even supported on <=Byzantium.

"value": -1
},
"network": [
"<=Byzantium"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this checks that extcodehash is failing it might be just enough to have one test checking that extcodehash failing on all forks <= Byzantium. and in this and other tests it is not required to check its failing on <=Byzantium.
cause otherwise it will produce many tests that all do the same thing - checking that extcodehash is failing on <= Byzantium.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I copied this from another test. I suspect the best approach is to have a single test that is specifically checking EXTCODEHASH is unsupported <= Byzantium. The purpose is fairly ambiguous with it mixed in with other tests.

For now I've removed the <=Byzantium cases from the tests I'm adding and also change >Byzantium to >=Constantinople to be clearer that these are added in Constantinople (my little brain struggles to remember the ordering of hard forks).

"value": -1
},
"network": [
"<=Byzantium"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same tests overload (see above comments)

@winsvega
Copy link
Collaborator

dont forget to run --filltests --fillchain once done. to enable this tests for hive.

…precompiles (existing and non-existing) and empty accounts.
…ble that this feature is new in Constantinople.

Remove <=Byzantium cases that are only checking that EXTCODEHASH is not supported.
@ajsutton
Copy link
Contributor Author

Added the blockchain variants.

@winsvega winsvega merged commit 420f443 into ethereum:develop Nov 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants