[AIP-32][Storage Deletion Refund]

[msmouse]

AIP 32 - Storage Deletion Refund

Summary

Proposed is to refund part of storage fee (introduce in API-17) paid for storage slot allocation to the original payer when a slot is freed by deletion.

Link to AIP: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-32.md

[IriArt]

This looks very cool!

[Milkpartner]

That's cool.

[e99243506bigplay]

I wonder what is happening on final gas price if you are going repeat to upload 32k Move contract module.

[e99243506bigplay]

There is a situation:
Alice put a NFT on marketplace for sale, Bob is bought Alice's NFT, Question is, who got the Storage Deletion Refund?

[msmouse]

Alice put a NFT on marketplace for sale, Bob is bought Alice's NFT, Question is, who got the Storage Deletion Refund?

Depending on how the contract is written, if transferring the NFT implicates moving to a new storage slot, the original payer will get the refund on transfer and who ever sent the transaction to make the transfer pays the storage fee to allocate the new slot.

[meetrick]

That's cool.

[davidiw]

Why do we have the knobs for refunds and what are the proposed values?

[msmouse]

@davidiw The numbers are in the picture (as e.g. s) but tentatively: 90% refund if deletion happens within one day after creation, and then the refund ratio starts to degrade linearly for 30 days until 50%.

[elliottdehn]

If you want the refund, clear it yourself!

I have a practical use-case for this, but it would require the refund to be returned to the one doing the clearing instead of the one that created the storage. We (Econia) maintain an exchange that features a limit order book. Each of these limit orders takes up storage, and can be "freed" upon being "filled" by any trader. If someone is creating thousands of small limit orders to clog up trading execution, which happens order-by-order until a fill size, then returning refunds to the attacker upon their orders being filled just gives them more ammunition to attack with! There is a cost to "bother with" a piece of storage. I would expect all or most of that cost to be refunded upon bothering with and freeing the storage.

Think of this as cleaning graffiti off the side of one's house: the one that did the spraying pays the price for removal. It wouldn't make sense to pay the sprayer back the cost of his act!

So if we return a refund to the trader who filled the order then we, in theory, make it possible to execute trades of any size at ~constant cost: every order that we bother with, regardless of size, provides a refund that allows us to continue--thereby defeating order book attacks and achieving maximum possible trading efficiency.

Reading storage, performing a little work, then clearing that storage, should be free or return positive gas.

Likewise

If we want to create a gas token, that is a token for which 1 unit associates with 1 piece of storage ready to be cleared, then returning the refund to the original storer makes this impossible. If I mint 1 gas token when gas prices are cheap and then sell that gas token to someone else when gas is expensive, they do not have the ability to yield the refund by clearing their bought and paid-for storage!

Furthermore

There is precedent here in Solidity and Ethereum having a storage refund that goes to the one doing the freeing. It's more efficient because the credits are always and immediately applied & storage freeing becomes a first-come first-served opportunity--this is ideal.

[msmouse]

@elliottdehn Thanks for the feedback. That's exactly what we look for via the AIP process! While the case you describe can be addressed by "billing accounts" described under the "Future potentials" section, it's not being implemented too soon, and that's why we are evaluating refunding to the deleter instead of the original payer as well. Stay tuned. (And keep the feedbacks coming! ❤️ )

[elliottdehn]

Thanks you @msmouse, can we know if/when there will (or might) be a decision made on this?

[msmouse]

@elliottdehn We update the AIP so that we refund to the deleter, we also will start with full refunds, putting the declining refund pending for discussion. Let us know if this works better.

[elliottdehn]

@msmouse Excellent! Happy to hear this, yes it works better. Nice to know the DOS risk that is refunding the original storer has been ruled out, which was going to prevent our ability to utilize the refund feature in our contracts. Thanks team!

[elliottdehn]

@msmouse I/we have a question about this feature: what is the maximum number of refunds offered to transactions? This matters because it affects the determination of a constant in our protocol which determines the maximum number of limit orders that can be processed one-by-one during a trade. In fact it's more likely that upon the volume of a price bucket not fitting a trade (can't be executed all together at once), and the maximum-size order in that bucket being less than N% of the remaining trade, we switch to a different mode of execution that relaxes some requirements in the interests of ensuring the whole trade can be executed. The N% kind of depends on the maximum number of refunds that can be obtained. Thanks.

Our protocol is blocked by the existence of these refunds so we eagerly await their implementation!

Edit: mainly it's because our implementation requires these refunds to prevent bad actors from denying service, and so if we run out of refunds then it's not safe to proceed with the trade as it may get reverted. In practice, 2^14 (~16K) refunds should be enough plenty to execute a normal trade under the worst possible DOS circumstances. Beyond that, it's very fair to stop refunding or taper off the amount refunded. This can come down by a factor of 128 if we weaken the precision of the exchange, but that's not 100% ideal.