Store the runtime code in the light client database #863
Conversation
| @@ -620,9 +659,24 @@ impl<TSrc, TRq> InProgressWarpSync<TSrc, TRq> { | |||
| let runtime_parameters_get = if let Phase::RuntimeDownload { | |||
| header, | |||
| warp_sync_source_id, | |||
| hint_doesnt_match, | |||
| downloaded_runtime: None, | |||
There was a problem hiding this comment.
This specific line fixes a bug mentioned in the CHANGELOG where the warp syncing downloads the runtime code twice.
|
Is this caching works if I run the light client using the substrate-connect library? |
|
That's more a question for substrate-connect, but yes for the 4 well-known chains (once substrate-connect has upgraded their smoldot of course). |
|
Do I understand correct that even if I don't have substrate-connect extension (I'm using the Electron environment) the latest state of the smoldot will be saved and when I run my Electron application next time this saved state will be used? The example:
User actions:
The question: |
|
Substrate-connect is kind of pointless if you don't have the extension, and I would suggest to directly use smoldot. |
Close #92
As explained in #92, we can't just store the runtime code in the database (doing so would require #177), but the Merkle value of the trie node and the closest ancestor.
When the database is loaded back, the warp syncing queries said closest ancestor and compares the Merkle value of the relevant children with the one in the database.
In practice, the storage query is thus now only around 850 bytes, compared to ~1.0 to 1.5 MiB beforehand.
While this "only" saves around 300ms on my machine, I can imagine that people with not-so-good Internet connections will be happy.
I'm not super-super happy with the changes in the code, and I've added all these fields while having in mind that they will be removed again after #177, but they're also not too bad.