At the application layer, concepts like ownership of resources are important for many different reasons. Ownership, in the sense that a specific identity can permit or prohibit the consumption of a resource it owns, does not exist at the resource machine level, so we need to implement it on top of that.
Resource consumption in the resource machine
To consume a resource at the lowest level, two things have to happen:
A nullifier has to be created.
The resource logic has to be satisfied.
Satisfaction of the resource logic depends on the contents of a TX containing the resource. Computing the nullifier, requires knowledge of the plaintext resource. These two requirements are not tied to each other by default, s.t. anyone who knows the plaintext of a resource could authorize consumption within a TX satisfying the resource logic.
Implementing consumption authorization in resource logics
To tie the two requirements together and close the gap we could implement ownership tied to an identity in a resource logics as follows:
Pick an encoding convention for placing an external identity (or a commitment to one) in the value field of a resource to determine the current owner of the resource.
Add a check to the logic that checks wether this identity signed over a transaction involving the resource.
Add a check to the logic that the information required to compute the nullifier is verifiably encrypted to the external identity of the new owner of a resource created after consumption of the current one.
Thanks to
@vveiln for explaining how consumption works as a primitive and @cwgoes for discussion on the resource logic implementation.
Thanks for the writeup! A few points that we may want to explore further here:
There is some subtlety here - we don’t typically want to check that the external identity owning the resource signed over the entire transaction, just that it (they?) signed over a part of it (e.g. I should sign A-for-B, if I own A). This is quite similar to how RM proofs need only take a subset of resource data as input, so that may be sufficient (since the signature is checked in the logic anyways), but we should probably work through a few example cases to make sure.
I think another option we may want is for a resource to be owned by another resource. For example, this would be used for account abstraction (where I want a stable name for a set of keys that may change over time). In this case, the resource logic of the owned resource should check that an ephemeral resource is included in the transaction with the right authorization message (generalized signature), and which can only be created by the account resource. The account resource, in turn, will check whatever authorization logic it encoded for producing that ephemeral resource. I think that this authorization message could also include what identity the nullifier creation information is supposed to be encrypted to, which can allow us to “chain” ownership properly. For the sake of overall simplicity, it may be also worth using this pattern (ephemeral resource authorization) even for direct external identity signatures. /cc @vveiln wdyt?
I assumed one would sign an unbalanced transaction which permits the consumption, but yes, this information needs to be preserved end-to-end.
Do composed transactions retain information about the parts they are composed of in general, or could they when required?
If there is no mechanism for this, we should canonicalize at least a special case for ownership, but it seems a general mechanism to preserve composition information would be useful.
In building Anoma, has the team considered the costs and benefits from building the chain using UTXO, account-based, or object-oriented account models?
Given the high flexibility and complexity of interdependent transactions envisioned for the project, I’m curious whether an object-oriented account model would introduce additional functionality and features to help it achieve its end goal?
Note: please disregard. I’ve reviewed other posts in Protocol Design page and it looks as though Anoma is trying to get the same functionality of object-oriented accounts.