Anoma Resource Machine Explainer in Long Form

[cwgoes]

Thank you for this lovely explainer! I really like the general style of building up step by step from very simple abstractions, adding just one component of complexity at a time.

A few notes and questions:

@graphomath

At this point, we come to a highly non-trivial design decision: each persistable comes equipped with its own logic, which imposes transition conditions for every transition that “touches” it. The precursors[7] to these logics were already described in Anoma’s first white paper.

I think it is worth some exposition as to why this is done. The most basic reason I can think of at the moment is that we are interested in state and state sequences which can be interacted with by anyone (anyone can submit a transaction), and therefore the only way for users to be able to reason about how particular parts of state (persistables) can change is if conditions are attached to persistables themselves. Does that make sense?

@graphomath

It could be just

• a SoC and
• a finite set of SoCs

because persistables are carrying their logic, which imposes transaction constraints.

I didn’t follow this step, why do we need both a SoC and a finite set of SoCs, instead of just a finite set of SoCs?

@graphomath

In one phrase, a transition x \to y is allowed if its SoC can be partitioned into pairs of disjoint sets of persistables such that the logic of any involved persistable is satisfied for the partition in which it is contained. One important consequence of this definition is that we are able to batch together several consecutive but independent allowed state transitions into a single “parallel” transition such that the logics of the persistables are satisfied for the relevant portion of the SoC.

I think we can further note that in deciding upon this structure of transitions, we have two goals:

1. Allow persistables to impose arbitrary requirements on what other persistables must be consumed and/or created atomically with themselves (and indeed, since there is no state other than persistables, there is nothing else they could conceivably impose requirements on), and
2. Allow valid transitions to be composed.

I believe that these two requirements should be sufficient to necessitate this structure.

@graphomath

• Balancing concerns the whole of the transaction description (and thus is not local to any of the scopes).

This is the essential point, and I wonder whether we can establish an even more basic mechanism for cross-scope checks, of which balance is then perhaps “just” an optimized, shielded-compatible implementation.

For example, we could say that persistable logic can check:

1. Persistables consumed and created in its logic scope (as you have already), and
2. Persistables consumed and created elsewhere (but we don’t know or care where).

Why is this interesting? If I want to enforce that another persistable is created or consumed along with myself, why not simply check whether it is in the logic scope? The key difference is that the logic scope checks are exclusive: checking a persistable in my logic scope ensures not only does that it satisfies my requirements but also that it does not satisfy other persistables’ requirements other than the ones which I allow to be included in the logic scope. This means, furthermore, that (without balance), different sets of persistables within an SoC can also be split into different transactions which would be independently valid. Checking cross-logic-scope persistables, on the other hand, is a way to intentionally forgo this exclusivity, and to ensure that a persistable exists somewhere which satisfies my requirements while also allowing it to satisfy other persistables requirements of which I need have no knowledge.

See also this discussion, which is relevant. I am not yet sure exactly how to formalize all of these aspects and design constraints but hopefully this minor exposition is something to work with.

@graphomath

Finally, we come to application data. Roughly, application data is any data that

1. logics can also take as part of their inputs and
2. is provided as part of the transaction description.

I wonder if we should include application “datums” as “pieces” as well, in this model.