[AIP-45][Discussion] Safe Burning of User-owned Objects

[davidiw]

AIP-45 Discussion

Summary

As a byproduct of the objects, users can acquired undesirable and unmovable content associated with their account address on Aptos. Currently, most applications on Aptos will typically share all Digital Assets and Fungible Assets associated with an account both to the account holder and those viewing the account. Because objects can be rendered undeletable, also known as soul bound, a user may be victim to undesired airdrops. To mitigate this issue, we propose leveraging a mechanism that allows users to unilaterally transfer any owned-object to a global burn address.

Goals

As a result of this AIP, users will be empowered to manage the data associated with their accounts on Aptos by removing direct linkage from undesired data to their account by moving its ownership to a safe burn address. In order to do this, all objects will have the ability to be transferred to the burn address.

If we delay enacting this, users will need to wait until their applications adopt allow-list frameworks to render content.

Out of Scope

This is only a mitigation, a victim cannot opt-out of receiving unsolicited content nor automatically remove this content. Burning also does not result in the burner receiving a refund, but the cost of doing so is expected to be negligible, that is, the cost of transferring a digital

Read more about this AIP here

[alnoki]

@davidiw does this break supply tracking for Coins, e.g. if someone burns a Coin at their account? Or does this only apply to certain object types?

[davidiw]

No, it shouldn't. So the reason why this is considered "safe burning" is that no assets are actually deleted or lost. An admin of a coin type, could reclaim "burned" coins.

In effect, this is basically like moving the data or asset to an account that doesn't exist.

[alnoki]

No, it shouldn't. So the reason why this is considered "safe burning" is that no assets are actually deleted or lost. An admin of a coin type, could reclaim "burned" coins.

In effect, this is basically like moving the data or asset to an account that doesn't exist.

@davidiw Got it, thank you for the clarification. Would a more appropriate term then be "rejection", "quarantine", or similar?

Typically "burn" is associated with destruction, rather than just moving to an offsite storage facility

[davidiw]

Hmm... in Ethereum burn is just a transfer to a specific address.
The goal here is to discuss it from the user perspective and not the implementation details.

[alinush]

The AIP says:

The burn address is defined as 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff or the largest valid unsigned 256-bit number. Upon acceptance of this AIP, a special Aptos name will be reserved for the burn address.

Is it possible to avoid reserving an ad-hoc address for this?

If future AIPs will similarly require reserving an address (for some purpose that serves them), it could become tricky to keep track of these. For example, it might complicate indexer logic, etc.

[alnoki]

Is it possible to avoid reserving an ad-hoc address for this?

@alinush I favor the approach of not reserving an ad-hoc address, in lieu of an approach that truly removes the objects from existence

[davidiw]

The AIP reviews 3 approaches. The only truly viable pure on-chain solution is a burn address. Burn addresses are pretty common in other Web3 ecosystems. Yes, it is sad to have a reserved address, but we already have 11 (0x0 -- 0xa). I'd be happy to discuss more rigorous solutions such as allowing deletes directly but without or trait-based dispatch, I cannot conceive a pattern that would actually allow an owner to safely reclaim storage.

If you have a counter proposal, happy to discuss.

[alnoki]

more rigorous solutions such as allowing deletes directly

e.g. allowing dropping of structs without the drop capability?

I'd guess this would just be a VM-level exception that only gets invoked in response to a special txn type