Problem
Resource destruction calls a destructor. If the destructor fails (explicit panic or implicit e.g. integer overflow, index out-of-bounds, division by zero, etc.) the resource won’t get destroyed - more specifically, the operation that removed the resource from storage gets reverted.
The fact that resource destroy can fail is a problem, because user pays for storing their resources. More specifically, user’s Flow token balance gets locked in proportion to the storage used by their account. This means that if a user owns a resource which could not be destroyed, the Flow token values that is reserved to pay for the resource storage cannot be released.
This can be attacked for example by contract dev upgrading their contract function which the resources calls, which will increase the size of that resource, locking up more funds in the user’s account.
This problem gets amplified by attachments feature. Attachments make it easier to extend resources and they follow same destruction pattern as described above.
To complete the problem statement, the following needs to be considered:
- We want to give developers an ability to perform an action when a resource is deleted - for example, the FT contract decrements total supply counter on token burn.
- Resource destruction (the removal from storage AND the destructor call) needs to be atomic within a Tx execution to avoid front-running or similar edge-cases (if we for example wanted to send event that is processed in the subsequent block to decrement total supply counter)
💡 Solutions considered so far
Catch abort, forbid or roll back changes
Examples of code that could abort
- Arithmetic, overflow/underflow
- Force-unwrap of nil
- Storage reference target to empty
- Infinite loop, recursion, etc. (will hit computation limit)
- Destructor could abort, but also, object might be broken because code does not type check
- Not just execution a problem
- Also, “type checking” trolling
➡️ Discussion outcomes
- Not a problem with attachments. Rather, already today, the inability to force delete a resource is a problem – attachments worsen the situation
- The contents of a resource are potentially a bigger problem than the storage usage of the resource