DL defines authorisation rules for specific denominations (that are not a part of what it means to be a kudo and the part we wanted to explicitly separate). We expect to have different DLs for different denominations
And user logic is user-dependent.
Merging user logic with denomination logic would mean that:
each denomination is defined per user which I’m not sure we want, but we might
if Alice has denomination AliceKudo and includes Alice’s receive rules, then Bob sending Alice BobKudo wouldn’t trigger the receive logic by default OR we would have to involve the AliceKudo logic in it, which is not clear from design perspective (why would BobKudo transfer involve AliceKudo logic?)
The receiving logic signature is verified in KL, right. Same mechanism for Intent resource in the swap tf
I’m not sure we want to have a separation between the private (function privacy?) and shielded (no function privacy?). From the RM perspective it is the same. In fact I think we would like to have fp whenever we can and separation of these cases might make it harder.
There is no change transaction function right now. If there was, there would be the check corresponding to that.
There is no hierarchical denomination generation. Bananas#500 and bananas#50 are two different denominations with different DLs. The DL itself might have a recursive structure, but this is also not covered here (since DL isn’t covered here, it is a future post work)
In your DL you might just not allow swaps that swap for apples. Or have a whitelist for creators if you want to be the only issuer. Or enforce signature verification to approve every issuance/transfer. It acts kinda like a KL extension.
The KL is shared between all denominations, it is in the logic field of each kudo resource. DL is referenced in the label, and there is one DL per denomination.
I’m not exactly sure what you mean by “banana#n” structure, specifically what “#n” part means and maybe this creates confusion. I treat all kudos that differ in label as distinct denominations, and I suppose the “#n” part would be a part of the label, so from that perspective “banana#1” and “banana#2” are equivalent to “kudo of denomination#1” and “kudo of denomination#2”
To be clear, I’m not advocating for one or other approach. The PRF was an example of a different way of authorizing policies (there may be more), and a motivation of why would be good to abstract that part. Just wanted to bring it up, but for the sake of concreteness and simplicity, you can stick to signatures.
Regarding function privacy vs shielded case. It is slightly out of scope, and you probably know more. My understanding is that depends on what relation is being verified in zero-knowledge, if the ‘universal’ or a specific one. So, one could implement a shielded application without function privacy, if desired, or even a partially shielded one. For example, it is conceivable that someone wants a traceable kudos system but hiding who are the parties participating in the system, some sort of ‘traceable digital cash’. But this are just my own thoughts.
I totally agree that more layers would create a clearer layout. I also share @Michael’s concern about increased resource needs, compliance and logic proofs, as well as the importance of ensuring correspondence checks between logics.
Yes, user logic layer can not be merge. If I understand correctly, KL defines common logic for all kudos, while DL defines logic for specific denominations. They are conceptually separate. Can we encapsulate them into a single application logic layer. To invent a new denomination, we derive the common logic and specify the specific logic for the denomination in one logic/resource.
I still struggle to see why we want to split logic into multiple resources.
The Kudos prototype that I’ve described in my ART report and implemented (with slight modifications) in Juvix features 1-3 except for the double permissioned transfer / receiver authorisation part in 2. that should be easy to add.
It does so with exactly one logic function for all Kudos kinds (that differ by their labels that include all the denomination-specific information).
It allowed you to create multiple denomination (differing by their symbols) and limit the supply to be fixed (one-time mint by the originator/issuer identity) or to be unbound (repeated mint and burn by the originator/issuer identity). All of this with one resource.
To me, this satisfies all the requirements above already. Am I missing something? Why isn’t this enough for v0.3?
Why do we want to do this (now)? As an exercise or to explore potential object models?
Note that the Kudos app you’ve linked in your first post is a “simplification” of the previous Kudos version (and the one described in the ART report) that had more features (but didn’t run on the Anoma node).
I looked into it a bit thinking about having better guarantees for authorship proofs. It didn’t help with the problems there, but it made me wonder: what concrete schemes for it do you have in mind?
Either way it is good to keep this idea in mind. Would also be nice to have an explicit comparison between the signature approach and the PRF approach for solving various problems. It seems to me that these approaches are alternatives in certain contexts but in other contexts you can’t get the same properties from one that you get from the other. It would be cool to explicitly specify such contexts. Signature schemes are a common and familiar tool, but if PRFs are better in some contexts, we should be open to that.
I don’t think that function privacy property is application-dependent. The application developer develops the application thinking about data privacy only + considers some pre-defined size constraints. The difference between FP and the lack of FP happens only when we decide if to prove the logic or the outer, application-independent circuit (gives us function privacy), but we don’t need to modify the logic
I’m not sure we can. The only reliable mechanism for triggering a logic is to tie it to a resource, it seems. Initially I was trying to have a hierarchical structure of logics, so that the KL triggers DL without an extra resource associated with the DL, but the only way I see to do that is to verify the DL proof inside the KL:
the KL uses the VK of DL from the resource label and tuns the verifier for the DL proof. The DL circuit is supposed to take as input the resources from the same action, so the prover proves DL with the resources from the action. To verify it, the KL passes the resource tags and whatever else is needed. The problems I see here:
the KL is supposed to know which arguments each different DL takes, which is not likely to happen
a recursive proof like that might be much more expensive in the end
If the DL proof is not verified in KL and there is no resource enforcing the DL check, we don’t have the enforcement mechanism to ensure there is a relevant DL proof in the same action, it seems to me. Do you see other ways to do it in a way that KL doesn’t have to be aware of the DL structure?
One of the main requirements for the design was to abstract away the authorisation logic (Point 2 in here), which is exactly the difference between the existing implementation and the proposed design. It is done at the cost of 1 extra resource (ephemeral, zero value) per denomination and 1 extra resource (ephemeral, zero value) per user (for conditional receive). Different traits (ownable, etc) do not require extra resources.
This design is not to satisfy the short-term goal for v0.3, but I think this is a planning issue. The design goals for the design were long-term, so we shouldn’t have put it in the short-term plan, as we have already discussed. I think it is okay
We have discussed it on the call already, I just put it here so that it doesn’t get lost