# Abstract intent machine model **URL:** \ **Category:** Protocol Design\ **Created:** [August 18, 2023, 8:54am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204 "2023-08-18T08:54:19Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [August 18, 2023, 8:54am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/1 "2023-08-18T08:54:19Z")
### Introduction I think it would be very helpful to have a discrete mathematical model of intents that captures the essence which we want to capture without unnecessary implementation detail, but which is specific enough to clarify what we do and do not mean by the term “intent”. The best candidate I have thought of personally is that of an “intent machine”. In this post, I will walk through what an intent machine is, what definition of “intent” it provides, and (broadly) how this definition relates to Anoma’s protocol components. ### Definitions Fix a state type T (can be equivalently understood as a possibly infinite set of possible states). An _intent_ I\_T is a function of type T \to T \to { 0 | 1 }. An _intent machine_ IM\_T is a potentially non-deterministic function IM\_f of type (T, Set\ I) \to (T, Set\ I). Informally, the first tuple consists of the prior state and a set of intents which could possibly be processed, and the second tuple consists of the posterior state and a set of intents which was actually processed. Let’s name the arguments for clarity: IM\_f :: (prior :: T, available :: Set\ I) \to (posterior :: T, processed :: Set\ I) In order to qualify as an intent machine, the function must preserve the property that all intents actually processed were satisfied: \forall i \in processed . i\ prior\ posterior = 1 . Let’s call this property “intent adherence”. IM\_f is required to satisfy this property, but it is not required to be deterministic. ### Analysis Without loss of generality, IM\_f can be decomposed into two steps and one constraint. _Two steps_ 1. computing a set of (candidate state, processed intents) tuples which satisfy intent adherence 2. selecting one of the tuples to return _Constraint_ IM\_f may additionally constrain which state transitions are considered to be valid (potentially returned). This constraint can be modelled as a singular “system intent” which must always be satisfied, and it may itself change from one invocation of the machine to the next, so we shall model it as a distinct component of state: T := (I\_T, T'). IM\_f :: ((I\_{{system}\_{prior}}, prior'), Set\ I) \to ((I\_{{system}\_{posterior}}, posterior'), Set\ I) IM\_f then satisfies: I\_{{system}\_{prior}} \ prior\ posterior = 1. Let’s call this property _system intent adherence_. Note that I\_{{system}\_{posterior}} is not checked, but it will constrain future invocations of the intent machine. Let’s go through the two steps in detail: _1 - Enumeration_ The _enumeration_ step enumerates all possible valid return pairs of (T, Set\ I). \{(posterior, processed)\ |\ \forall i \in processed . i\ prior\ posterior = 1, processed \subset available, I\_{{system}\_{prior}}\ prior\ posterior = 1\} _2 - Selection_ The _selection_ step picks one pair from the set of valid options. choose :: Set\ (T, Set\ I) \to (T, Set\ I). ### Selection All of the interesting structure happens in the selection phase. To aid the intuition, here are some example choose functions: - “Pure chaos” - Select at random a valid return pair - “Pareto-efficient chaos” - Select the return pair which satisfies the most intents, break ties with randomness. - “Utility maximization” - Select the return pair which maximizes some scalar function U\_T :: T \to Nat. - “Profit maximization” - Utility maximization with U\_T as the balance of some specific token owned by the operator’s address in the posterior state. - “Expected utility maximization” - Select the return pair which maximizes U\_{{T}\_{expected}}, given some probability distribution over future intents conditional on the posterior state. ### Relation to Anoma A _resource machine_ is an intent machine with a system intent that interprets the state as a set of created/consumed resources, checks resource logic adherence, and enforces linearity. Taiga is a concrete instantiation of a resource machine (currently using Halo 2). Typhon, roughly, is a concrete instantiation of a distributed intent machine. This needs to be treated in combination with composition and will be covered in a follow-up post. ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [August 18, 2023, 9:19am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/2 "2023-08-18T09:19:24Z")
Areas to expand upon: _Analytic_ - Identity type and information flow control - Intents as atomic information flow constraints - Composition of intent machines - Distributed intent machines - Distribution of state - Distribution of computation - Distribution of enumeration - Distribution of selection _Operational_ - Resource machine system intent - Partial transaction encoding in resource machine - Intent composition ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [September 13, 2023, 12:39pm UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/3 "2023-09-13T12:39:36Z")
Revised basic model (after discussion with @isheff): Fix a (possibly infinite) state type T. Let an ordering Ord be Lt, Eq, or Gt. An _intent_ I\_T is a partial ordering over transitions over T, i.e. a function of type T \to T \to T \to Ord. An _intent machine_ IM\_T is a non-deterministic function of type (T, Set\ I) \to (T, Set\ I). Informally, the first tuple consists of the prior state and a set of intents which could possibly be processed, and the second tuple consists of the posterior state and a set of intents which were actually processed. Let’s name the arguments for clarity: IM\_T :: (prior :: T, available :: Set\ I) \to (posterior :: T, processed :: Set\ I) In order to qualify as an intent machine, the function must preserve the property that all intents actually processed were satisfied: \forall i \in processed . i\ prior\ posterior\ prior \neq Lt Informally, this means that the intent either prefers transitioning to the new state or is neutral. Let’s call this property _intent adherence_. (to be continued…) ---
**Author:** ![degregat](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/degregat/32/449_2.png) [@degregat](https://forum.anoma.net/u/degregat)\ **Post date:** [October 23, 2023, 12:39pm UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/4 "2023-10-23T12:39:46Z")
Some preliminary notes on the connection between > [@cwgoes](#): > > Composition of intent machines and > [@cwgoes](#): > > - Distribution of state ## Intents and State We always have the option to run consensus over (subsets of) intents, which means composing the (ordered) views of the intent space of all the agents participating in consensus. This generalizes to consensus over intents over intents …, but obviously comes with all the downsides of needing to run consensus. It is connected however, to the distribution of state itself, where composition of subspaces also happens by composing views via running consensus: Since intents will be formulated over resources, which have controllers who need to execute the transactions which result from the intents being matched, intents already carry information about which parties will be involved with execution. Here, the controllers will execute transactions according to internal decision metrics, fee structures, etc. s.t. they are coupled into the intent machine. > Question: Do I understand correctly, that intents can only be valid if they are over resources with compatible controllers, or do we want a mechanism to run hybrid consensus on demand? I’ll try to sketch this out in a hopefully non-synthetic, but very reduced, ### Example to illustrate worst case incentives: If we assume trust-aware distribution of solving, in the worst case controllers would just drop proposed `PTXs` by untrusted solvers. The edge case of this is the bootstrapping stage, where every controller does the solving for resources they control on their own and only cooperates with the respective solvers/controllers on `PTXs` which include resources controlled by others. Since there is no trust, all parties assume maximal likelihood of defection. As such, the assumed setting consists of: Maximally malicious parties, with maximal interests outside of solving rewards. I assume settings like these will always be present, even once there is more trust and non-controller solvers show up in the network. If we are able to come up with some reasonable incentive structure for this, I guess we can generalize towards something useful. ## Spectrum of composition It looks to me composition then can happen on a spectrum with the two endpoints: - Fully independent solvers come up with independent solutions and controllers pick amongst them according to their decision criteria. → Maximum competition and fully parallel - All solvers cooperate (making up one composed solver) to come up with exactly one proposal for each controller (or composed HPAXOS round between multiple controllers). This could include running consensus on intents or other mechanisms, but we cannot assume non-malicious behavior. → Maximum cooperation and fully sequential. In reality, different solvers will populate this spectrum at different points. The above considerations _should_ be independent of `enumeration` and `selection` which are roles within solvers. ---
**Author:** ![graphomath](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/graphomath/32/9_2.png) [@graphomath](https://forum.anoma.net/u/graphomath)\ **Post date:** [November 24, 2023, 8:31am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/5 "2023-11-24T08:31:58Z")
> [@degregat](#): > > run consensus over (subsets of) intents, Can you give an example of what it means to run consensus over intents? Consensus, by the book, is the agreement of a set of agents on a value that has been proposed by one of the agents. So which agents agree on what and who proposes these values directly or indirectly? ---
**Author:** ![apriori](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/apriori/32/1655_2.png) [@apriori](https://forum.anoma.net/u/apriori)\ **Post date:** [November 25, 2023, 3:09am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/6 "2023-11-25T03:09:35Z")
Agree on a view of intents before actually solving them. > Example. > > You could have a fairness criteria such that > > - intents for a given application can only be solved in a particular order; e.g., first-come first-serve. > - In this scenario a solver could receive user intents over a given time interval (say every 1 second) submit a batch of intents ordered how they are received to Typhon where n rounds of consensus are performed before the intents can be solved (matched). > - Thereafter, some intents from the batch would be solved and submitted as balanced transactions for ordering and execution. > > (Obviously, threshold decryption is better and possibly provides greater inclusion gaurantees and welfare - less incentive to spam in a latency race, still optimisitc spam with TD - for users than the FCFS example). ---
**Author:** ![degregat](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/degregat/32/449_2.png) [@degregat](https://forum.anoma.net/u/degregat)\ **Post date:** [November 27, 2023, 9:59am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/7 "2023-11-27T09:59:10Z")
If multiple solvers have batches of intents alerady which they want to solve for, they could decide to run consensus over the union of these batches and solve together. Then, at least during this round, certain kinds of defection, like front running are prevented. This gives no guarantees into rounds in the future, and I suspect that specific agents could strategically hold back messages (probably even dependent on some data they received in the ongoing consensus round). ---
**Author:** ![graphomath](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/graphomath/32/9_2.png) [@graphomath](https://forum.anoma.net/u/graphomath)\ **Post date:** [November 27, 2023, 11:19am UTC](https://forum.anoma.net/t/abstract-intent-machine-model/204/8 "2023-11-27T11:19:32Z")
intriguing, but, in place of writing down my thoughts on the game theoretic perspective, … …, for the consensus side of things, red-belly has “something” similar (called _Set Byzantine Consensus_), and then there’s a more technical paper below, making reference to some classics, proposing _set-union consensus_ ## Set Byzantine Consensus [Definition 1 (Set Byzantine Consensus)](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9519440) Assuming that each correct node proposes an enumerable set of transactions as a proposal, the Set Byzantine Consensus (SBC) problem is for each of them to decide on a set in such a way that the following properties are satisfied: 1. SBC-Termination: every correct node eventually decides a set of transactions; 2. SBC-Agreement: no two correct nodes decide different sets of transactions; 3. SBC-Validity: a decided set of transactions is a valid non- conflicting subset of the union of the proposed sets; 4. SBC-Nontriviality: if all nodes are correct and propose an identical valid non-conflicting set of transactions, then this subset is the decided set. ## Set Union Consenus [3.1 Definition](https://grothoff.org/christian/consensus2017.pdf) We now give a definition of set-union consensus that is motivated by practical applications to secure multiparty computation protocols such as electronic voting, which are discussed in more detail in the section “Application to SMC.” Consider a set of n peers P = {P1, . . . , Pn}. Fix some (possibly infinite) universe M of elements that can be rep- resented by a bit string. Each peer Pi has an initial set Si (0) ⊆ M. Let R : P (M) → P (M) be an idempotent function that canonicalizes subsets of M by replacing multiple con- flicting elements with the lexically smallest element in the conflict set and removes invalid elements. What is consid- ered conflicting or invalid is application-specific. During the execution of the set-union consensus protocol, after finite time, each peer Pi irrevocably commits to a set Si such that the following applies: 1. For any pair of correct peers Pi, Pj , it holds that Si = Sj. 2. If Pi is correct and e ∈ Si 0, then e ∈ Si. 3. The set Si is canonical, which is Si = R(Si). The canonicalization function allows us to set an upper bound on the number of elements that can simultaneously be in a set. For example in electronic voting, canonical- ization would remove malformed ballots and combine multiple different (encrypted) ballots submitted by the same voter into a single “invalid” ballot for that voter.