Tests v7 beta1 and updates Istanbul numbers #1871
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added a normalizer `normalize_post_state` to handle this case. Renamed existing method `normalize_post_state` to `normalize_post_state_hash`
fix copy/paste
Plus a bonus fix: tests: fix import when DEBUG2 logging. Logging utilities have moved to separate package, eth_utils. === The EIP-161 implementation evolved over a few commits originally, here is the history: Geth is now filling (some) tests in upstream/tests, so for edge-cases that are impossible on mainnet, prefer geth's approach. Walk the entire computation tree, including branches that errored out (got REVERTed, OOGed, etc.), looking for wabbit RIPEMD160, _always_ collecting it. Skip everything else on errored branches. --- Don't collect if nested computation errored. In the general non-RIPEMD160 case, if the computation errored, it would still be collected, because of the computation.is_origin_computation condition. --- collect_touched_accounts(): clean up. Now that `computation.is_origin_computation` no longer needs to be considered, it's fine to move the RIPEMD160 special-casing back into the `if` clause, because the condition is the same. --- collect_touched_accounts(): remove computation.is_origin_computation when considering SELFDESTRUCT beneficiaries + refactor. `computation.is_origin_computation` has been present since the file was first introduced by @pipermerriam: ethereum@69a8385#diff-28f7a9ef4182d19a95f4cccb1c073ef3 However, whether it's present or not has no effect on the tests passing. (Possibly, this is due to the case not being covered in the tests...) I can't find a place which explicitly states that beneficiary collection should only be skipped if the error happened in the origin computation. From the fact that having a `computation.is_origin_computation` in the next if-clause (`if computation.msg.to != constants.CREATE_CONTRACT_ADDRESS`) caused an error in a RevertPrecompiledTouchExactOOG test, it would seem that upstream (geth v1.9.6) does not consider this a necessary condition. Therefore, removing the condition here, too; and re-working the if-else clauses to look like they did previously (moving the RIPEMD160 special-casing as a sub-clause of the main clause).
Used these napkin-quality scripts: https://gist.github.com/veox/02336c518f049cb749608657622d127f SQUASHED: tests: add Istanbul variants to existing SLOWEST_TESTS + CALLBlake2f_MaxRounds. GeneralStateTests/stTimeConsuming/CALLBlake2f_MaxRounds.json takes an awful long time - I was never able to run it fully. Beyond that, file names for some previous slow tests have changed, losing a `_dXgYvZ` qualifier. Not all have been reviewed! Just enough for the BlockchainTests to run Istanbul within half an hour on my workstation. tests: mark `randomStatetest94` as slow for Istanbul, too. Test passes, takes 22 seconds to run in py-evm (checked for Istanbul only), and indeed causes a +3 GiB memory use peak on my workstation - similar to `geth`, as reported here: https://gitter.im/ethereum/tests?at=5d8c6d25b38cc849bf1402fe (Not as time-consuming as some other tests, though.)
Moved "newsfragment" to `internal` section + update it, because: `towncrier --draft` shows that newsfragments in the `misc` category don't get their contents displayed, they just get listed with a link in the "Miscellaneous internal" section. This is unacceptable! Move to `internal` section instead.
See Istanbul's hardfork meta: https://eips.ethereum.org/EIPS/eip-1679#activation
Raising the exception immediately tells you what's wrong if a test fails, rather than giving you a no-context assertion failure.
carver
force-pushed
the
tests-v7-beta1-and-istanbul-numbers
branch
from
998806a to
812cc56
Compare
pipermerriam
approved these changes
Nov 5, 2019
2 tasks
2 tasks
|
Looks like this closes #1837 too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was wrong?
Rebased version of #1858 with a few updates, merged in from #1870
How was it fixed?
Essentially all of this PR is courtesy of @voith and @veox -- I only moved it because I didn't want to rebase their branches without a conversation, and I really want to get a release out today.
I added a couple minor pieces from #1870:
internaltype of news fragmentcomputation.raise_if_error()overassert computation.is_successfeaturesince Istanbul support belongs thereSo I'm going to be a touch aggressive and approve/merge "myself" in the PR, which is really 97% contributed by others.
To-Do
Cute Animal Picture