I’m wondering now if we should have two distinct mechanisms for storage writes. From what I understand, it can be useful to specify writes to both storages since they seem to have different purposes:
- blob storage keeps data accessible post ordering
- per-node storage allows independent transaction verification and can generally can store stuff for whatever reason the user has
I think it is either that we never explicitly specify writes to the latter, or we should have them separate to have a clear distinction and avoid confusion.
We can either do it by introducing some structure to the deletion criterion predicate, or have two separate predicates. Or some other way, these two just came to mind now.
Side note: I think it would also be helpful to further think about distant time verification: if the transaction is to be a part of a roll up, then storing whatever data the user specifies is very different from when there is no roll up. If there is rollup verification, storing the data seems to be more of a user’s whim. If there is no rollup, everything must be stored, and if it must be stored, the user can’t be charged much for pretty much infinite storage (because it isn’t just for the user now, the whole chain status would depend on the ability to verify the transaction). Of course it may be not very practical, but it makes sense to consider if we don’t exclude this option. But this generally also introduces the distinction between must writes and want writes and they shouldn’t be treated the same, I think.
My understanding is that post- and pre- ordering execution partition the world of execution. Then what do we call shielded execution with a transaction candidate assembled by the solver? I think we used to call that pre-ordering execution, but even if we don’t, we need to call it something.