Minor note: the label must store a binding class name (e.g. a hash of the class logic or something), otherwise someone could simply insert different class logic in the transaction function.
I think we may be bundling two conceptually distinct choices into the “ephemeral” flag at present:
- The choice of whether a resource should have been created prior to this transaction or within it, and
- The choice of whether a consumed resource should have been created “from nothing” (i.e. commitment existence is not checked) or whether it should have been created at some point beforehand.
Namely, right now we have the choice between:
- Non-ephemeral resources, which must have been created before the transaction in order to be consumed (and included in some past commitment tree root), and
- Ephemeral resources, which can be created and consumed in the same transaction, but for which commitment existence is not checked.
As far as I can tell, we don’t have the ability to demarcate a type of resource which should be created and consumed in the same transaction and where commitment existence is checked. I think that this ability would be useful – not just for @mariari’s goals here, but also more generally.
To me, consuming resources that were never created before is really a special tool – in a sense, the boundary conditions of a linear logic – that should be used only for the purpose of introducing resources “out of nothing” from an application semantics perspective (such as newly created kudos) or vaporizing resources “into nothing” from an application semantics perspective (such as burning kudos) – it shouldn’t really be used for constraint-carrying.
I have a wee proposal that I think might reconcile our goals here:
- Split the “ephemeral” flag into a triple. Resource “ephemerality” can be either “spontaneous”, “transient”, or “persistent”. Both “spontaneous” and “transient” resources are ephemeral in the sense that they have no lifetime beyond a single transaction. “Persistent” resources behave as regular (non-ephemeral) resources do at present.
- “Spontaneous” resources are handled as “ephemeral resources” are currently.
- Commitments of “transient” resources are added to a temporary commitment tree and nullifiers of “transient” resources are added to a temporary nullifier set. In the transaction validity check, check that (a) all transient resources consumed in this transaction were indeed created in this transaction and (b) all transient resources created in this transaction were indeed consumed in this transaction.
- We would then use “transient” resources for constraint-carrying purposes (such as the one which @mariari has in mind here), so that
valuewould be checked.