You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have multiple limits in place to restrict max state witness size: doc
Also see #12701.
Enable space sharing between different parts of state witness
Currently we enforce limits separately for each part of the witness. We can improve space utilisation if we carry over unused size as we execute the chunk. For example we process transactions first and then add unused part of combined_transactions_size_limit to main_storage_proof_size_soft_limit when executing receipts.
All credit for this idea goes to @jancionear who originally proposed it in zulip.
Switch from 'soft' to 'hard' limit for main storage proof
Currently we have to be pretty conservative with main storage proof at 4MB because the next receipt could make it 8MB (because max receipt contribution can be another 4MB). Instead we can increase that limit significantly (let's say to 7MB) and then include the last executed receipt only if the previous size together with this receipt's contribution does not exceed the limit, otherwise put the receipt to the delayed queue. This effectively changes this from 'soft' to 'hard' limit since now it won't be exceeded.
The text was updated successfully, but these errors were encountered:
Description
Currently we have multiple limits in place to restrict max state witness size: doc
Also see #12701.
Enable space sharing between different parts of state witness
Currently we enforce limits separately for each part of the witness. We can improve space utilisation if we carry over unused size as we execute the chunk. For example we process transactions first and then add unused part of
combined_transactions_size_limit
tomain_storage_proof_size_soft_limit
when executing receipts.All credit for this idea goes to @jancionear who originally proposed it in zulip.
Switch from 'soft' to 'hard' limit for main storage proof
Currently we have to be pretty conservative with main storage proof at 4MB because the next receipt could make it 8MB (because max receipt contribution can be another 4MB). Instead we can increase that limit significantly (let's say to 7MB) and then include the last executed receipt only if the previous size together with this receipt's contribution does not exceed the limit, otherwise put the receipt to the delayed queue. This effectively changes this from 'soft' to 'hard' limit since now it won't be exceeded.
The text was updated successfully, but these errors were encountered: