-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Optimize the block resyncing #3537
Comments
I don't see how this can work at all. And consensus history has nothing to do with block correctness. The last point from #3463 is more viable as a shortcut, but it's nothing on its own, proper state sync should be available first. And then people should always have an ability to check the full chain if they'd like to. Right now it's about 1h of time. Not a small number, but not a very big one either. |
this is for a verified "noverify". first of all, its not 1 hour in c#, far from it, second, even if its 1 hour, why cant we make it 50 minutes |
I think that is good to verify only when consensus changed (only in bulk sync), but if it's wrong, we need a checkpoint |
If you trust blocks you're importing (like you really trust that dump file), you can skip signature verification completely and hashes are to be checked anyway (see |
checkingpoints as @shargon said is the solution. |
But you currently can import with noVerify, isn't it? |
yes, this issue is trying to have a solution to have the speed of "noverify", while make it verifiable. |
We can create an enum, { verify, noVerify, verifyEpoch } |
Summary or problem description
Currently, when synchronizing the blockchain, we need to verify the signature of each block to ensure data authenticity and integrity. This process is extremely time-consuming, requiring verification of numerous signatures. We aim to optimize this process to improve synchronization efficiency.
Do you have any solution you want to propose?
We propose implementing a selective verification mechanism:
To ensure the correctness of the updated consensus nodes, we hardcode the consnesus address history in the neo core.
Where in the software does this update applies to?
The text was updated successfully, but these errors were encountered: