pub trait FullReachability { }Expand description
Assumption (Full reachability during synchronization). After GST, a correct driver’s
ChainClient::synchronize_chain_state reaches every correct validator, not merely a
quorum of them.
This is the weakest link in the liveness argument, and it is stated separately for that
reason. LockRecovery needs the proposer to learn the highest lock held by any correct
validator, because a single correct validator holding a lock above the proposer’s will reject
the proposal (UnlockingRequiresHigherCertificate) and may be exactly the weight that a
quorum was missing.
What the implementation actually guarantees is weaker.
Client::synchronize_chain_from_committee dispatches
synchronize_chain_state_from to every validator but aggregates through
communicate_with_quorum, which stops once a quorum has answered plus a grace period of
quorum_grace_period (default DEFAULT_QUORUM_GRACE_PERIOD, 0.2) times the time that took;
still-pending responses are then dropped. A correct but slow validator holding the highest
lock can therefore be missed.
Why this is usually not observable. A validator holds a lock at round p only because it
received a ValidatedBlockCertificate at p, which the client that assembled it pushes to
every validator; so the ordinary way for a lock to exist at one validator and not at a quorum
is a partition that GST has since healed, followed by that validator being slow in exactly the
synchronization that matters. ChainClient::process_pending_block also retries: on a rejection
whose consensus-state snapshot is unchanged it performs one explicit fallback
synchronize_chain_state and retries, and the caller’s loop re-enters the whole procedure. The
combination makes the assumption hold with probability tending to one over retries rather than
deterministically.
Residual obligation. Making this a theorem rather than an assumption requires the
synchronization step to wait for all correct validators — or, more cheaply, for a rejection
carrying ChainError::HasIncompatibleConfirmedVote to trigger a targeted pull from the
rejecting validator, as NodeError::WrongRound already does through
chain_client::Error::LocalNodeLagging. It does not: the lag-report path in
RemoteNodeUpdater::sync_remote_if_needed matches only the round and height mismatches. The
fallback path is also noted as untested in the source (TODO(#6453)).