-
Notifications
You must be signed in to change notification settings - Fork 74
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
Full node should load consensus data from chain storage instead of storing it in database #1752
Comments
First we should refactor the code that builds the chain information. cc #1681 |
mergify bot
pushed a commit
that referenced
this issue
Oct 10, 2022
Close #1681 Right now the code of `warp_sync` and `chain_spec` both build a `ChainInformation` struct by making runtime calls. However the code of these two modules is completely different. Because these two modules were built very early on in smoldot's history, they are getting help from the sub-modules of the `chain_information` module, that are also very old. This PR modernizes all of this: it removes all the sub-modules under `chain_information` and merges them into one that does everything. This new module is now used by `warp_sync` and `chain_spec`, and `warp_sync` and `chain_spec` are now more simple. I'm also planning to use this new module in order to refactor the SQLite database. (#1752) This PR slightly changes the behavior of the warp syncing: we now download the runtime, then build it, and then only download the call proofs to obtain the chain information. Right now all the downloads are done in parallel. This change is in principle more correct. At the moment we blindly call functions that we expect to exist. By downloading and building the runtime first, we can check the list of supported functions and then only call them. (cc #949) This is really not a problem at the moment because none of the functions that we use has ever been deprecated, but it could have become one in the future.
I've realized a problem with #2845, which is that there were moments when we didn't provide any runtime function to get the GrandPa current set id. |
This can't be done in we want to support syncing from scratch. We can, however, implement this if we force the full node to warp sync. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Instead of storing the Aura/Babe/Grandpa authorities in the database, the full node should load them from the chain storage.
Before tackling this issue, one should check whether it is actually possible to load everything from the chain storage.
The text was updated successfully, but these errors were encountered: