Add invalid large withdrawable epoch test

[jtraglia]

PR Description

I believe this is an impossible situation to be in, but this PR tests an edge case in initiate_validator_exit. It is possible to cause an overflow when calculating a new withdrawable epoch. When fuzzing state transitions, we discovered that one of the clients would crash in this situation; so we should add a test.

[dapplion]

What's the value of this test if it's impossible to occur in any practical situation?

[jtraglia]

I believe there is value in having all of the clients behave the same even in impossible situations. The spec states that "state transitions that cause a uint64 overflow or underflow are also considered invalid." This test is just verifying that the clients consider this state transition as invalid.

[ralexstokes]

test looks good although I'd suggest tightening the scope of what we are testing

the logic you target is in initiate_validator_exit so we can test that function instead of the broader process_registry_updates

I'd suggest doing the same setup you have here but testing just that one function (and moving this code to reflect the corresponding spec structure)

[jtraglia]

Good idea. I agree with tightening scope. Where do you suggest I move this test to?

I was thinking epoch_processing/test_initiate_validator_exit but I'm not sure it would fit the scheme. All of the files in that directory are testing methods directly called in process_epoch.

[jtraglia]

Moved it to test/phase0/helper_functions/test_misc.py which matches the spec table of contents.

[hwwhww]

Hey @jtraglia @ralexstokes

• To be compatible with testgen, we don't use pytest in test cases. That's why there are helpers like expect_assertion_error to replace with pytest.raises(Exception). @jtraglia I can push commits to your PR if it's okay.
• The test vectors for clients should be defined in test formats. We have to determine if (i) we will add more unit tests in client test vectors or (ii) keep using the "well-defined" epoch-processing/block-processing helpers to test everything.

I'm sligntly inclined to (ii) because it may be fragmental to create a new test format only for initiate_validator_exit.

[djrtwo]

I would prefer to keep this as testing the epoch processing functions directly to be able to build tests in a generic way.

You can also add a unit test (or a few) for initiate_validator_exit for internal spec consistency purposes, but I'd still bubble it up into some of our standard test-gen test types

[ralexstokes]

yeah I agree that making a new test format is a lot of overhead and I thought we would have already exposed this function to the testgen infra so in my original comment I thought it would be a much simpler change :)

in this case I think we can either revert to the original process_registry_updates test or test a voluntary exit with the mutated state

[jtraglia]

@hwwhww Thank you for your review. Feel free to make changes.

Do I need to yield 'pre', state before the call to run_process_registry_updates too?

[hwwhww]

@jtraglia
lgtm! I run the testgen locally and it works.

Do I need to yield 'pre', state before the call to run_process_registry_updates too?

No, run_process_registry_updates run yield 'pre', state before exception happens.

I pushed a commit for test format (89e7a10)

[jtraglia]

Great. Thank you!