Sets of ̶r̶e̶s̶o̶u̶r̶c̶e̶s̶-̶ persistables through the object oriented lens

RM/AVM
1

This post is addressing the question of how can we understand persistables
as objects? We start with the positive side of things.

Movable persistables

This case is best explained using an equivalence relation on (sets of) persistables that relates two (sets of) persistables whenever they are to be considered “the same”; let us denote this relation by ≃. We read 𝑋 ≃ 𝑌 as 𝑋 and 𝑌 are different incarnations of essentially the same persistable(s). The typical scenario that impliciclty has such an equivalence relation “built in” is when we allow to move (sets of) persistables between different controllers.

This cross-controller scenario is a good minimalistic example: we simply have different versions of “the same persistable(s)” over time; this is in direct analogy of several different versions of the same object over time, which is changing only accidental properties (and not essential ones, by which we mean properties that would change object identity).

The cross-controller example shows that we have a natural notion of time, flowing in some direction. Thus, we may go for an additional general partial order on (sets of) persistables such that 𝑋 ≤ 𝑌 means 𝑋 is a potential predecessor of 𝑌. Note that 𝑋 ≤ 𝑌 and 𝑋 ≃ 𝑌 may hold at the same time, which amounts to 𝑋 being an earlier version of 𝑌 . Note that ≤ is something like provenance in a deployed instance, in particular relative to one controller or several cooperating ones.

Now, we may have a sequence 𝑋1 ≺ 𝑋2 … ≺ 𝑋𝑛 , each change is via executing a valid transaction, and 𝑋1 ≃ 𝑋2 … ≃ 𝑋𝑛. Now each of the transactions can be thought of as a method call[1]. And there we have discovered a way to think of sets of persistables as transactional objects!

Singular persistable

This is a special case with one creation event and at most one consumption event. We only have a constructor and a destructor.

Next steps

Besides writing the above up in more detail, it would probably be nice to have the equivalences ≃ between different families of sets of persistables, such that each member of the family is an object such that we have several objects that are changing in cooperation with each other.

However, I think, there are many questions to ask: Please ask away and comment!

  1. In fact, this is precisely like a call to ?exec [LXK+22], taking the transaction description as program. ↩︎

5 Likes
2

What properties would change object identity? I’m not sure that the object identity is a question about the properties of particular persistables insomuch as it is a question about the relationships between persistables in transactions (since those are how method calls are represented), e.g.

  1. If I consume one persistable A and create another B in the same transaction, where A≃B for some suitable object-identity equivalence relation, A and B can be clearly said to represent successive versions of the same object.
  2. However, if I consume two persistables A_0 and A_1, and create just one B, or consume A and create both B_0 and B_1, what is happening at the object level here?
    • It’s possible that I’m combining two objects into one object (or splitting one object into two objects).
    • It’s also possible that I’m just changing one object, and either destroying or creating another object.

We might want some notion(s) of identity (and corresponding equivalence class(es)) which allow us to both (a) capture the historical ancestry relationships between objects and (b) preserve the object-level semantic difference between these cases (where destroying an object and creating two new objects is semantically different than making a new version of an object and creating one new object). I suspect that this might soon start to dovetail with @Jamie’s work on history-structures…

With proper tracking, I think we should be able to check (when it is the case) that X is an actual predecessor of Y, e.g. by embedding some hash-linked history in the persistable itself. In the limit case, perhaps we could model persistable-objects as carrying around commitments to their entire personal histories, although we’ll have to figure out operationally efficient ways of implementing that.

I’m being picky, but I think it would be slightly more accurate to think of transactions as sequences of method calls (transactional object-programs rear their head again) – transactions are atomic history-append operations, they can append entire message sequence diagrams, not just single calls (although I think modeling a transaction as a single outer call to an ephemeral-transaction-program-object is nicely elegant).

3 Likes
4

On the object level, the destruction of an object would lead to “spending” of the object ID; similarly, creating an object should give a new object ID. Both are relative to a encompassing set of principals that would ever be involved in the object in question, which means that objects IDs are relevant to (groups of) principals.

In particular, I would want them to have the same object id encoded in some of the fields of the persistable (or using the nonce field of resources).

Before I answer, avoiding object identity for a second and using Event Structure jargon for a moment (as it has a fairly good match with causation and events in natural language), we would have and event e with the following properties

  • A_i's final transaction (or method call if you prefer) a_i would be a causal predecessor of e (for i=0 and i=1)
  • the first transaction on B_i would have e as a causal predecessor (for i=0 and i=1)

Now, the question of what you do with object IDs is roughly independent: the canonical case is to destruct both of A_i and construct new B_i. For the general A_0, …, A_m and B_0, …, B_n case, you could take any “sub-permutation” of m and n points (for the right definition of sub-permutation, e.g., defined in terms of creation, annihilation, and preservation operators, possibly something like the free symmetric monoidal category on the creation 0 → 1, and annihilation operator 1 → 0 — would be fun blog post to write :slight_smile: ). TL;DR up to you how you want to change IDs. However, if you want to think of objects, than you better say which ones are different versions of others. But this hits exactly the point of having a family of sets of resources: namely, sets of resources of A_0 and A_1, and sets of resources for B_0 and B_1. And, thinking about it again, each of those events, one for each transaction, would have to come equipped with such a sub-permutation—unless you have some good examples where you want to essentially have arbitrary spiders to related identities before and after. In the end, it is really up to you what you want to consider essentially the same and how complicated an identity system you want.

Well, @Jamie , I hope you are not afraid of spiders :wink: – and free symmetric monoidal categories over those. Definitely worth a chat.

I think single message sequence diagrams are not expressive enough, because of matters of serializability / linearizability , but up to that nit: yes, we definitely should look into causal structures that are expressive enough to between atomic events on the resource level …

… which brings me ( / us (???)) back to the question of whether we want to add the possibility to have read-only checks for persistables as part of transactions (cc @vveiln)

2 Likes
5

Since the definition of a persistable is unclear, I find it difficult to argue about what we can do with them. I am worried that you might use this term to unite elements with different security properties, which might make some judgements inapplicable.

Moving resources between controllers is defined: moving a resource is to move its commitment from one controller’s commitment tree to another. What does it mean to move a persistable between controllers?

How is object’s identity defined? How is persistable’s identity defined?

This statement wouldn’t make sense for resources because for every resource there is at most one consumption event. What would make sense is to have at most one creation for an object or a “version of a resource with the same identity”, where identity is defined by the combination of (label, logic, value, quantity, ephemerality, nullifier key commitment). If a statement doesn’t make sense for resources, could it make sense for persistables? Another question related to the definition of persistables.

3 Likes