test(local-cluster): ensure liveness after second notar fallback condition

[ksn6]

Test to validate the Alpenglow consensus protocol's ability to maintain liveness when a node needs to issue NotarizeFallback votes due to the second fallback condition.

This test simulates a scenario with three nodes having the following stake distribution:

• Node A: 40% - ε (small epsilon)
• Node B (Leader): 30% + ε
• Node C: 30%

The test validates the protocol's behavior through two main phases:

Phase 1: Node A Goes Offline (Byzantine + Offline Stake)

• Node A (40% - ε stake) is taken offline, representing combined Byzantine and offline stake
• This leaves Node B (30% + ε) and Node C (30%) as the active validators
• Despite the significant offline stake, the remaining nodes can still achieve consensus
• Network continues to fast finalize blocks with the remaining 60% + ε stake

Phase 2: Network Partition Triggers NotarizeFallback

• Node C's turbine is disabled at slot 50, causing it to miss incoming blocks
• Node B (as leader) proposes blocks and votes Notarize for them
• Node C, unable to receive blocks, votes Skip for the same slots
• This creates a voting scenario where:
  • Notarize votes: 30% + ε (Node B only)
  • Skip votes: 30% (Node C only)
  • Offline: 40% - ε (Node A)

NotarizeFallback Condition 2 Trigger

Node C observes that:

• There are insufficient notarization votes for the current block (30% + ε < 40%)
• But the combination of notarize + skip votes represents >= 60% participation while there is
  sufficient notarize stake (>= 20%).
• Protocol determines it's "SafeToNotar" under condition 2 and issues NotarizeFallback

Phase 3: Recovery and Liveness Verification

After observing 5 NotarizeFallback votes from Node C:

• Node C's turbine is re-enabled to restore normal block reception
• Network returns to normal operation with both active nodes
• Test verifies 10+ new roots are created, ensuring liveness is maintained

Key Validation Points

• Protocol handles significant offline stake (40%) gracefully
• NotarizeFallback condition 2 triggers correctly with insufficient notarization
• Network maintains liveness despite temporary partitioning
• Recovery is seamless once partition is resolved

[qkniep]

Alternatively, we could test the second notar fallback condition even without the leader equivocating: Have 40% of stake be offline (not even issuing votes), the rest is split (roughly) 30-30 between receiving the block (and voting notar) and not receiving it (and voting skip). Then, safe-to-skip does not hold, neither does the first safe-to-notar condition, so the second safe-to-notar condition is required for liveness.

[ksn6]

Alternatively, we could test the second notar fallback condition even without the leader equivocating: Have 40% of stake be offline (not even issuing votes), the rest is split (roughly) 30-30 between receiving the block (and voting notar) and not receiving it (and voting skip). Then, safe-to-skip does not hold, neither does the first safe-to-notar condition, so the second safe-to-notar condition is required for liveness.

Appreciate the simpler test! Updated the test to employ this setup.