-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Light client - verification failed for requesting missing blocks #2295
Comments
Looking deeper into this it is interesting that requesting missing block Possible theory: other nodes are unable to locate the requested block However this failing shouldn't lock-up the whole queue which let me think that somewhere there is a reference to block |
Your assessment is correct. Specifically a request to a block with the oldest locators in the future of that block will return an empty response. The oldest possible locator to any given head height is always the most recent macro block. Generally such requests should never be send, as it can be determined before sending it that the response will be empty, making it pointless. On the other hand it should also not prohibit progress if they are. |
Exactly @nibhar, just came to the same conclusion. The direction of the |
It should also no longer be necessary as a more recent macro block has been adopted. |
Ok I am fairly confident that I have found the cause to this. Let's assume To begin with our Node knows block number Before that request resolves the node sees Now the block queue can happily push block Now the Missing blocks request from earlier resolves and we get Now within the That creates another missing bocks request. This time for |
The fix should be as easy as adding a sanity check before the predecessor check into the I.e. // Check if the block is still relevant if not discard it.
if self.blockchain.read().macro_head().block_number() >= target_block_number {
return None;
} I will try and see if I can create a test for this first though. |
Proposed fix on this branch |
New issue checklist
README
General information
Bug report
When a light client has to request missing blocks, there is a chance that the verification of this request fails. It could be that this issue exists for quite a while now but never really got noticed until in recent versions light clients had a low peer count (#2277) and not all gossipsub block header messages are received (#2288). Because of this combination, the node has to perform more missing block requests, probably causing the chance of this issue occurring to increase. When the verification fails the node is unable to continue accepting new blocks and can't recover from this state. Even when the macro sync kicks in.
It appears that blocks that already have been accepted, are requested as missing blocks. Also it tries to push it again from the missing block response.
Note block 17778523 and 17778525 in the following snippet. And gossipsubs of 17778524 and 17778526 to be out of order.
Crash log? Screenshots? Videos? Sample project?
light-client-falling-behind.log
The text was updated successfully, but these errors were encountered: