Proposal Timeout-Leader Election Deadlock Under Byzantine Equivocation Attack

[JamesEjembi]

Problem Statement / Feature Objective

When a Byzantine primary sends equivocating proposals (two different blocks at the same height), the existing timeout-based leader election can deadlock: honest replicas that locked on different equivocations cannot reach a quorum to advance, and the timeout is never reset because each replica believes progress is possible.

Technical Invariants & Bounds

• Equivocation detection: 2 conflicting proposals at same height with valid signatures.
• Locking rule: a replica locks on first proposal it sees (no unlock until next view).
• Timeout progression: linear from 4s, doubling each view (4s -> 8s -> 16s -> capped 120s).
• Deadlock threshold: >5 consecutive views without a committed block.
• Recovery: fallback to synchronous consensus after 5 deadlocked views.

Codebase Navigation Guide

• src/consensus/proposal/equivocation-detector.rs — equivocation detection.
• src/consensus/leader-election/timeout-leader.rs — timeout-based leader rotation.
• src/consensus/consensus-engine.rs — main consensus loop.
• src/consensus/recovery/fallback-sync.rs — synchronous fallback.

Implementation Blueprint

1. In equivocation-detector.rs, upon detecting equivocation, broadcast an EquivocationProof message with both proposals.
2. In timeout-leader.rs, when an EquivocationProof is received, immediately advance to the next view without waiting for timeout.
3. In consensus-engine.rs, after 5 deadlocked views (no commit), trigger fallback-sync.rs which runs a synchronous Byzantine agreement (PBFT-style) for one view.
4. In fallback-sync.rs, all replicas exchange locked values and the one with highest view-number lock is chosen as the fallback proposal.
5. Chaos test: inject a Byzantine primary that sends 2 equivocating proposals; verify recovery within 6 views.