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
To address #8325 we previously raised the state-sync payload size form 64MB to 512 MB. However because we currently have a leak in the board and the wallet factory vats, mainnet blew over that limit and state-sync snapshots can no longer be restored. The board vat leak has been identified and fixed, but we still haven't diagnosed the wallet factory leak, so until such time we need to accommodate it.
Description of the Design
Raise the state-sync snapshot payload size to a number sufficient to cover the expected heap snapshot size of the of the leaking wallet factory vat running for 8 weeks. That number is likely about 1GB.
Security Considerations
I believe the limit exists to avoid a state-sync snapshot fetched from an untrusted peer cannot blow up the disk usage of the node. 1GB in that case is likely no more a problem than 512MB.
Scaling Considerations
None
Test Plan
Already tested raising this limit locally in a modified follower restoring from state-sync. #8325 included a test verifying the limit applies as expected.
Upgrade Considerations
Distributed as a chain software upgrade but does not affect consensus.
The text was updated successfully, but these errors were encountered:
What is the Problem Being Solved?
To address #8325 we previously raised the state-sync payload size form 64MB to 512 MB. However because we currently have a leak in the board and the wallet factory vats, mainnet blew over that limit and state-sync snapshots can no longer be restored. The board vat leak has been identified and fixed, but we still haven't diagnosed the wallet factory leak, so until such time we need to accommodate it.
Description of the Design
Raise the state-sync snapshot payload size to a number sufficient to cover the expected heap snapshot size of the of the leaking wallet factory vat running for 8 weeks. That number is likely about 1GB.
Security Considerations
I believe the limit exists to avoid a state-sync snapshot fetched from an untrusted peer cannot blow up the disk usage of the node. 1GB in that case is likely no more a problem than 512MB.
Scaling Considerations
None
Test Plan
Already tested raising this limit locally in a modified follower restoring from state-sync. #8325 included a test verifying the limit applies as expected.
Upgrade Considerations
Distributed as a chain software upgrade but does not affect consensus.
The text was updated successfully, but these errors were encountered: