syncer: insufficient criteria for a node to become synced #4931
Labels
Comments
bors bot
pushed a commit
that referenced
this issue
Aug 31, 2023
## Motivation Closes #4931 ## Changes - make sure state is synced before declaring node is synced - reduce gossip sync from 10 min to 2 min - do not print confusing log "failed to build proposal" when node is not synced ## Test - manually synced with mainnet ## TODO - [ ] Update [changelog](../CHANGELOG.md)
bors bot
pushed a commit
that referenced
this issue
Aug 31, 2023
## Motivation Closes #4931 ## Changes - make sure state is synced before declaring node is synced - reduce gossip sync from 10 min to 2 min - do not print confusing log "failed to build proposal" when node is not synced ## Test - manually synced with mainnet
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
currently node will declare itself synced when it fetched all atxs/ballots from peers.
it doesn't wait for the state to be synced with the network.
and when a node become synced, it starts to participate in hare and tortoise consensus.
we found that the condition is insufficient for the node to become synced for the following reason.
blocks were downloaded only when one of the following conditions is satisified.
A. the node received a valid block certificate
B. tortoise verified the block to be valid
when a node become synced, and the state lags, hare will finish but unable to generate blocks, because its state is different from the majority of proposals in the hare output.
and when blocks are not locally available when hare finishes, tortoise will vote against the block in the next layer.
the ripple effect causes the node to lag even further and produce bad votes for the network.
proposal
sync all data up to layer N and call
ProcessLayer/TallyVotesup to layer N until no errors is returned fromProcessLayer()The text was updated successfully, but these errors were encountered: