This is true as long as resource logics are directly circuits, but would not be true if we used an additional layer of recursion / a zkVM for resource logics, right? (in which case, we could select at runtime how many and which resources to pass in, as long as the logic is able to understand them).
Iām afraid not. Circuits are a worst-case check and donāt depend on how they are created. If Iām wrong, pls correct me.
we could select at runtime how many and which resources to pass in, as long as the logic is able to understand them
It could be possible and leads to different kinds of resource logics by passing different numbers of resources in. But it might not be one kind of resource logic that can accept variable resources.
It makes sense for ephemeral/intent resources because they can be created after the number is determined in the ptx. But for normal resources (like a Token), the logic is fixed. If the number passed to the logic changes, the Token type changes.
For now, resource logic loads all the resources and treats them equally in Taiga so that we can do forall/negative checks.
It would be an architecture modification to support the variable inputs.
Summary of requests for clarification from @mariari:
- Need to specific what public inputs and what private inputs for resource logic proofs are.
- Need to specify how correspondence of public inputs to resource logic proofs is checked.
- Need to specify how public inputs for resource logic proofs relate to transactions which are āin progressā in the flow (i.e. not yet balanced).
- Need to work out an example of a post-ordering counter increment.
- Need to work out an example with a token swap where one of the tokens (X) requires that a counter be incremented every time it is transferred (checked with an ephemeral resource), both where the counter increment is performed pre-ordering by the solver and where it is performed post-ordering by the executor.
- Need to specify how binding signatures currently work (even if this will change).
- Need to work out example timelines (orderings of events) with more details on what the inputs are in the specific examples and who does what computation, makes what proofs, etc.
cc @vveiln
1 Like
Most requests I can come up with were already in the summary from @mariari
Just a few additions:
- need to specify what statement, private inputs, and public inputs are for compliance proofs.
- need to specify how to check the correspondence of public inputs between resource logic proofs and compliance proofs
- Do we still have the sub-vp(dynamic vp) conception in RM?
- Note encryption
- VP commitments(resource logic commitments?) and functional privacy: even without functional privacy atm, we may still need a trivial vp commitment in compliance proof to enforce the specified resource logic to execute.
- more details about nullifier keys would be better(e.g., nullifier keys are needed to consume resources, but only nullifier public keys are required to create resources.)
- more details about ephemeral flag mechanism(e.g. when the flag should be true or false; a fake but existed merkle root is required when consuming a ephemeral resource)
- Is
Pi_ptxin the examples the compliance proof?
A general question: is the Spec for an abstract and generic conception description or development documentation? Itās good enough for an abstraction. Developers may expect a very concrete and detailed
definition of parameters and protocols like the Zcash protocol.
1 Like
Here are a minor thing and an actual question.
an atom is a natural number
ānatural numberāāāfield element of \mathbb{F}_hā
Could we (ab-)use .^ notation instead of SCRY or have the analogy to urbit complete?
https://docs.urbit.org/language/hoon/reference/rune/dot#-dotket
multiplication operation Z_n Ć Z_n ā Z_n Ć F_2 (with overflow indicator)
The product of two Z_n should be a Z_{n^2} (or a Z_n Ć Z_n).
Why does the preference function have to return a real? That raises a lot of uncomfortable questions for me, and I assume thereās a need for application/domain-specific sidebands to direct composition and guide solvers anyway; so why not just make it an ordering function taking two ptx and returning a tristate?
It makes sense to me to use a disjoint union to compose commitments and nullifiersāI assume thatās what prevents double-spendābut why is it necessary for proofs?
1 Like
Just to take on this part of your question - a real preference function is structured in a way that we want; namely, preferences must take a consistent partial order - if pref x > pref y, and pref y > pref z, pref x > pref z. This is not necessarily true of a simple ordering function, which could rank x > y, y > z, and z > x. A real preference function is also much more conducive to mathematical analysis of e.g. structure of the preference space, degree of preferences, etc. What uncomfortable questions are raised?
Ah yes, I see.
Mainly the problem I have is that itās suggesting the existence of some policy issues early but not actually dealing with them. EG: the paper uses the example of a linear function, but maybe you would want to use a logarithmic function? And how are preference functions composed; can I make my preference function have a higher weight than somebody elseās by putting my result always in [0.9 1] rather than using the full [0 1] range? Those are questions that probably do need to be answered, but on an application/domain-specific basis, with application/domain-specific sidebands.
I was thinking: for a given ordering, we can derive lots of order-preserving functions from the domain to R (or whatever), so this increases expressiveness (since you can choose which such function to use), but not in a useful way. But youāre right the set of functions Ptx x Ptx ā 2 or 3 is also larger than the set of orderings on Ptx. So thatās not so nice. Hrm.
2 Likes
Need to specific what public inputs and what private inputs for resource logic proofs are
Some of that started here: VP Runtime Environment - HackMD
If expression of preference (and it having weight) is free, any self interested actor is incentivized to game it.
If some cost is tied to preferences being taken into account, systems with some robustness properties against the above can be built. The cost could be expressed in resources, or it could be requiring some amount of preexisting trust.