Burnable Tables

[sanderpick]

Now that tables are more easily browsable via the OpenSea collection pages and the forthcoming Admin UI, the many test / throw away tables seen on some chains have become an eye sore.

We currently don't implement ERC721ABurnable, which allows people to—you guessed it—burn tables. "Burning" a table would delete it from storage, and mark the tableID as burned. A burned table would not show up on the collection pages.

Upgrading to a burnable ERC721A is easy. We'd inherit from the burnable extension and delete controller entries when a table is burned. The bulk of the work would reside in the validator, where we'd need to handle Transfer events to the zero address, and delete rows from system tables.

[asutula]

What do you mean "and delete associated system tables"? I don't imagine deleting the actual table in question, so just wondering what you mean.

[sanderpick]

But, maybe not needed. As you say, we probably don't want to delete the actual tables, since they may be relied on my other tables. So, removing the entries in system tables would be odd.

[jsign]

But, maybe not needed. As you say, we probably don't want to delete the actual tables, since they may be relied on my other tables. So, removing the entries in system tables would be odd.

This is a quite an interesting topic. If we never delete tables because they maybe rely on other tables, we should consider how related tables can be threatened by nobody paying for the burned one. Perhaps that depends on what we come up with about what "burning a table" means for payments.

Tables depending on other tables create a dependency where people should be aware of risks maybe. If my app depends on data in 4 tables with different owners, the app data availability is as good as the weakest link.

Just sharing a stream of thoughts here; this might be slightly offtopic.

[carsonfarmer]

It is important to consider for sure. We have some other pending tension(s) around foreign key constraints and when they might be viable/not allowed that is related. I think we'll have to draw a line in the sand at some point. There are lots of implications here, versioned tables, (dis)incentives to store burnt tables, foreign keys and joins, etc.

[sanderpick]

IIRC, we decided in some tension awhile back that we'd would not enforce direct dependencies between tables. But, we could still support foreign keys with NO ACTION actions (https://www.sqlite.org/foreignkeys.html). @asutula you had some ideas here awhile back. Can you create a tension around that?

I'll make some assumptions here around payments to clarify this tension:

• Once a table is "burned", it can't be written to anymore. Its owner would become "unknown" and its controller would disappear. So, write costs are not of concern.
• It could still be queryable, but for how long would depend on if validators considered it worthwhile to keep storing it to earn read fees. Assuming reads are directly paid for over payment channels, these wouldn't involve on-chain reward cycles, and we wouldn't need an on-chain record of the table.
• If there's no on-chain record, validators couldn't earn regular storage rewards... so, likely they would drop it.

Lot's of unknowns here. I think we can let this one marinate and revisit with more info.

[carsonfarmer]

I actually do have a draft tension around foreign key constants based on @asutula’s original questions in discord/notion. I’ll aim to get that moved onto GitHub this weekend. You can chime in there if you want @asutula (unless you get to it first).