-
Notifications
You must be signed in to change notification settings - Fork 829
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
Validator emits Possible compression bomb encountered
for ah-next
#7664
Comments
Does the failure in backing cause the parachain to author blocks 1 -> 2 -> 3 -> 1 -> 2 ... in a loop? this is the outcome that I see in the parachian log. |
Is coming from here:
So, is it possible this parachain creates a bigger PvF than that ?
Yes, that's exactly what you are going to see, because with async backing the collator always tries to build ahead 3 blocks(1,2,3), then if those fail to be backed it tries again an so on, until the chain progresses. |
Ah yes, @kianenigma your uncompressed PVF was 14mb right? |
Yes:
But I am using the compressed one to generate the chain spec, which is 2MB. Double checking now |
The entire chain-spec is:
|
Ah, I see, this line tries to decompress it -- and it will be bigger than the limit. Short term, I can hack a custom polkadot node with a higher limit. But if I am not doing anything wrong, and the normal AH runtime will be more than 12MiB, we will have to do a node upgrade before AHM -- CC @seadanda. We would also take this into account for Westend, but we can use the hacky way. @alexggh thank you very much for the input! What constraints would we have towards increasing this limit in production? |
It seems like AssetHub westend for example was close to this limit, but below it:
Probably due to adding like a dozen pallets to AH, now it is above the limit. |
What drives this limit? Is it just a safe but conservative limit or is there a calculation/reasoning behind this exact number? |
I don't know the history of it, we will have into looking if this can be safely increased. Another, thing to note here is that if we actually do need to increase all validator would probably have to be upgraded before we can use the new value, and that proved to be a really slow process on both kusama and polkadot. |
We should look a little bit into these wasm files and do some optimizations.
|
First reported by @kianenigma on element.
Spawning a zombienet network from these instructions, the relay chain does not back any blocks.
On the validator logs I see:
The text was updated successfully, but these errors were encountered: