feat: improve randomize_state field coverage for fork transition testing

[richardgreg]

feat: improve randomize_state field coverage for fork transition testing

Description

• This PR improves the randomize_state function to populate beacon state fields with realistic non-default values during testing.
• Currently, when clients forget to copy fields during upgrades, tests don't catch these
  bugs because 0 == 0 assertions still pass, as demonstrated in the issue description with the Teku client. By using realistic test values, missing field copies now cause test failures
• randomize_state field population now extended to all forks

Relations

Fixes #4535

Co-authored by Claude

[richardgreg]

@jtraglia, do you think it is necessary to populate the fields for previous forks?

[jtraglia]

@jtraglia, do you think it is necessary to populate the fields for previous forks?

Yes, it would be valuable to do this. Please complete the TODO items you've stated in the functions.

Sorry I just haven't had enough time to properly review your PR. Given that this change will affect lots tests for several forks, it will require a more extensive review. In the mean time, I've started the CI checks for this.

I would like for @leolara to review it too. He's in charge of testing here.

[richardgreg]

Hi @leolara, what are your thoughts?

[leolara]

@richardgreg I think this ìf` either should not be here or throw an exception. Like it should not be allowed to call this function in the phase that is not supposed to be used. I search our code base and there are no examples like this, I think.

What do you think?

[richardgreg]

You're right, Leo. It's a counterproductive measure

[leolara]

@richardgreg the reftests are failing in this branch: https://github.com/ethereum/consensus-specs/actions/runs/18327061427/job/52193981595

[leolara]

@richardgreg let me know if I should try to run the tests again

[richardgreg]

@richardgreg let me know if I should try to run the tests again

@leolara sure. You can go ahead and do it. My branch is up-to-date and it generates the reftests locally. I'm hoping that will fix any conflict arising in the CI

[leolara]

Trying here: https://github.com/ethereum/consensus-specs/actions/runs/18891974203

[leolara]

@richardgreg the reference tests are failing in this branch, please check the logs there https://github.com/ethereum/consensus-specs/actions/runs/18891974203 and see if you can fix it

[richardgreg]

https://github.com/ethereum/consensus-specs/actions/runs/18891974203

Right, Leo. I'm investigating it

[richardgreg]

@leolara In this latest push, Altair now inherits Phase 0's fields. The bug was likely due to BLS signature verification failing. Altair not inheriting Phase 0 fields including randao_mixes most likely contributed to that. It's hard to confirm ref tests pass locally because of the amount of time it takes 😅

So I went quite all in this issue without much external input. From what you've seen so far, what are your thoughts on the fields chosen to be randomized for each fork?

[leolara]

I am closing this, but let me know if you think we should reopen it

[richardgreg]

Hi @leolara, okay. I'll let you know when to reopen it for review. My initial solution was kinda rushed, so I'm taking a new approach. I'm putting together a system design for the problem based on the learnings from my initial attempt. I'd love for you to help me review it when I'm done before I put it into code.

I'd also appreciate it if you could confirm that the correct test command for spotting the bug in my initial solution is make reftests k=test_randomized_11. Just gathering intel. Any other tips you can provide, like relevant links in the eth2book, would be appreciated

Happy New Year