| Status | COMMENTED |
|---|---|
| Stakeholders | |
| Outcome | |
| Due date | |
| Owner |
Background
Block synchronization is briefly discussed in whitepaper, nevertheless much more details are needed for this feature. Also several design decisions were taken during the implementation that influence other core modules. Therefore this document is meant to review in detail the current design of block synchronization and start a discussion of what changes are accepted by the core team and what needs to be corrected in the future.
Problem
Scenarios
The following are the scenarios for the block synchronization:
- New peer joins the validator network and needs to get the whole blockchain.
- The peer lost several commit messages due to poor internet connection and needs to get the latest blocks.
- The peer was stopped and restarted after some time and needs to get the latest blocks.
- ...
Solution
Gossip
For peers to discover that they do not have latest blocks, peers send their latest block hashes to all other peers in the network every N seconds. If a peer discovers that it has a different latest block hash, it will request the missing blocks from other peers.
Sequence Diagram
The sequence diagram here represents a scenario where new peer has joined the peer network. The peers latest block hash will be `[0u8, 32]`, while other peers would have different latest block hash, assuming they committed several other blocks. Therefore the new peer will request missing blocks.
Activity Diagram
Activity diagram represents a synchronization process from the moment of receiving the latest block hash to the moment when all the new blocks are stored.
Block Validation
To validate the signatures of the block the peer needs to have:
- The set of peers that were validators at the moment of discussing that block in consensus
- The order of those peers that defines their roles at the moment of discussion
Set of peers
The set of peers will already be up to date for this block validation on our peer as the initial peers set is taken from the `trusted_peers` file and new peers are added through AddPeer ISI, therefore only on block commits.
Order of peers
The order and therefore roles are defined based on the previously committed block hash. But the order is shifted every time a view change happens (when leader or proxy tail is faulty or the voting fails).
The synchronizing peer will definitely have a previous block hash, but it does not know the number of view changes (order shifts) that happened between the previous block and the new block were committed.
Therefore a new field was added to the block header: number_of_view_changes. It specifies the number of view changes that happened between the commit of the previous block and the commit of the block in which header it exists.
With this design both the set of validating peers and their roles are known to the synchronizing peer for each new block.