Notes on system architecture

Protocol Design
1

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
2

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
3

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
4

At a high level - at the end of the system architecture section - we should be able to reason about the predictability of interactions with the system, in everything from sending messages to reading state, finding a counterparty, etc. - subject to assumptions about services being provided as promised (incl. BFT quorums and such).

We should also be able to reason about some kind of “preference convergence” where the topology of the network over time approximates some underlying set of preferences.

5

A thought I had today while re-reading https://github.com/anoma/nspec/pull/104 is that the clarified application interface - as discussed with @Michael @degregat and @vveiln today - should probably also be reflected (at some point) in the structure of the specs, e.g. we should have whatever bits of service provider awareness are necessary for the application in the “Application Architecture” section.

I also wonder if the “Protocol Architecture” section even needs to be aware of resources at all. Some controller bookkeeking should be performed automatically, so this needs to be included somewhere, but maybe there can be an abstraction in between - it would be nice if all of the ordering machine logic could reason only about key-value store interactions and abstract computation, for example.