Skip to content

New merge tests#2598

Closed
zilm13 wants to merge 20 commits intoethereum:devfrom
zilm13:tests/merge
Closed

New merge tests#2598
zilm13 wants to merge 20 commits intoethereum:devfrom
zilm13:tests/merge

Conversation

@zilm13
Copy link
Contributor

@zilm13 zilm13 commented Sep 14, 2021

Added some merge tests, all I was able to discover. Not a good test creator though
Covering:

  • more bad cases with process_execution_payload
  • unit tests on is_merge_complete, is_merge_block, is_execution_enabled
  • testing out compute_terminal_total_difficulty's max option
  • is_valid_terminal_pow_block tests and process_merge_execution_payload

The latter one is a new method combining all checks for terminal block in on_block handler. Appropriate changes to spec was made too. Also fixed minor type misalign in compute_terminal_total_difficulty.
@mkalinin @protolambda Please, take a look

@mkalinin mkalinin requested review from djrtwo, mkalinin, protolambda and ralexstokes and removed request for mkalinin September 14, 2021 08:54
@hwwhww hwwhww added testing CI, actions, tests, testing infra bellatrix labels Sep 14, 2021
@zilm13
Copy link
Contributor Author

zilm13 commented Sep 15, 2021

I see some options for client tests, researching it, so NO MERGE at the moment, I think we could add some new test generators

@djrtwo
Copy link
Contributor

djrtwo commented Sep 22, 2021

Would you mind rebasing to dev to handle the conflicts?

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

Nice! a handful of comments.

Needs a rebase on dev due to the removal of dynamic TTD. Will do another review after that


# execution payload
execution_payload = build_empty_execution_payload(spec, state)
execution_payload.gas_limit = uint64(0)
Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@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

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

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

Great work! 👍

Some minor suggestions on pyspec conventions. I didn't review test_terminal_validity.py in detail since it will change after rebasing.

@zilm13
Copy link
Contributor Author

zilm13 commented Sep 23, 2021

@djrtwo @hwwhww Updated everything according to your feedback, sorry if missed a thing, there was a lot of it.
Added test_on_merge_block fork choice tests for clients and turned on genesis and fork_choice tests for MERGE. Maybe there are another opportunities I'm missing to test clients? But it's all I see. I'm ready for merge )
Also we need consensus-spec-tests regen after this one is merged

Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

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

@zilm13

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!

@zilm13
Copy link
Contributor Author

zilm13 commented Sep 24, 2021

@hwwhww thanks for the help, the tests were not actually run. Now fixed. Could you check it?

@hwwhww
Copy link
Contributor

hwwhww commented Sep 24, 2021

Once the above suggestion is applied, the new test case outputs look good to me! 🎉

@zilm13
Copy link
Contributor Author

zilm13 commented Sep 24, 2021

@hwwhww the fix passed!

@djrtwo
Copy link
Contributor

djrtwo commented Sep 25, 2021

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

Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

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

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")
Copy link
Contributor

Choose a reason for hiding this comment

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

To be clear, only this test case would overflow with mainnet config stub. Maybe remove this decorator from other test cases?

Comment on lines +8 to +9
# TBD, 2**256-2**10 is a placeholder
TERMINAL_TOTAL_DIFFICULTY: 115792089237316195423570985008687907853269984665640564039457584007913129638912
Copy link
Contributor

Choose a reason for hiding this comment

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

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)

Copy link
Contributor

Choose a reason for hiding this comment

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

/cc @djrtwo

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

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,
Copy link
Contributor

Choose a reason for hiding this comment

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

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

@hwwhww hwwhww mentioned this pull request Sep 27, 2021
@djrtwo
Copy link
Contributor

djrtwo commented Sep 27, 2021

closing in favor of #2630

@djrtwo djrtwo closed this Sep 27, 2021
djrtwo added a commit that referenced this pull request Sep 27, 2021
@zilm13 zilm13 deleted the tests/merge branch September 28, 2021 08:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bellatrix testing CI, actions, tests, testing infra

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants