I think I might understand post-ordering execution wrongly since it seems to imply more than I imagine. The way I understand post-ordering execution is that the solver submits a transaction “template” that describes the idea of what should be done and fills in some of the fields, but in the post-ordering phase the placeholders are replaced with the actual values.
- Do we assume that submitted transactions that imply post-ordering execution being valid before ordering?
- If no, how to tell the difference between an invalid transaction and a transaction that will be valid after ordering?
But back to my understanding: such a definition practically means that post-ordering execution is not possible for shielded transactions (I describe it a bit further here) since they must have all the fields ready. But it seems there are other things that happen post-ordering that do affect shielded transactions? I would be helpful to understand better how per-node storage writes come out of post-ordering execution. I don’t have an intuition for that now and so I can’t see how it applies to shielded transactions. Can users affect what is written in per-node storage if they have a particular desire to have something stored but do not need it in the blob storage?
From your description it seems to me that we make sure that users can specify what to write to the blob storage easily, which makes a lot of sense to me, but I don’t understand how to access this state in the shielded case and how it can be used in a helpful way there. At the same time per-node storage can be useful, but doesn’t have the same guarantees, so it might not be what is needed. I think a better understanding of post-ordering execution will help me with it