The sync state of the node affects some key components and processes in the node, since some of them rely on having most up to date data and blocks.
The node cannot participate in any consensus process until it has all up to date data from nodes.
Sync - Gossip deadlock
Syncing the node requires the node to query it's peers for all blocks, transactions, ATXs and NIPoSTs so that it can calculate current mesh state that in consensus. While the node queries all peers and receives the synced data some more data is likely to be shared via gossip. since validating the data requires all previous data to be present - when a node is syncing data it does not listen to gossip network.
So the issue that arises is - how do we know when to open gossip so that messages can be validated
Enabling gossip
the first solution is to store all blocks received in gossip for the last layer- when sync will finish the data stored will need to be validated. this solution will allow us to be up to date with all data
Second proposal requires no use of additional memory- to have an intermediate state where node both listens to gossip but does not participate in consensus yet - for 2 layers, but still continues to try and sync these last 2 layers.
This will allow to listen to newest gossip data and still sync missing data.
This creates a transient state between not synced and synced - Gossip sync
in this state, the node listens to gossip but does not participate in consensus yet
The state maching transitions are described in the following diagram:
The describes state machine describes the transition of the entire node state, it can be reduced to the toggling of a single state identifier that will toggle between 3 states: Not synced, Sync + Gossip and Synced.
The state transition between modes affects the processes in the node. as described above, some processes can work only when the node is synced. the following table describes for each component whether it should be active or not in different stats of sync
countvonzero
commented
1 year ago
General description
The sync state of the node affects some key components and processes in the node, since some of them rely on having most up to date data and blocks. The node cannot participate in any consensus process until it has all up to date data from nodes.
Sync - Gossip deadlock
Syncing the node requires the node to query it's peers for all blocks, transactions, ATXs and NIPoSTs so that it can calculate current mesh state that in consensus. While the node queries all peers and receives the synced data some more data is likely to be shared via gossip. since validating the data requires all previous data to be present - when a node is syncing data it does not listen to gossip network. So the issue that arises is - how do we know when to open gossip so that messages can be validated
Enabling gossip
The describes state machine describes the transition of the entire node state, it can be reduced to the toggling of a single state identifier that will toggle between 3 states: Not synced, Sync + Gossip and Synced.
The state transition between modes affects the processes in the node. as described above, some processes can work only when the node is synced. the following table describes for each component whether it should be active or not in different stats of sync