Hybrid reward model: activation & rollout (fork schedule, deployment, BlsG1 re-linking)

[luishsr]

Follow-up to the hybrid reward computation landed in feat/hybrid-reward-model. That change ships the reward math only; this issue tracks activating it on a network.

Background

The hybrid applyIncentives blend (80% participation / 10% Anchor Commit Share / 10% stake tier) and the off-chain participation tally (ConsensusHeaderParticipation + tally_hybrid) are implemented and tested, but nothing wires activation: no fork schedule, no change to which contract genesis deploys, no in-place upgrade path. Original issue: raylsnetwork/axyl-private#633.

Why rollout was deferred (surfaced during review / e2e)

1. ConsensusRegistry deployment/upgrade is non-trivial. It is a directly-deployed (non-proxy) contract that links the external BlsG1 library at owner.create(0) — a per-network address filled in at genesis. A naive bytecode swap carries a wrong, code-less library address and reverts (stake() reverts empty). This is e2e-verified, not theoretical. The upgrade must re-link BlsG1 for the target network, or the network must re-genesis.
2. Activation ABI must match the deployed contract at every block. The pre-hybrid contract serves a 1-arg applyIncentives; the hybrid contract serves 2-arg. The rollout must keep deployed bytecode and the node's reward-call path consistent across the activation boundary (fresh genesis vs. in-place upgrade), or the first epoch close halts the chain.

Scope of this follow-up

• HybridRewards hardfork in chainspec.rs (hardfork! macro, ForkCondition schedule per network)
• is_hybrid_rewards_active_at_block + .hybrid_rewards(block) builder; update schedule-length assertion
• CloseEpochTally enum threading (Legacy / Hybrid) in the EVM ctx; compute_close_epoch_tally picks tally() vs. tally_hybrid() by fork; new ConsensusRegistryV2 sol! binding for the 2-arg calldata (leave the 1-arg binding untouched for replay)
• Bytecode-swap migration (evm/hardforks/hybrid_rewards.rs) with correct per-network BlsG1 linking, or a documented re-genesis path
• Regenerate checked-in rayls-contracts/artifacts/ConsensusRegistry.json consumed by genesis
• Fork-boundary integration test in reth_env/tests.rs::test_close_epochs (pre-fork old ABI, post-fork new ABI, no revert either side); EIP-712 domain-separator self-heal check
• Full multi-node e2e (epochs.rs::test_epoch_boundary) post-fork
• Archive replay of hybrid epochs (richer snapshot format or direct ConsensusBlocks access) — SnapshotRewardsBackend::tally_hybrid currently hard-errors by design
• Decide the real participationFloorBps threshold against post-activation data; optionally make the weight constants governance-settable

Pre-activation validation available now

The hybrid tally can be computed against a real consensus DB and compared to the current leader-only split before any activation (the PoC measured a latency-injected validator going 5.7% → 19.8%).

[luishsr]

Rollout implementation is up as #88 (stacked on #80, base feat/hybrid-reward-model).

It lands the HybridRewards hardfork: an in-place ConsensusRegistry bytecode-swap migration that re-links the per-network BlsG1 address and the _rls/EIP-712 immutables read straight from the live contract — solving the BlsG1 blocker that deferred this — plus the fork-gated legacy↔hybrid applyIncentives ABI switch (clean whole-epoch cutover on the close block). Local activates at block 1; testnet/mainnet stay Never until SRE schedules a block.

Validated by in-process executor tests that execute the migrated contract: migration units, test_hybrid_rewards_fork_boundary (pre-fork legacy / post-fork hybrid + code-length migration proof), and test_close_epochs on Local. Remaining items from this issue — the concrete mainnet/testnet activation block, the pre-existing test_epoch_boundary chain-id bug (blocks the multi-node e2e; reproduces with none of these changes), and archive replay — are noted in the PR.