Consideration for "deletes" in addition to "reads" + "writes"?

[jakerockland]

Howdy!

@ryley-o and I are team members over at Art Blocks, where we've been working on adding some of the fancier gas savings techniques re: storage, influenced by this SSTORE2 library, for our in-progress core contract updates and realized that for our purposes having the capability to perform "delete" operations as part of the library was important.

Would love to get input from your side as to whether or not this idea was already explored and decided against, and if so additional context on why. Or, if this wasn't yet explored for SSTORE2 (e.g. wasn't in scope) if you would be interested in / open to us sending a pull request to update your implementation to make use of a similar approach as is used in our implementation.

tl;dr, we've updated the approach used in the two SSTORE2 implementations that we're familiar with to add the added functionality of:

a) supporting safe-deletion in addition to writes and reads (this is important in our opinion if this type of pattern becomes widely adopted to allow for reduction of chain bloat where relevant, for example if one uploads one version of a file but they mess up the upload and then want to re-upload pre-launch).
b) allows for introspect-ability of who wrote a given block of data to chain which has some interesting properties that this enables, you can see more about my musings on this here: ArtBlocks/artblocks-contracts#307 (comment), which I've copied inline here:

The introspect-ability of this author/writer data is interesting because it enables some interesting use-cases for systems-of-applications (dApps that use multiple smart contracts). For example, in the case of the Art Blocks ecosystem, this introspect-ability allows us to potentially build in the future a tool that allows a collector to input into a given tool the contract address for a deployed script's data, and have that tool use this introspection to reverse-lookup the core-contract that the said script is associated with (e.g. is it an Art Blocks flagship core-contract, an Art Blocks Engine core-contract, an auxiliary registry Art Blocks contract that writes some other provenance related data to chain-state via BytecodeStorage, etc.).

Anyway, tl;dr, here is the current implementation of this SSTORE2 variant, any thoughts/feedback/input is greatly appreciated and would love to know if there is interest on your end in us sending a PR with these adjustments back into this library:
https://github.com/ArtBlocks/artblocks-contracts/blob/36a0598f498bbdfe63602c21f86a514b9b25b97a/contracts/libs/0.8.x/BytecodeStorage.sol

[jakerockland]

Note: I've updated the BytecodeStorage.sol reference link above to make use of including ArtBlocks/artblocks-contracts#308.