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

Do not delete frozen accounts. #210

Open
mikhailUshakoff opened this issue Feb 13, 2024 · 2 comments
Open

Do not delete frozen accounts. #210

mikhailUshakoff opened this issue Feb 13, 2024 · 2 comments

Comments

@mikhailUshakoff
Copy link

The storage size of a frozen account is minimal, about 1 cell and 327 bits, as it only stores the hash of the stateInit. Currently, accounts are deleted when their debt(due) exceeds 1 ever. However, if an account is frozen with a balance near 0, the time before it is deleted is more than 30 years.

For safety reasons, we propose not to delete frozen accounts. This will ensure that the account remains in the blockchain and can be unfrozen and used again in the future if needed.

@Rexagon
Copy link

Rexagon commented Feb 13, 2024

The problem with account deletion is that the previously large contract could accumulate a fairly large debt (for example due to FastStorage "feature"), and now, when it goes into a frozen state, this debt is preserved and the subsequent transaction deletes it.

I agree with the proposed solution, since it is not so expensive to store frozen accounts.

@mnill
Copy link

mnill commented Feb 14, 2024

I agree, this is an absolutely logical change. As @Rexagon said, the main issue with deletion is that a contract can accumulate a very large debt before it gets frozen, and then it will be removed immediately without a 3-30 year waiting period. However, my wish is that this should be marked as temporary, meaning that currently we are not deleting contracts but only freezing them. But in the future, when, for example, storage transactions are introduced, which will prevent contracts from accumulating a large debt and ensure they are frozen in time, we will revert back to deletion. This is because if you write contracts using opcodes, it's very cheap to create many contracts, and they do have some impact since it's necessary to update the merkle proof of the shard's state.

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