hotstuff_rs::block_sync

Module client

source
Expand description

Implements the BlockSyncClient, which helps a replica catch up with the head of the blockchain by requesting blocks from the sync server of another replica.

The client is responsible for:

  1. Triggering Block Sync when:
    1. A replica has not made progress for a configurable amount of time.
    2. Or, sees evidence that others are ahead.
  2. Managing the list of peers available as sync servers and a blacklist for sync servers that have provided incorrect information in the past.
  3. Selecting a peer to sync with from the list of available peers.
  4. Attempting to sync with a given peer.

§Triggering Block Sync

HotStuff-rs replicas implement two complementary and configurable block sync trigger mechanisms:

  1. Event-based sync trigger: on receiving an AdvertisePC message with a correct PC from the future. By how many views the received PC must be ahead of the current view to trigger sync can be configured by setting block_sync_trigger_min_view_difference in the replica configuration.
  2. Timeout-based sync trigger: when no “progress” is made for a sufficiently long time. Here “progress” is understood as updating the Highest PC stored in the block tree - in the context of the HotStuff SMR, updating the Highest PC means that the validators are achieving consensus and extending the blockchain. The amount of time without progress or sync attempts required to trigger sync can be configured by setting block_sync_trigger_timeout in the replica configuration.

The two sync trigger mechanims offer fallbacks for different liveness-threatening scenarios that a replica may face:

  1. The event-based sync trigger can help a replica catch up with the head of the blockchain in case there is a quorum of validators known to the replica making progress ahead, but the replica has fallen behind them in terms of view number.
  2. The timeout-based sync trigger can help a replica catch up in case there is either no quorum ahead (e.g., if others have also fallen out of sync with each other), or the validator set making progress ahead is unknown to the replica because it doesn’t know about the most recent validator set updates. Note that in the latter case, sync will only be succesful if some of the sync peers known to the replica are up-to-date with the head of the blockchain. Otherwise, a manual sync attempt may be required to recover from this situation.

§Block Sync procedure

When sync is triggered, the sync client picks a random sync server from its list of available sync servers, and iteratively sends it sync requests and processes the received sync responses until the sync is terminated. Sync can be terminated if either:

  1. The sync client reaches timeout waiting for a response,
  2. The response contains incorrect blocks,
  3. The response contains no blocks.

In the first two cases, the sync server may be blacklisted if the above-mentioned behaviour is inconsistent with the server’s promise to provide blocks up to a given height, as conveyed through its earlier AdvertiseBlock message.

§Available sync servers

In general, available sync servers are current and potential validators that:

  1. Are “in sync” or ahead of the replica in terms of highest committed block height,
  2. Notify the replica’s sync client about their availability,
  3. Have not provided false information to the block sync client within a certain period of time specified by the blacklist expiry time. By “false information” we mean incorrect blocks or incorrect highest committed block height (used to determine 1).

Keeping track of which peers can be considered available sync servers is done by maintaining a hashmap of available sync servers, and a queue of blacklisted sync servers together with their expiry times.

Structs§

Enums§

  • BlockSyncClientError
    The block sync client may fail if there is an error when trying to read from or write to the [block tree][BlockTree].

Functions§