ART: Scope, Goals, and Structure of the Anoma Protocol [braindump]

[cwgoes]

Reader beware: this is currently a braindump, and may not be clear at all. Here be dragons!

Prior context:

• Scope section of the Anoma specs
• This old HackMD
• This other old HackMD

The reader who has not already read the scope section of the specs linked above should do so first. The following should be understood as an addendum to the content therein.

Concepts which need to be developed & defined

• “What is a protocol?” - a protocol is a box (algorithm to be run on a non-deterministic Turing machine) inside an agent, “through which” the agent can send and receive messages, and which can automatically respond to messages “on behalf” of the agent (including complex responses, not just request-response).
• “What is an equilibrium protocol?” - an equilibrium protocol is a protocol such that, for a specific set of requirements, either:
  • there exists no protocol which better satisfies those requirements, up to implementation details (e.g. choice of cryptographic primitives), or
  • agents who start using this protocol for purposes within those requirements will never have a reason to switch to any other protocol / uses of this protocol will be incentive-compatible
  • (I am not sure which definition is correct here, we might need multiple ones for different purposes)
• Agent identity. In particular, agent identity is - from the physical perspective - fluid, as the “zone of control” definition is neither fixed nor verifiable. Zone of control is preserved through time through control of private information, which is what we use to reason about agent identity at higher levels (cryptographic identity), and we should spell this out in detail. I wonder if this report can get to a point where we can detail what “composition of agency” means in this context, which is related to this question (see also this SFI paper)
• Semantics of promises w.r.t. messages in/out on other protocols (e.g. one can understand “arm lifting up boulder” as a protocol, the semantics of which are opaque to Anoma the protocol but meaningful to the agents themselves vis-a-vis their access to this other protocol, I think). This is related to what is sometimes called “the oracle problem”.
• The difference between “direct” coordination of object-manipulation actions (representing objects as resources and using intents to agree on what to do with them) vs. “symbolic / delegated agency” coordination of object-manipulation actions (scale-free money, i.e. coordination on values-alignment and decision-making power).

Protocol requirements

The key set of requirements to lay out is: what is it that we think that the Anoma protocol must do? Several things come to mind:

• sharing observations (already mentioned in the specs) (here we need to define in more detail what sharing observations means and requires, e.g. perhaps partial-order linkage using one-way functions to collate “intersubjective time” information)
• sharing compute, storage, and network resources (already mentioned in the specs) (this is related to service commitments) (we need to clarify what “network resources” are)
• providing a virtual plane of agent-to-agent communication which adapts to a dynamic underlying physical network where the agents are moving about in the physical plane and their physical communication links/speeds/capacities etc. are always changing (this is the sort of “heterogeneous Perigee” area of requirements)
• providing a distributed intent machine, such that Anoma provides a distributed state with configurable rules as to how parts of that state can change (applications), and abstractions so that agents can agree on those changes using the interface of an intent machine (see: intent machine ART report)
  • I think this is a mechanism-by-which the direct & symbolic coordination may be implemented

I think it will also be helpful to investigate whether it makes sense to “layer” these requirements - e.g. if service commitments are understood as a sort of metaprotocol, subsequent protocols (distributed intent machine) depend on service commitments, but not vice-versa.

[cwgoes]

I think one contrast we can draw viz-a-viz the question of “equilibrium protocols” is of syntax/semantics - e.g. when particular symbols acquire semantic content, they become valuable to use strategically (to misrepresent), which then reduces the precision of the semantic content - so these are unstable in the sense that we care about.

[cwgoes]

I think initially it will be most helpful to focus the collective discussion on aligning on a set of requirements for the protocol, which we should be able to phrase in terms of interface requirements on the protocol “box”, i.e.:

In general, requirements describe what interfaces should be available to Alice and Bob when sending and receiving messages to and from their protocol boxes (treating the interior of the protocol box as opaque), and what properties those interfaces should have.

I think we will need to get a bit more specific about the physical network model. One way of modeling it would be something like:

• Agents have a (dynamic) set of physical network addresses (e.g. IP address, Bluetooth address), which are names that they can communicate to other agents, and may be (but are not required to be) global.
• Agents can send messages through the abstract network to names that they know. These messages may be arbitrarily delayed, re-ordered, and mis-delivered (but liveness properties will require some form of eventual correct delivery).
• Typically, latencies of transmission from one agent to another agent on a particular address will change slowly (i.e. the rate of change in latency will be low compared to the latency itself - we should make this a bit more formal). note from D: sometimes there are sudden 0/1 changes (links up/down)

I think that this is close, although not quite identical to, the graph model of P2P networks that @Jamie and @nzarin investigated a few months back - as I recall it, the main difference here would just be that nodes (agents) can have multiple edges between them (different physical transport links).

With requirements that talk about distributed state and distributed intent machines, I think we can craft an “omniscient observer model” very similar to the one used in @Jamie and @nzarin’s paper on Service Commitments.

I also realized while trying to decompose the requirements here that there should be a clear distinction between:

1. Requirements which talk about what the system is at this level of protocol boxes, agents, and messages
2. Requirements which talk about what the system should allow agents to do (e.g. coordination)

– and I think we should focus first exclusively on (1), and leave (2) for later work (which this model will be a necessary prerequisite for in any case).

[cwgoes]

An approach suggested by @jonathan in our last meeting was to clearly delineate the various levels of abstractions and assumptions in play here. I think a starting point here could be (in order from the basic agent model up):

1. Basic agent model (outlined in the links above)
   • Agents have physical addresses.
2. Abstract agent-to-agent network
   • For anything built on top of this abstraction, agents have cryptographic addresses.
   • Requirements here are precisely those requirements needed in order for the higher-level interface (send-to-cryptographic-identity) to work as desired.
3. Abstract agent-to-agent network w/service commitments
   • Requirements here are precisely those requirements needed in order for the higher-level interface (request, track service commitments) to work as desired.
4. Distributed intent machine
   • Requirements here are precisely those requirements needed in order for the higher-level interface (send intent to intent machine) to work as desired.

What do the distributed intent machine layer requirements look like exactly? Broadly, we want the ability to guarantee that, subject to certain assumptions, an observer (an agent) who treats a group of networked agents as a distributed intent machine will observe properties consistent with modeling that group as a simple (non-distributed) intent machine, within some tolerance.

Recall the definitions from the Intent Machines ART report:

I think we can split the properties we care about into a few groups:

• Correctness, namely, given input intents, will the future observed states be consistent with behaviour as an intent machine?
• Liveness, namely, given input intents, will the input intents be processed “as much as possible” (e.g. it may be necessary to make assumptions about the existence of other matching intents)?
• Alignment, namely, given input intents, to what degree will the preference functions of the input intents be respected (here we enter the questions of iterated games / MEV / slow game / etc.)?

Miscellaneous notes, not yet organized:

• At what level of granularity do we want to reason about state here? Do we want to be able to talk about resources? Do we want to be able to talk about the ability to build restrictions into state changes (resource logics)?
• At what level of granularity do we want to be able to reason about information flow control here?

[cwgoes]

One meta-procedural note: the kinds of requirements we’re talking about here are in a certain sense requirements for model accuracy: given a model of how another part of the network graph will behave, where the model is a lens through which messages are sent and received, and which has certain behavioural properties, under what assumptions can we guarantee that this model will actually be instantiated by the real agent graph (perhaps within certain tolerances)?

[cwgoes]

Notes from brainstorming:

• We can segment / split the agent-local state based on protocol layers, for example:
  • Network-level state includes metadata about physical connection <> external identity relationships, metadata about physical connection latencies & reliabilities.
  • Service commitment - level state includes historical data about which service commitments have been made, historical data about which messages have been sent and received, computed aggregates of performance, etc.
  • Distributed storage - level state includes metadata on which content-addressed blobs are where.
  • Pub/sub - level state includes metadata on which nodes have which preferences, efficient broadcast topologies.
  • Distributed indexing - level state includes metadata on which nodes have which intermediate states.
  • Distributed intent machine - level state includes RM state (commitments, nullifiers), in-flight intents & transactions.
  • Kudos - level state includes kudo balances, transfers, swaps, etc.
• With the lower-level protocols, we should get an optimality / convergence criterion that holds modulo appropriate incentives, which will typically be instantiated at higher levels (so this should be abstracted out somehow).
• Protocol layers should be separated such that - modulo incentive requirements - they form a interface dependency DAG (I think, not 100% on this).

[cwgoes]

The astute reader (such as @graphomath) may inquire as to what the difference is between these “segmented agent state components” and “engines”. I think the answer is - nothing! - except for here we are reasoning top-down, articulating desiderata based on the intended behaviour of many engines “of the same type” across nodes talking to one another, and that the appropriate separations of concerns here will often end up referring to groups of engines.

[cwgoes]

Notes from brainstorming 2024.10.07 (need to be collated + organized, likely will not be legible):

• Question: what is it, ultimately, that we aim to allow agents to do?
  • Possible avenue (rejected, but kept as a sub-goal): share and update a virtual, shared state space in an incentive-compatible way, synchronize the virtual shared state space to physical locations given (varying) access needs.
• Fundamental topic: composition of agency, where agency is understood as the ability to take inputs, model, plan, and act. Consider a hypothetical world where two agents can instantaneously communicate and share a locus of control - i.e. where they are in fact really one agent. The goal of a protocol should be to:
  • Allow potentially coordinating (composing) agents to discover each other, discover in which situations they really can “act as one”, and reason about incentive-compatibility of such.
  • Allow potentially coordinating (composing) agents to build a shared model, by sharing observational data.
  • Approximate this world as closely as possible, in the cases where agents wish to act as one.
  • At least for now, bracket out the question of semantics - we care only about what is necessary to allow agents to agree on shared state changes and make those changes visible / common knowledge as they wish. What those state changes “mean” in the world, measuring whether or not agents kept their promises of acting in the world in a particular relation to the state changes, making promises about how to act in the world in relation to state changes, etc. are all out-of-scope for now (but maybe we can bracket these out as “somehow measurable”, i.e. specify the interface).
• What is the difference between this approach and natural language?
  • In this computational commitment approach, we have an exact split between syntactical rulesets, agreements, and changes - which have no fixed, a priori relation to anything in the world at all - and semantical rulesets, agreements, and changes.
  • In the natural language approach, there are degrees of syntax vs semantics but there is no intrinsic, computational meaning of terms, and typically / in practice syntax and semantics are mixed (as is checking whether or not previous promises were consistent with observed behavior).
  • Something something computational capability.

[graphomath]

While I have not understood the following (draft of a?) definition for model, stating that

the model is a lens through which messages are sent and received,

completely yet, I am jumping to the point that I find most important: the definition of protocol.

To get started, I would like to pick up the slogan that we are “moving from an imperative to a declarative paradigm”. In particular, I wonder what is the quickest way to “de-algorithmize” the above definition,^[1] i.e., the following:

@cwgoes

a protocol is a box (algorithm to be run on a non-deterministic Turing machine) inside an agent, “through which” the agent can send and receive messages, and which can automatically respond to messages “on behalf” of the agent (including complex responses, not just request-response).

In short, the plan is to avoid the jargon “ɴᴅᴛᴍ” and decouple the definition from any of the various entities that one may want to call an “agent”.

So, for starters, let us put aside the question of whether a protocol (instance) has to run inside agents and defer the question of whether or not a first definition of protocol requires agents; I would think that all we need are primitive notions of receiving and sending of messages (w/o mention of who is sending or receiving) — very much in the spirit of the basics of service commitments (cc @Jamie @nzarin). But maybe not even that!

Candidate for an abstract protocol definition

Notation

• \wp powerset: \wp(A) ≔ \{ A' \mid A' \subseteq A\}
• \wp_f finite powerset: \wp_f(A) ≔ \{ A' \mid A' \subseteq A, A' \text{ is finite }\}
• A^B function space: A^B ≔ \{ f \mid f \colon B \to A\}

Also, suppose we have an arbitrary but fixed set of messages \mathbb M.

Def. Protocol

A protocol endpoint^[2] is a function e \colon \wp_f(\mathbb{M}) → \wp\bigl(\wp_f(\mathbb{M})\bigr) that takes a finite set of messages M —think received ones, for the sake of intuition— as input and outputs a set of finite sets of messages e(M) —think all possible options for message sets to be sent as correct reaction, out of which one set must be chosen. A protocol is a pair (E, r), consisting of a finite set of protocol endpoints E and a function r \colon M \to \wp_f \left( \left(\wp\bigl(\wp_f(\mathbb M)\bigr)\right)^{\wp_f(\mathbb M)}\right), which maps each message to a finite set of protocol endpoints-- (think of it as the receivers).

Exercise: describe protocol state as a pair of a set of messages in transit and sets of received messages at their endpoint (a map from endpoints to their received messages).

Best solution goes here!

Exercise: describe protocol evolution as a transition system whose set of states are all possible protocol states.

The idea is that one message at a time gets delivered. See the WiP ART report (please dm me for details.)

What about computable endpoints?

Once we have a definition of protocol in place, we sure want to have restrictions such that we can implement “sub-endpoints” of type \wp_f(\mathbb{M}) → \wp_f(\mathbb{M}), which is what Anoma’s engines do.^[3]

What’s next: properties – but wait!

So, now, if we think about properties of protocols, likely we want to have this is sync with the current research on service commitments. Next up is the question of how to “upgrade” the above candidate definition with time, but one step at a time …

TL;DR

I think, with little effort, we can find a way to polish our definition of protocol such that it is in line with Anoma’s philosophical underpinning, but independent of it and has clear links to published papers on the topic of protocol endpoints. In the end, engine instances should amount to implementations of protocol endpoints (cf. protocol instances in the above post).^[4]

References

• Secure Synthesis of Distributed Cryptographic Applications
• Hybrid Multiparty Session Types - Full Version

---

1. Mainly, I want to put aside any ontological commitments, for the time being, being agnostic so to speak. Also, I think, some of the above text may already hint at some aspects of what I am after: the “boxing things up” and the occurrence of protocol instances – as opposed to something else ↩︎

2. The terminology protocol endpoint is borrowed from two papers: the viaduct paper and Nobuko’s paper (see also ᴍᴘꜱᴛ)—without considering specifics of these papers. ↩︎

3. I think, we can even encode the spawning of new endpoints in that we send messages to endpoints that are not yet present. However, No semantics given! ↩︎

4. In fact, the above idea of protocol could end up being extremely useful for setting the stage before we turn to the arduous definitions in the engine ART report (@jonathan @AHart). ↩︎

[graphomath]

@cwgoes

Distributed indexing - level state includes metadata on which nodes have which intermediate states.

There is indeed a close resemblance between protocol instance^[1] and engine intance in the context of the above illustration:

The blue arrows in this picture could be used to illustrate the idea of local interactions of engines (and a comparison with interaction trees is overdue). The current version of engines in the spec does not have any non-trivial interactions with Alice and Bob, except for that Alice and Bob “run” these engines in their boxes and can stop and restart them.

On the topic of state: the main state of interest to engine instances is the set of received messages (as all initial state could be “hard coded” in the function)—and access to local time. Leaving out local time, a very abstract view on engine instances is as computable protocol endpoints. To be continued …

---

1. A protocol instance may consist of several “composed” engines though. ↩︎

[cwgoes]

Thanks for the feedback! I will take a look at the links. In general, I am in favor of divorcing the concepts and language here from any unnecessary philosophical commitments, and we certainly don’t need ontological ones - no claims are being made about the nature of being or existence - but we do want to be able to make claims about what kinds of protocols are possible and incentive-compatible given a certain understanding of parties running the protocols who have, always, the ability to do otherwise - so an “agent”-concept of some sort is inescapable, I think…

[cwgoes]

I think as a next step here it would make sense for me to attempt to organize the content thus far into a structured document, which might as well be in ART format, with holes for the parts we have yet to figure out - and then seek feedback on and contributions to that. That document should rigorously define, at minimum, the following concepts:

• Agent
  • and what it means to be “inside” or “outside” an agent (locus of control)
• World
• Network
• Input
• Output
• Time
• Agency
• Coordination (composition of agency)
• Protocol
• Predictability (and “trust”, at least for our purposes)

[cwgoes]

I’ve started a repository here, although it’s not useful for readers yet.

While trying to figure out how to articulate the desiderata of protocol components at a suitably high level of abstraction, I came up with an idea that might be useful, tentatively dubbed the “as-if invisible hand” model, which I want to note down here.

I think it’s easiest to illustrate by example. Consider the case of pub/sub. Abstractly, pub/sub is a giant message bus: anyone can publish a message, and subscribers wish to receive any message matching an arbitrary boolean predicate (filter) which they define. As time progresses, subscribers may change their filters. Broadly, the pub/sub system component is responsible for tracking who wants to receive which messages, such that they (the messages) may be routed over the network efficiently and reach their desired destinations.

Practically, the implementation of pub/sub must be distributed - i.e., consisting of a pub/sub system component within each node, which communicates with pub/sub system components in other nodes - but I think that we basically want this distributed system to approximate as best as possible (subject to network conditions, available resources, and incentives) an imaginary message bus maintained by an imaginary node with infinite storage/bandwidth/compute resources and zero-latency connections to all other nodes in the network.

Such an imaginary node could implement a trivial pub/sub algorithm:

1. Each time a new filter is received, store it, associated with the node who sent it.
2. Each time a new message is received (published), iterate through all stored filters, and forward the message to any node whose filter matches it.
   • (if that node does not acknowledge, store the message and retry later)
3. (repeat forever)

Furthermore, this pub/sub algorithm is ideal: all subscribers receive the messages they want to receive and they can even go offline, come back online later, and receive the queued messages (stored for that period by the imaginary node). Thus, I would argue, we want our actual pub/sub protocol to approximate as best as possible what this imaginary node would do, subject to:

• knowledge limitations, i.e. that nodes have partial information about each other’s preferences, in this case specifically the subscribers’ filter predicates (and partial information about which other nodes know which other nodes’ preferences, etc.)
• bandwidth limitations, i.e. that nodes have a (heterogeneous) limit of how much bandwidth they can dedicate to pub/sub
• compute limitations, i.e. that nodes have a (heterogeneous) limit of how much compute they can dedicate to checking filters
• storage limitations, i.e. that nodes have a (heterogeneous) limit of how much storage they can dedicate to storing messages which have not yet been acknowledged
• incentive limitations, i.e. that nodes have a (heterogeneous) limit of how much “work” they are willing to do for another node (and they must keep anti-DoS in mind)

Furthermore:

• All of these limitations (their specific values) are known only at runtime, and dynamically changing, so whatever distributed pub/sub algorithm we have should take them as continuous inputs and attempt to approximate the ideal “imaginary message bus” as best as possible.
• Given that we desire to approximate the imaginary message bus, there is a fundamental sense in which the state that the distributed w/sub protocol tracks must be in correspondence with the state that the imaginary message bus tracks, e.g.
  • Receivers’ filter predicates must be stored (here in a distributed fashion)
  • Messages which have not yet been acknowledged by their recipients must be stored (here in a distributed fashion)
  • Additional metadata must be stored such that the distributed state can be used in lieu of the imaginary message bus state, i.e. where receivers’ filter predicates are stored, if one is not storing them directly (ditto for enqueued messages).

Pictorially:

Additional notes

I also wonder if it might be possible to describe these sorts of “distributed approximations” as as kind of distributed obligation passing, where - say in the case of pub/sub:

• The publisher firsts creates an obligation by publishing, where the obligation states that this message should be sent to any receiver whose filter it matches.
• The publisher attempts to discharge this obligation as best as possible, by:
  • First sending the message to any receivers they know whose filter matches
  • Subsequently forwarding the obligation - less those receivers whose filter they have checked - to other nodes who might know additional interested receivers
• (repeat until all nodes who have heard about the obligation have attempted to fulfill it)

In effect, this obligation carries the intention to approximate the idealized model - and a great benefit of this frame is that it is automatically capable of dealing with heterogeneity - each node simply does what it can to help fulfill the obligation, tracks what it has done, and forwards the remaining complement. This kind of direct translation will not be immediately practical, but I think it may be a helpful analytical frame.

[cwgoes]

[this post is still WIP, posting to ensure the WIP content is saved on the cloud ™]

Post preface

Let’s try to extend this “as-if invisible hand” concept to more areas, at a high level. So far, we’ve covered pub/sub. In this post, I will try to sketch:

• network relay,
• service tracking,
• storage,
• indexing,
• and ordering.

Network relay

Imaginary algorithm

The imaginary relay node would implement the following algorithm:

1. Connect to all nodes on any physical connections they have available.
2. Periodically measure these connections for latency and bandwidth capacity.
3. When a relay request is received, relay the message to the connected node directly using the most suitable physical connection (given bandwidth/latency preferences and measurements).

Distributed state correspondence

State distributed around the network should correspond to:

• the state kept by this node (physical connections, latency, bandwidth)
• metadata about which other nodes have which connections (or, more generally, are likely to be able to reach which recipients), to be used in forwarding messages when a node does not itself have a connection to the desired message recipient

Similar to pub/sub, we should be able to phrase this distributed algorithm in terms of obligation-passing, where a node forwards the relay obligation (marking off routes it has already tried) until the recipient is reached.

Service tracking

Imaginary algorithm

The imaginary service tracking node would implement the following algorithm:

1. When a new service commitment is created, store it.
2. Measure all network activity.
3. When a service information query is received, return any matching service commitments and performance data (the query can filter by commitments and performance data). Performance data is calculated on the fly as necessary.

Distributed state correspondence

State distributed around the network should correspond to:

• the state kept by this node (observed network activity, known service commitments)
• metadata about which other nodes:
  • may have observed which network activity
  • may have computed and recorded which intermediate performance data
  • may be aware of which service commitments
    – which is, in general, to be used in order to fulfill requests to query service commitments and performance data as close as possible to how the imaginary service tracking node would have done, given that the state is distributed.

An analogous obligation-passing model can be constructed.

Distributed storage

Imaginary algorithm

The imaginary storage node would implement the following algorithm:

1. When a data blob is provided in a storage put request, store it, recording the specified expiry date in an index which is efficient to scan in order.
2. When a data blob is requested by a storage get request, look up the hash in the database, and return the blob (if present, else nothing).
3. Periodically scan through the expiry date index and delete any blobs which have expired.

Distributed state correspondence

State distributed around the network should correspond to:

• the state kept by this node (the actual data blobs)
• metadata about which other nodes are storing which data blobs and for how long, to be used in order to fulfill requests to query blobs as close as possible to how the imaginary storage node would have done, given that the state is distributed

An analogous obligation-passing model can be constructed.

In general, this question of metadata tracking - “which nodes know what” - is one where we may want to investigate more efficient organizational schemes, in particular those which reduce storage costs from linear (node X knows data with hash Y) to sublinear, which must necessarily organize the data in some further fashion, perhaps abstractly with predicates (node X knows all data which satisfies predicate P), and/or probabilistically (node X is likely to know data which satisfies predicate P). We should investigate this further.

Distributed indexing

We assume here that indexes can range over (project arbitrary computations over):

• Resources (current & historical)
• Transaction candidates & transactions
• Data referenced therein (stored in the distributed blob storage)

The imaginary indexing node would implement the following algorithm:

1. Subscribe to all processing results of all controllers, such that the indexing node can detect whenever a new block is produced.
2. When an index subscription request is received, store the projection function provided therein associated with the identity of the node who made the request.
3. When an index unsubscription request is received, delete the previously stored projection function and node identity.
4. When a new block is produced by any controller, iterate over the stored projection functions, recompute their results, calculate deltas vs previous results (which must be stored), and notify the subscribed nodes about the deltas (queueing and aggregating unacknowledged delta notifications).

Thereby, any subscribing node can maintain a synchronized local copy of an arbitrary projection of state, where they receive only delta changes (which are even aggregated while they’re offline).

Questions:

• Should pub/sub be used as a component here (updates for specific projection functions)?

[todo: state correspondence for distribution approximation]

Distributed ordering

This one is probably the trickiest to figure out how precisely to abstract in this matter - I’m not 100% sure about the following, but it’s my best guess at the moment.

There are a few levels of granularity in play here. First, the most basic: a single imaginary ordering node which orders all transactions.

The imaginary ordering node would implement the following algorithm:

1. Initialize a counter at 0.
2. When a transaction request is received, associate it with the current counter value, increment the counter by one, and produce an attestation that associates the transaction with the counter value.
3. Repeat forever.

Here, we assume that all resources are tracked by this imaginary ordering node, and a transaction can reference any resources it likes.

Now, let’s introduce the constraint of heterogeneous trust. To implement this under the constraint of heterogeneous trust, we:

• partition the resources, so that each resource is associated with exactly one controller, where users have trust constraints and preferences that refer to controllers
• limit each transaction to consuming resources referenced by a single controller (it can still create resources on any controller, we elide the details of state sync at this level of abstraction)

We still have an imaginary ordering node, but it now processes transactions subject to these restrictions. This imaginary ordering node can then be approximated by an actual distributed set of controllers.

[todo: state correspondence for distribution approximation]

Several points are elided in this high-level description that we might want to cover in some fashion:

Amortization

Ordering blocks (an ordered list of transactions) instead of ordering transactions directly is an amortization technique to increase throughput at the (slight) expense of latency, assuming that producing attestations carries a cost (as it does in distributed consensus). Modifying the model to fit this requires that the imaginary ordering node:

1. Accept transaction requests and note their order.
2. Periodically, produce a block containing the most recently received batch of transaction requests in the previously noted order.

(note: the batch of transactions received in a certain period could be ordered differently)

This amortization technique can be applied at any of these levels of abstraction.

Scheduling & load-balancing

In general, users will have resources and some preferences about which controllers they trust and what kind of rough distribution of their resources they wish to maintain across controllers. One could imagine an imaginary ordering node which takes a batch of transactions (referencing any resources) and figures out how to move resources between controllers (subject to trust constraints) in a way which would allow that batch of transactions to be processed. At some level, the actual system should act like this, but where individual users are making decisions about how to move their resources. I am unsure how helpful it is to model this dynamic here, but it might be worth exploring.

A final note: in order to maintain, or at least gradually converge to, their preferred resource-controller distribution, users should select which controllers they create resources on (and perhaps sometimes even split them, e.g. tokens). In the controller model, this is “free” modulo amortized state synchronization.

[cwgoes]

Notes from brainstorming 2024.11.04:

What is the goal of the protocol?

The goal of the Anoma protocol is to approximate the abstraction of a single logical virtual machine connected to all agents as best as possible in a way compatible with the preferences and resource constraints of the agents involved (which are themselves changing).

Note: This “single logical virtual machine” is more-or-less the same as the “imaginary node” in the above posts, but now understood as a single logical unit, not just a tool for subprotocol design.

Why might such a virtual machine be useful?

We can segment the motivations for use into:

1. Instrumentally-motivated use, where the virtual machine is used as a computational tool for the tracking and reconfiguration of promises, where the promises being tracked are understood as promises concerning what actions agents will take in the world. The correspondence of promises tracked by the virtual machine to promises (or, rather, adherence to those promises) in the real world is always dependent on a specific set of meta-promises which establish a “semantic binding” between promises tracked by the machine and promises in the world. For example, suppose a “Cacao Bank” issues cacao tokens (tracked by the virtual machine), where the bank promises that a cacao token tracked by the virtual machine can be redeemed for one unit of physical cacao, and one unit of physical cacao can be deposited in exchange for a cacao token. The cacao tokens can be said to represent cacao only in virtue of these bidirectional metapromises.
2. Non-instrumentally-motivated use, where the virtual machine is used for communication between agents, archival of data, and other purposes not directly aimed at achieving a particular configuration of promises in the world. A (single logical) virtual machine is much more useful for these purposes than a protocol which only abstracts a network (such as TCP/IP), because a virtual machine has memory, which can be used to provide tolerance for agents with intermittent connections, archive data of interest, etc.

What external interfaces are provided by this virtual machine?

1. Intent machine.
2. Sending + subscribing to data.
3. Storing data.

Note: if we extend the “state” ranged over by intents, interfaces (2) and (3) can be encapsulated - e.g. to send data is to express an intent that the data be received according to some criteria, and to store data is to express an intent that the data be stored according to some criteria. Intents in the basic range of (1) over resources express constraints+preferences under which the resource state can change. The state of this virtual machine (which can be ranged over) then consists of resource state, local storage, and message queues.

Note on naming: I am not sure about the best term to use here. “Virtual” is good, but “machine” is underdefined at the moment, and might conflict with other uses. “Virtual node” might work, but we aren’t trying to virtualize what other nodes do, we’re trying to provide a singular logical abstraction. “Virtual computer” is also an option. Still, for now, I like “virtual machine” the best, and we’ll just need to define the particulars and make sure it’s compatible with our other uses of “machine” (which I think it is for now).

[cwgoes]

Revised order of exposition for the ART report:

1. Introduction & Guide to the Paper
   • Aim of this paper
   • A very brief history of Anoma
   • A very brief history of blockchains, particularly Ethereum
   • Basic conceptual overview of what a distributed OS means
2. Conceptual Model
   • Agent, world, time, etc.
3. Desiderata & Fictitious Machine
   • Spatiotemporally non-local communication
     • Common point of reference for conditional commitments (promise tracking)
   • Fictitious machine
4. Protocol Model
   • What is a protocol
   • Correspondence theory
   • Equilibrium protocols
   • Instantiating subject to:
     • Heterogeneous trust
     • Information flow control [programmable disclosure]
5. Protocol Components
   • Subsystems (engines)
6. Analysis
   • Is Anoma an equilibrium protocol?
7. Future work

Considering this scope (of the ART), we might want to consider renaming this “Scope, Goals, and Structure of the Anoma Protocol”, as section 5 is really covering at least high-level internal structure. We could choose to omit that section from this ART, but I think it will be very useful for readers to connect the dots between these (rather high) levels of abstraction and the existing specification and implementation work, so I prefer to include it and broaden the paper scope slightly.

[cwgoes]

Note on desiderata exposition: the clever reader may inquire as to why one would bundle together “instrumental promise-tracking” and “non-instrumental spatiotemporally non-local communication” uses into one fictitious machine and protocol, and this should be addressed in the associated section. I don’t have a complete answer yet, but one note is that the semantics of use (instrumental vs. not) are not necessarily important from the perspective of the protocol, which is concerned purely with syntactical state transition rules. It might also be better to treat the instrumentally-motivated promise-tracking uses as simply a subset of the more general “spatiotemporarilly non-local mediated communication” use description.

[cwgoes]

I think the weakest part of the connective tissue here is agents → desiderata.

What do agents want to do?

1. Communicate with each other across space and time
   • Meet an agent, and later communicate with that agent
   • Meet an agent, and far away communicate with that agent
   • This may also be all agents, agents satisfying a particular criterion, etc.
2. Using this spatiotemporally nonlocal communication tool, create a common point of reference for conditional commitments (promise tracking)
3. Efficiently represent finite and fungible objects
4. Subject to dynamic information flow control (through time) - fictitious node enforces this

Anoma is a tool which can be used by the agents to do these things - what to actually do + what to want is up to the agents.

It would be helpful to diagram what this all looks like across time.

What is the difference between sending a message and storing a message?

• Nothing, only how long the sender wants the message to be retrievable for (and who should keep the copies)

Then later, instantiate the fictitious node as an actual distributed system, with the correctness of instantiation subject to dynamic heterogeneous trust assumptions.