Light Client Committee Synchronization Skew Across Heterogeneous Finality Gadgets

[JamesEjembi]

Problem Statement / Feature Objective

The light client committee tracks finality across heterogeneous chains with different block times (e.g., 2s Substrate vs 15s Ethereum). Committee synchronization drift exceeds the timeout threshold during periods of high network latency, causing the light client to incorrectly report non-finalized headers as finalized.

Technical Invariants & Bounds

• Max clock drift: 500ms per hop.
• Committee sync timeout: 3x max block time of the target chain.
• Header cache: 256 most recent headers.
• Finality threshold: 2/3 + 1 of committee weight.
• Sync retry backoff: exponential, 1s -> 2s -> 4s -> capped at 30s.

Codebase Navigation Guide

• src/cross-chain/light-client/committee-sync.rs — committee synchronization.
• src/cross-chain/light-client/finality-verifier.rs — finality verification.
• src/cross-chain/consensus/header-cache.rs — header storage.
• src/cross-chain/types.rs — chain configuration types.

Implementation Blueprint

1. In types.rs, add BlockTimeMs to ChainConfig; compute SyncTimeout = max(3 * BlockTimeMs, 60000) per chain.
2. In committee-sync.rs, adjust the sync interval per chain: sync at BlockTimeMs / 4 frequency.
3. In finality-verifier.rs, add a grace period multiplier (1.5x sync timeout) before marking headers as finalized when sync drift is detected.
4. Add chain_finality_lag_ms gauge metric for each connected chain.
5. Integration test: simulate two chains at 2s and 15s block times with 800ms injected latency, verify finality lag < 10s on both.

[Primex-hub]

I would love to solve this issue and I can submit within 24hrs