Conversation
|
I see some options for client tests, researching it, so NO MERGE at the moment, I think we could add some new test generators |
|
Would you mind rebasing to |
djrtwo
left a comment
There was a problem hiding this comment.
Nice! a handful of comments.
Needs a rebase on dev due to the removal of dynamic TTD. Will do another review after that
tests/core/pyspec/eth2spec/test/merge/block_processing/test_process_execution_payload.py
Outdated
Show resolved
Hide resolved
|
|
||
| # execution payload | ||
| execution_payload = build_empty_execution_payload(spec, state) | ||
| execution_payload.gas_limit = uint64(0) |
There was a problem hiding this comment.
Now that I look at it, some of the gas_limit validations in is_valid_gas_limit can be validated even on the first_payload. Another option would be to call is_valid_gas_limit not matter what and pass in None or the prev exection header and premise some of the checks on if there was a prev execution header or not.
OR we can leave as is
OR we can remove because the execution-layer will perform these checks anyway.
cc: @mkalinin
There was a problem hiding this comment.
oh and marginal preference to turn is_valid_gas_limit into a validate_gas_limit which actually has the line by line assertions. This makes debugging much easier than calling assert on a multi-line predicate.
Not relevant for this PR but want to drop it here while I'm thinking about it
There was a problem hiding this comment.
@djrtwo from my experience any logic duplication leads to bugs when we change it someday in one place and forget about another. So I'd vote for removing it if there are no security threats by letting everything up to execution layer decision
There was a problem hiding this comment.
The intention was to put all the validations to the consensus layer except for verification that require execution state accesses like transaction validation and state root matching after the execution. The rationale behind this intention is to verify as much as we can before communicating with the execution client, also, this is gonna be a requirement for the statelessness introduction in the future, none of this arguments is that strong though. For now we decided to avoid uint256 math that is required to validate base_fee_per_gas and it might make sense to remove is_valid_gas_limit at all.
Despite the above, I like the idea of turning is_valid_gas_limit to validate_gas_limit.
tests/core/pyspec/eth2spec/test/merge/block_processing/test_process_execution_payload.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_terminal_validity.py
Outdated
Show resolved
Hide resolved
hwwhww
left a comment
There was a problem hiding this comment.
Great work! 👍
Some minor suggestions on pyspec conventions. I didn't review test_terminal_validity.py in detail since it will change after rebasing.
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_terminal_validity.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/block_processing/test_process_execution_payload.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_terminal_validity.py
Outdated
Show resolved
Hide resolved
|
@djrtwo @hwwhww Updated everything according to your feedback, sorry if missed a thing, there was a lot of it. |
There was a problem hiding this comment.
I got errors once I added yield from to test_on_merge_block.py tests locally. Not sure how to fix the assert spec.get_head(store) == anchor_block.state_root correctly, but I'm happy to help fix the testgen, feel free to ping me if you have any questions!
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Show resolved
Hide resolved
|
@hwwhww thanks for the help, the tests were not actually run. Now fixed. Could you check it? |
|
Once the above suggestion is applied, the new test case outputs look good to me! 🎉 |
|
@hwwhww the fix passed! |
|
My apologies for not getting to this before the release today. I'll include them in the release monday and make sure consensus client teams know there are additional vectors available |
hwwhww
left a comment
There was a problem hiding this comment.
Some minor refactoring suggestions. Otherwise, it looks good to me. 👍
|
|
||
|
|
||
| @with_phases([MERGE]) | ||
| @with_presets([MINIMAL], reason="mainnet `TERMINAL_TOTAL_DIFFICULTY` stub would cause overflow") |
There was a problem hiding this comment.
To be clear, only this test case would overflow with mainnet config stub. Maybe remove this decorator from other test cases?
tests/core/pyspec/eth2spec/test/merge/fork_choice/test_on_merge_block.py
Show resolved
Hide resolved
| # TBD, 2**256-2**10 is a placeholder | ||
| TERMINAL_TOTAL_DIFFICULTY: 115792089237316195423570985008687907853269984665640564039457584007913129638912 |
There was a problem hiding this comment.
second thought, I think it would be more useful & practical if we also set mainnet config to stub 2**256-2**10. (require spec change though)
tests/core/pyspec/eth2spec/test/merge/unittests/test_terminal_validity.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/unittests/test_terminal_validity.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/unittests/test_transition.py
Outdated
Show resolved
Hide resolved
tests/core/pyspec/eth2spec/test/merge/unittests/test_transition.py
Outdated
Show resolved
Hide resolved
djrtwo
left a comment
There was a problem hiding this comment.
I'm a bit confused about run_process_merge_execution_payload usage in test_terminal_validity
| assert spec.is_valid_terminal_pow_block(pow_block, pow_parent) | ||
|
|
||
|
|
||
| def run_process_merge_execution_payload(spec, block, parent_block, payload, |
There was a problem hiding this comment.
This doesn't run process_merge_execution_payload (which isn't a function I believe) nor process_execution_payload. Instead, it runs is_valid_terminal_pow_block.
I'm also unsure why we are yielding anything here. Is this a new vector type? And if it is, shouldn't a result -- True or False be provided?
It seems that this function is incorrectly named and that it should not be yielding any test vectors
|
closing in favor of #2630 |
Added some merge tests, all I was able to discover. Not a good test creator though
Covering:
process_execution_payloadis_merge_complete,is_merge_block,is_execution_enabledcompute_terminal_total_difficulty'smaxoptionis_valid_terminal_pow_blocktests andprocess_merge_execution_payloadThe latter one is a new method combining all checks for terminal block in
on_blockhandler. Appropriate changes to spec was made too. Also fixed minor type misalign incompute_terminal_total_difficulty.@mkalinin @protolambda Please, take a look