-
Notifications
You must be signed in to change notification settings - Fork 69
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
Investigate PoV sizes #667
Comments
i can confirm this, collator is producing 1MB+ proofs for as long i can see in collator logs (2 weeks). do you have historical data about PoV size? |
I can only say it was still the case in July but don't have historical data below that. |
Might be related: paritytech/polkadot-sdk#1498 |
@cheme do you have a radix 2 flavor of https://github.com/paritytech/trie or whatever somewhere? |
Had this branch from 2020 paritytech/trie#84, but today it is a lot behind current trie crate (probably 1 or 2 days of work to update). |
it looks like we are attaching code wasm in every block proof. this is example list of tries we are building the proof from:
1st one contains our runtime code wasm:
why do we attach it in storage proof? |
Well you are probably using trie_version 0 (maybe state_version), with version 1 the value is not attach to the node and only include if accessed by the runtime. WARNING: switching requires a migration (or warpsync will be broken). So if using state_version 0, maybe you query an entry close to key ":code" eg ":codex" that would include the node (and its value) at ":code" into your proof.
yes wasm is in the top trie at key ':code' (utf8 values). |
With state_version set to 1. 2023-09-18 16:40:12 [Parachain] PoV size { header: 0.1787109375kb, extrinsics: 2.865234375kb, storage_proof: 4.306640625kb } So I guess, we should consider migrating. Would have some details how to do that? |
There is a link to the md guide and lot of link to different progress on relay chain https://github.com/paritytech/devops/issues/1508#issuecomment-1271565180 . |
sry, this link is broken for me, is it in private repo? |
🤦 yes it is a private one, the link to the guide was https://hackmd.io/JagpUd8tTjuKf9HQtpvHIQ (a post refering to it https://forum.polkadot.network/t/state-trie-migration/852). |
Solved by #799 and running migration on wasm |
gm
I wonder if you're aware of the PoV sizes of the blocks produced by both Basilisk on Kusama and HydraDX on Polkadot. Our scraping services show that the PoV contribution of each of your parachain is around 8GB per day, which is more than 1MB per PoV block on average (this is way above any other parachain).
Are you aware of this or know that might be contributing to the PoV size? (can also probably see the collators logs to confirm)
Given that there not enough extrinsics in the blocks to explain that, is it possible that you for example do some iteration in every block, reading some state? If not, that could indicate a bug in state proof recorder that includes some data it shouldn't.
The text was updated successfully, but these errors were encountered: