Skip to content
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

Better usage of state witness space #12751

Open
Tracked by #103
pugachAG opened this issue Jan 16, 2025 · 1 comment
Open
Tracked by #103

Better usage of state witness space #12751

pugachAG opened this issue Jan 16, 2025 · 1 comment
Assignees

Comments

@pugachAG
Copy link
Contributor

pugachAG commented Jan 16, 2025

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 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.

@shreyan-gupta
Copy link
Contributor

This ties in a bit with #12701, so let's see if we can merge the efforts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants