revert 2478

[open-junius]

Description

The pr will revert #2478. need handle the storage in precompile when subnet de-reg.

Related Issue(s)

• Closes #[issue number]

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

[jeremyp-tao]

As explained in the PR this is a non-issue, it doesn't add any risk for the user.

On the other side clearing an unbounded map of substrate is NOT SAFE as highlighted in the Substrate docs (hense why they provide cursor logic to do in multiple steps). But if this is not needed, better to not touch the map.

If really you want to prevent allowances to "leak" over de-reg (not a real issue), you can add a generational ID to the approve so approves on previous reg is considered 0. No storage cleaning and no leak. If you want that I can make a PR to implement that.

[open-junius]

As explained in the PR this is a non-issue, it doesn't add any risk for the user.

On the other side clearing an unbounded map of substrate is NOT SAFE as highlighted in the Substrate docs (hense why they provide cursor logic to do in multiple steps). But if this is not needed, better to not touch the map.

If really you want to prevent allowances to "leak" over de-reg (not a real issue), you can add a generational ID to the approve so approves on previous reg is considered 0. No storage cleaning and no leak. If you want that I can make a PR to implement that.

As explained in the PR this is a non-issue, it doesn't add any risk for the user.

On the other side clearing an unbounded map of substrate is NOT SAFE as highlighted in the Substrate docs (hense why they provide cursor logic to do in multiple steps). But if this is not needed, better to not touch the map.

If really you want to prevent allowances to "leak" over de-reg (not a real issue), you can add a generational ID to the approve so approves on previous reg is considered 0. No storage cleaning and no leak. If you want that I can make a PR to implement that.

I just prepare the PR, will discuss with team later about how to continue, and if put it in the main upgrade.