Just as an operational note to add to @isheff’s comprehensive description of what’s possible - the transaction function (which runs post-ordering) could request time attestations (e.g. from the controller), and use those as inputs to compute the final transaction (including, potentially, resource data). Proofs for resources so computed cannot be created before ordering, yes, but resource could be split out so that this isn’t such a big deal - e.g. suppose that I have a shielded resource that can only be transferred (or, more generally, acted upon) before time t:
Pre-ordering
- I consume my resource, create whatever corresponding new resource, and create a carrier resource for the timestamp check
- I create a shielded proof that the transfer is correct
Post-ordering
- The transaction function runs and computes the latest controller-attested timestamp, which is used as input for the timestamp check carrier resource logic proof
- As long as the controller-attested timestamp is less than the timestamp in the carrier resource, the transaction is valid and we’re done
- No information needed to be revealed other than this timestamp check carrier resource
Now, there’s a little bit of an annoyance here - the timestamp check carrier resource must predict a timestamp which will be after the controller’s attested timestamp at the time the transaction is ordered, and this prediction will have some error, so that in effect our transaction must be crafted before t - e for some epsilon e. In practice for many applications this seems unlikely to be an issue, since controller timestamps are unpredictable anyways.