Notes on system architecture

The objective of this topic is to investigate and collectively brainstorm what the “System Architecture” section of the Anoma specification should describe. Right now, I think that section is the least clear.

Prior source material for reference:

Fundamentally, I think the System Architecture section should be concerned with describing concepts and properties of the whole system, i.e. a partially connected graph of nodes, properties of the system evolution, i.e. how the state of the system can change over time, and properties of observations, i.e. what observations and combinations of observations should and should not be possible.

Specifically, I think the system architecture should aim to:

  • define key concepts: what is the system? what is a node? what is the state of the system? what is an observation?
  • mathematically define system-level properties, such as these (mostly liveness properties), and safety properties such as observers not observing different states for the same controller (subject to assumptions)

Miscellaneous notes

  • I think we can say that a node lives within / is run by an agent.

to be continued…

1 Like

Further thoughts:

  • A node is run within and by an agent. Specifically, we can say that the agent dedicates a certain amount of storage, compute, and bandwidth resources to the node (these can change over time), configures it with their preferences, and the node runs autonomously (for the most part) using those resources.
  • In general, we assume that the node runs the Anoma protocol as defined in the specification documents. Other nodes running other protocols (including nodes on agents who have modified the Anoma protocol) are out-of-scope, except insofar as we care about modeling arbitrary software run by potentially Byzantine parties.
  • Observations are made by agents. One kind of observations (name: TBD?) are made through the node, i.e. observations of state, and we want to reason about this kind for e.g. safety properties. The other kind are arbitrary observations by agents, and we want to reason about this kind for e.g. bounded disclosure properties (since malicious agents might not follow the protocol).
1 Like

Possibly cleaner overall organization (brainstorming):

  • Introduction
  • Scope
    • define agent
    • define compositional cybernetic agency
    • define semantics-independence, or similar - purely coordination syntax
    • generally, move heterogeneous trust / etc. statements to System Architecture, as they need concrete definitions
    • figure out how to bound the scope exactly - metaprotocol? at least add “making promises” and “trust” / “assumptions”
  • Basic Abstractions (hash function, virtual machine, encoding scheme, etc… - abstractions only, no concrete types)
  • Protocol Architecture
    • System Architecture
      • (generally structured as a hierarchy of graph overlays? or something like this)
      • Identity Architecture
        • Identity types… + diagrams
      • Network Architecture
        • tbd
      • Service Architecture
        • Filler for now about different types of services (compute, ordering, storage, network)
      • State Architecture
        • Resource + transaction types … + diagrams
    • Node Architecture (as currently - module + engine decomposition)
  • Application Architecture
  • Concrete Implementation
    • Concrete instantiations for all basic abstractions