In the RM spec there’s a note on computing the transaction balance change:
Specifically it says that the kind-distinctness property of h_{\Delta} allows computing the balance change without having to explicitly distinguish between resource kinds.
Our question is, what instantiation of h_{\Delta} can we use in the transparent RM, and how can we use its kind-distinctness property to compute the transaction balance change without having to partition the input/output resources and subtract the relevant quantities?
I assume this is an example of such a hash? Correct me if I am wrong. From here:
An example of a function that satisfies these properties is the Pedersen commitment scheme: it is additively homomorphic, and its kind-distinctness property comes from the discrete logarithm assumption.
I do have the same question regarding kind distinctness. Seems like we are assuming in that link that kind and q are postulated there but the initial property only state the existence as a possible hypothesis.
As we are discussing the Resource Delta page, I was wondering whether we should make explicit that we will need additive inverses to be computed efficiently (for the Δₜₓ, e.g. here). Or how is the minus sign to be interpreted? \Delta_{tx} = \sum{r^{in}.\Delta} - \sum{r^{out}.\Delta}
This is based off my understanding/recollection from last Tuesday where “everybody” seemed to agree that we need subtraction (and we have subtraction in this PR).
I saw this but assumed it was suitable for the shielded RM. Can something simpler be used for the transparent RM that still does not require us to partition the resources on a transaction?
If we must use a Pedersen commitment scheme, how do we implement it concretely? It’s not clear to me.
Well, basically for every kind kind we just say that h(kind, -) := id_F - the identity function - for whatever field F you are working over. It is a field homomorphism, so everything is preserved as in the Delta computation description. So we would just compute the difference between quantities for delta computations, that’s it
I guess kind-distinctness property is not supported, as it is easy to compute the q it presupposes. We should maybe ask @vveiln whether such a requirement for the transparent case can be relaxed
We cannot figure out how to compute the transaction balance change from a transaction because
We don’t know where we get the ‘plaintext’ of each of the transaction’s resources. Each transaction action contains commitments and nullifiers only. We need the plaintext to obtain the quantity of the resource.
If we had the ‘plaintext’ resources, we do not know which are input and which are output (in order to determine the sign in the delta sum).
We wondered if the spec is hinting that some property of h_{\delta} and the delta proofs meant that obtaining the ‘plaintext’ resources is not required.
@paulcadman and I just had a quick discussion in private where we both agreed that there is an evident solution which I personally thought we kinda agreed on. I will write down the thoughts I expressed down here and let @vveiln , @Michael , @ray tell me if I am completely off the rails here.
So from all of our discusssions it seemed to me that what made an RM transparent is that whenever there is a hash used, we could use very dumb functions which basically do not hide any information. So, e.g. using the identity function on e.g. some binary compiled representation of an an object which can therefore be returned to its plaintext form easily. So, e.g. a consumed resource will be just put, e.g. in its binary format into the nullified field.
This solves 1: we have access to the commitments and nullifiers, so we’re done.
For 2: this can be specified in a separate filed in the action proofs. If I understand correctly, this is what the Node is doing.
So an example of delta for a transparent RM can be a simple map between kinds and quantities with addition defined as: \Delta_1 = \{k_1: q_1, k_2: q_2\}, \Delta_2 = \{k_1: q_1', k_3: q_3\}, \Delta = \Delta_1 + \Delta_2 = \{k_1: q_1 + q_1', k_2: q_2, k_3: q_3\}
what made an RM transparent is that whenever there is a hash used, we could use very dumb functions which basically do not hide any information
Just picking some nits here, but I think it might be helpful to have a shared understanding of this: what makes an RM transparent is that regardless of the kinds of hashes it uses (identity or not), it doesn’t satisfy the privacy requirements of the ideal shielded RM. This makes it a somewhat vague definition in the absence of a definition of the ideal shielded RM, but roughly it has to provide data and function privacy, which in cryptographic sense not only means that nobody can figure out who you are and what you do, but they can’t infer any useful information about that from the publicly available data
Note that it is only the property we decide to highlight (and in relation to some other property, i.e. there is no transparent RM if there is no idea of a shielded RM), e.g., succinct RM can be both shielded and transparent, and so this property doesn’t uniquely define the type of RM.
Using the resource plaintext as the nullifier works fine (as I understand, that is what you suggest), and if you use resource plaintexts as nullifiers, you can distinguish consumed and nullified resources from the component name (is it said to be the nullifier?), you don’t need an explicit tag attached to the plaintext in this case (it is the same for the shielded implementation nullifiers and commitments - they are just field elements, so if you don’t know that this random field element is a nullifier, you can’t really guess it from just looking at it)
an explicit tag is attached just as a pointless personalization so when i’m debugging and looking at arbitrary values that came out of some piece of code, i have some idea about their provenance. it doesn’t really do anything
However — there is a place with an explicit tag attached that does get used, but it’s not related to commitments or nullifiers at all.
It’s the “which resource am I” field passed to a resource logic, currently called tag in the spec, which is implemented as {polarity, plaintext} where polarity is created or consumed. This is just some arbitrary field element in the shielded implementation and I really don’t know how this is supposed to come about at all. Do I just provide a make_tag API here on the client?
Yeah. You would have to verify the inclusion anyway to make sure the resource in the tag is some resource in the nullifier/commitment set, but adding an explicit flag would save you half of the search.
Also if you write applications that are supposed to work in both shielded and transparent systems, the constraints have to be written for resource plaintexts (because in the shielded system the tag and the plaintext wouldn’t collide), so you would have to then do the work of matching the tag to the plaintext and constraining the plaintext