You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a validator syncs, it sends out a duplicate block request for a certain height, despite already having received a response for that height from the earlier request.
Specifically, it requests blocks of a certain range (e.g., 1 to n+m with m>1), and then advances to block n. Then, it sends out a block request for height n+1 again, despite it already being in the initial block range request.
The bug slows down the syncing of validators.
Steps to Reproduce
Run the ./devnet.sh script with 4 validators, turn off 1 validator. Let it run for ~30 blocks. Then, start the fourth validator and let it sync. Consider adding logs to snarkOS for sync profiling.
Expected Behavior
The validator should use the block already sent to it and advance to it (and further).
Your Environment
snarkOS branch kp/profile/sync/ in ProvableHQ/snarkOS
macOS
Debugging notes
In sync_storage_with_blocks, there are two places where we advance with blocks - without and with BFT checks.
The issue is for cases where we advance with BFT checks. sync_storage_with_blockdoes not always update the canon ledger. Thus, self.canon can't necessarily tell until which height we already parsed responses.
While the block is still in self.latest_block_responses, this member is in Sync and not in BlockSync. A refactor should consider the entire syncing logic, and how Sync and BlockSync relate.
The text was updated successfully, but these errors were encountered:
🐛 Bug Report
When a validator syncs, it sends out a duplicate block request for a certain height, despite already having received a response for that height from the earlier request.
Specifically, it requests blocks of a certain range (e.g.,
1
ton+m
withm>1
), and then advances to blockn
. Then, it sends out a block request for heightn+1
again, despite it already being in the initial block range request.The bug slows down the syncing of validators.
Steps to Reproduce
Run the
./devnet.sh
script with 4 validators, turn off 1 validator. Let it run for ~30 blocks. Then, start the fourth validator and let it sync. Consider adding logs to snarkOS for sync profiling.Expected Behavior
The validator should use the block already sent to it and advance to it (and further).
Your Environment
kp/profile/sync/
inProvableHQ/snarkOS
Debugging notes
sync_storage_with_blocks
, there are two places where we advance with blocks - without and with BFT checks.sync_storage_with_block
does not always update the canon ledger. Thus,self.canon
can't necessarily tell until which height we already parsed responses.self.latest_block_responses
, this member is inSync
and not inBlockSync
. A refactor should consider the entire syncing logic, and howSync
andBlockSync
relate.The text was updated successfully, but these errors were encountered: