Skip to content
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

Open
Jim8y opened this issue Oct 17, 2024 · 8 comments
Open

Optimize the block resyncing #3537

Jim8y opened this issue Oct 17, 2024 · 8 comments
Labels
discussion Initial issue state - proposed but not yet accepted

Comments

@Jim8y
Copy link
Contributor

Jim8y commented Oct 17, 2024

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:

  1. Perform full signature verification only for blocks that change consensus nodes, ensuring the authenticity of these critical blocks.
  2. For other blocks, use the hash of the previous block (prehash) to verify their authenticity, without conducting full signature verification.
  3. This approach can significantly reduce computational overhead during the verification process while maintaining the overall security and integrity of the blockchain.

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?

  • Consensus
  • Ledger
  • Network Policy
  • P2P (TCP)
@Jim8y Jim8y added the discussion Initial issue state - proposed but not yet accepted label Oct 17, 2024
@roman-khimov
Copy link
Contributor

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.

@Jim8y
Copy link
Contributor Author

Jim8y commented Oct 17, 2024

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

@shargon
Copy link
Member

shargon commented Oct 17, 2024

I think that is good to verify only when consensus changed (only in bulk sync), but if it's wrong, we need a checkpoint

@roman-khimov
Copy link
Contributor

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 SkipBlockVerification in NeoGo). But if you don't, you have to check everything, because anyone can create a block with the same NextConsensus as current (or past) one and invalid signatures. I don't see how checking here and not checking there makes it better, it's either you trust input data or not to me (and the default of course is not trusting).

@Jim8y
Copy link
Contributor Author

Jim8y commented Oct 17, 2024

checkingpoints as @shargon said is the solution.

@shargon
Copy link
Member

shargon commented Oct 17, 2024

But you currently can import with noVerify, isn't it?

@Jim8y
Copy link
Contributor Author

Jim8y commented Oct 17, 2024

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.

@shargon
Copy link
Member

shargon commented Oct 17, 2024

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 }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

No branches or pull requests

3 participants