Feat/spec proposer round robin for Boole fork

[julienh-ssv]

This PR updates the proposer selection function to match the latest spec for Boole Fork. Since the function was duplicated in our codebase, I also refactored the code to use a single source of truth implementation.

1. Spec PR
2. SIP

[greptile-apps]

Greptile Summary

This PR implements the Boole fork round-robin proposer algorithm and adds fork configuration across all networks. The core changes include:

• New RoundRobinProposer_Boole function that divides QBFT height by 32 to introduce per-period variability in proposer selection
• Fork configuration added to all networks (mainnet uses math.MaxUint64 for future activation, testnet uses epoch 0)
• Controller updated to use fork-aware proposer selection via ForkAwareRoundRobinProposer
• All tests updated to include the new Boole fork field

The implementation follows SSV fork configuration best practices by placing configuration in SSVForks rather than NetworkConfig. However, there are style improvements needed in the proposer algorithm around variable naming and type consistency.

Confidence Score: 4/5

• This PR is safe to merge with minor style improvements recommended for the proposer algorithm implementation.
• Score reflects that the PR implements the required functionality correctly across all networks with proper fork configuration placement. The core logic is sound and follows established patterns. Minor deductions due to style issues: misleading variable naming in the proposer algorithm (ethEpoch when it's not the actual Ethereum epoch) and type inconsistency between the original and Boole versions of the round-robin proposer (uint64 vs int). These are non-critical issues that don't affect correctness but should be addressed for code clarity and consistency.
• protocol/v2/qbft/round_robin_proposer.go needs attention for variable naming clarity and type consistency improvements.

Important Files Changed

Filename	Overview
protocol/v2/qbft/round_robin_proposer.go	New proposer algorithm for Boole fork that divides height by 32 to introduce variability. Variable naming is misleading: ethEpoch is calculated locally and is not the actual Ethereum epoch. Type inconsistency between RoundRobinProposer (uint64) and RoundRobinProposer_Boole (int) could cause issues with large values.
networkconfig/network.go	Added BooleFork() helper method following the same pattern as GasLimit36Fork(). Correct placement in Network struct per custom instructions.
networkconfig/ssv.go	Added Boole field to SSVForks struct. Correct placement in SSVForks (not NetworkConfig) per custom instructions.
operator/validator/controller.go	Updated ProposerF functions in two locations to use ForkAwareRoundRobinProposer instead of RoundRobinProposer. Correctly passes BooleFork() flag. Minor concern: function calls BooleFork() on each invocation which could be expensive if called frequently.

Sequence Diagram

sequenceDiagram
    participant Controller as ProposerF in Controller
    participant ForkAware as ForkAwareRoundRobinProposer
    participant Boole as RoundRobinProposer_Boole
    participant Original as RoundRobinProposer

    Controller->>ForkAware: ForkAwareRoundRobinProposer(state, round, booleFork)
    alt booleFork == true
        ForkAware->>Boole: RoundRobinProposer_Boole(state, round)
        Boole->>Boole: Calculate firstRoundIndex from Height
        Boole->>Boole: Calculate heightPeriod = Height / 32
        Boole->>Boole: Calculate proposer index with heightPeriod
        Boole-->>ForkAware: return OperatorID
    else booleFork == false
        ForkAware->>Original: RoundRobinProposer(state, round)
        Original->>Original: Calculate firstRoundIndex from Height
        Original->>Original: Calculate proposer index
        Original-->>ForkAware: return OperatorID
    end
    ForkAware-->>Controller: return OperatorID

Loading

[greptile-apps]

_{13 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[codecov]

Codecov Report

❌ Patch coverage is 16.66667% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 56.0%. Comparing base (ab23cb6) to head (14581cb).
⚠️ Report is 2 commits behind head on stage.

Files with missing lines	Patch %	Lines
operator/validator/controller.go	0.0%	8 Missing ⚠️
networkconfig/network.go	0.0%	4 Missing ⚠️
message/validation/consensus_validation.go	50.0%	1 Missing and 2 partials ⚠️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[y0sher]

@julienh-ssv please add description and also link to relevant Spec and SIP PRs.

[y0sher]

To be honest, I think the scope of this change should be as limited as we can to the required change. So even though I think the refactor is correct and better looking, I wouldn't want to tie it with the scope of this change, So I'm willing to live with the duplication of the forking logic:

if netCfg.BooleForkAtSlot { 
   // with epoch leader 
} else {
  // no epoch leader 
}

It's going to be duplicated similarly around the code for many use cases anyway. but if possible to reduce the duplication in consensus_validation by importing the logic from the qbft package (and wrapping with the ifs like I mentioned before).

Just to clarify my main goal is to keep the change as minimal as possible while achieving the expected result.

I'd be up to do a refactor in how we do leaders in a future PR with a clear scope for that specifically.

[vyzo]

just a minor formatting nit, looks good.

[julienh-ssv]

@vyzo @y0sher fixed the formatting and rebased on top of stage to get the linter fixes

[iurii-ssv]

Nice changes, just some questions & minor suggestions from me.

[iurii-ssv]

LGTM!