Skip to content

Feat/adaptive consensus timeouts#406

Merged
Xhristin3 merged 2 commits intorinafcode:mainfrom
Chrisland58:feat/adaptive-consensus-timeouts
Apr 28, 2026
Merged

Feat/adaptive consensus timeouts#406
Xhristin3 merged 2 commits intorinafcode:mainfrom
Chrisland58:feat/adaptive-consensus-timeouts

Conversation

@Chrisland58
Copy link
Copy Markdown
Contributor

feat: Adaptive Consensus Timeouts with Network Condition Monitoring

Problem

BFT consensus proposals used a hard-coded 24h timeout. During network degradation, validators
couldn't reach quorum in time, causing proposals to expire and consensus to fail with no
recovery mechanism.

Solution

Introduce a dynamic timeout system driven by observed network conditions:

  • Monitor — NetworkCondition tracks avg_latency_ms, consecutive_misses, and a derived
    NetworkHealth (Healthy / Degraded / Critical)

  • Dynamic timeouts — create_proposal calls adaptive_timeout() which scales the base 24h timeout
    by health:

    • Healthy (0 misses) → 24h
    • Degraded (≥1 miss) → 48h
    • Critical (≥3 misses) → 72h
  • Graceful degradation — vote_on_proposal auto-increments the miss counter when a proposal
    expires; execute_proposal resets it to 0 on success, so the system self-heals as network
    conditions improve

  • Observability — update_network_condition and get_network_condition are exposed as contract
    entry points for external oracles/admins to feed in latency data

Changes

  • types.rs — NetworkHealth enum, NetworkCondition struct
  • storage.rs — NETWORK_STATE key
  • bft_consensus.rs — adaptive timeout logic + self-healing miss counter
  • lib.rs — two new contract entry points + type re-exports
  • 4 new tests covering all health states and the full miss/reset lifecycle
    closes Fix potential consensus timeout in network degradation #250

- Add NetworkHealth enum and NetworkCondition struct to types.rs
- Add NETWORK_STATE storage key
- Implement get_network_condition, update_network_condition, adaptive_timeout
  in BFTConsensus (Healthy=1x, Degraded=2x, Critical=3x base timeout)
- create_proposal uses adaptive_timeout instead of hard-coded constant
- vote_on_proposal increments miss counter on expiry (graceful degradation)
- execute_proposal resets miss counter on successful consensus (self-healing)
- Expose update_network_condition and get_network_condition via contract API
- Add 4 tests covering all health states and miss counter lifecycle
@drips-wave
Copy link
Copy Markdown

drips-wave Bot commented Apr 23, 2026

@Chrisland58 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@Xhristin3 Xhristin3 merged commit ad7c56a into rinafcode:main Apr 28, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix potential consensus timeout in network degradation

2 participants