I have a question related to the nullifier nf and nullifier key nk in the context of kudos.
The current RM report says: r.nf = h_nf(nk, r) and that nullifier public key r.npk = h_npk(nk).
Let’s say I create my own Kudo token.
1a. What is used here as the nk ? Is it the creator’s private key (in this case my own)?
If so, the RM report says that this is a bad idea and that I shouldn’t be able to compute the nullifier:
In particular, the resource creator should not be able to compute the resource nullifier, and as the nullifier key allows to compute the resource’s nullifier, it shouldn’t be known to the resource creator. At the same time, the resource plaintext must contain some information about the nullifier key. One way to fulfil both requirements is, instead of sharing the nullifier key itself with the resource creator, to share some parameter derived from the nullifier key, but that does not allow computing the nullifier key or any meaningful information about it. This parameter is called a nullifier public key and is computed as r.npk = h_npk(nk).
Remark 4. Note that these concerns are not meaningful in the contexts with lower security requirements.
In the existing Juvix examples, we often use the pub key of the resource creator as the r.npk.
1b. Is the resolution to this that Kudo creation is such a “lower security” case?
2 . What steps must happen in detail if the r.nf is added to the nullifier set, and who is doing them?
In particular, I am wondering why we are putting an owner field in the Kudo data and checking this with a signature if in fact the person/entity with the nullifier key nk is deciding about the consumption. Do we even need an owner field?
This is not application-specific and defined on the resource machine instantiation level.
For example, in Taiga the nullifier key is randomly generated. The user generates a nullifier key, computes the nullifier public key and shares the nullifier public key with the solver so that the solver can create resources for the user.
I think you can implement kudos as both shielded or transparent application, “lower security” mostly refers to the way you instantiate the resource machine, not the way you develop your application, because with a higher security properties instantiation you still can write both transparent and shielded applications, which is not the case for purely transparent instatiations
So there are some resource fields that can be related to the application (e.g., logic, label, value, quantity) and some fields that don’t make that much sense in that context (e.g., npk, eph, rseed). The nullifier public key in particular is independent of the application logic and its distribution is not fixed in the protocol (the user might publish their npk once, might change it every 5 minutes, might deliver different npks to different solvers, combine all of these options, etc), so this is not something to rely on designing the application logic
For simplicity I would see as resource fields that make sense to consider writing the application:
logic: constraints
label: fixed per kind data
value: volatile data
quantity: either by having variable quantities as a meaningful part of the application or just employing the balance mechanics to enforce constraints
eph: for balancing and ephemeral resources - the ones we create and consume in the same transaction
The rest (nonce, rseed, npk) - not really. Some applications designed for a concrete RM instantiation might take advantage of those in some way, but I don’t think this is something we need to think about