In my attempts to optimize the architecture of the ARM to make it more suitable for protocol bootstrapping, I came across the concept of system of systems. I noticed a bunch of parallels between this framework and Anoma and it made me thinking.
ARM ecosystem as a system of systems
In this paper, a system of systems is defined..in a pretty straightforward way. There are constituent systems and there is a larger system that emerges from it, the system of systems.
In these definitions, each instantiation of ARM (or, more precisely, the domain that emerges around it), is a constituent system and the whole protocol (the big Anoma) is the system of systems. This analogy may be a bit reductionist since I only look at it from the ARM perspective, but I will continue doing so.
Back to the framework, both CSs and SoS have certain properties. CSs have operational independence - they can function without the rest of the SoS - and they have managerial independence - each CS has their own government. So far it checks out.
The properties of SoS include evolutionary development - as a system, the protocol evolves by adding new CSs into the system, removing the old ones, etc, and emergent behaviour - each individual CSs contributes to the SoS level behaviour of the system (intentionally or not). That also checks out. The emergent behaviour, I believe, in our case can be both intentional or not.
The paper defines four SoS types:
- directed: centralised management
- acknowledged: has SoS-level objectives and a designated manager
- collaborative: lacks a central authority; CSs cooperate voluntarily
- virtual: no central management, no purpose, no hope, no life, no future. It is rather sporadic
I would say that our protocol is collaborative in that framework.
To support these types, the paper defines four typical architecture types:
- centralized
- hierarchical
- heterarchical
- holonic
Out case is heterarchical (really hard to spell) - p2p interactions between the systems (here one p stands for one CS).
Constituent ARMs
That made me thinking..if we consider different domains (spawned by different ARM instances) as different CSs, then we can naturally assume multiple types of the ARM.
To give you an overview, when the first version of the ARM emerged, the assumption was that we will always have multiple instances that may differ in proving backends or cryptographic primitives but share more or less the same architecture.
Then, at some point, we were facing all the bootstrapping challenges that were partially due to the existing architecture, which triggered me to start this line of research - how to enable bootstrapping-friendly behaviour in the ARM without losing the freedom of expression we currently have (but can’t really use). The goal I had was to design an ARM that has a flexible architecture. It would be reducible to minimal functinality for bootstrapping or extendable for when expressivity is valued more over efficiency. While I’m not giving up on this idea, the SoS framework made me thinking, perhaps we don’t need a single ARM type to accommodate all of this but can instead develop a set of ARMs?
What would we need to do?
First, we need to define a set of ARMs to support. The minimal set includes:
- lean, bootstrapping-friendly ARM
- bulky, expressive ARM
The current version of the ARM we have is on the bulkier side, but it still would require certain modifications to be an appropriate member of the minimal set.
Now, is that set complete or not? There are two ways to address this:
- either we try to anticipate all potentially useful ARMs versions, or
- we develop another protocol (another protocol
) for extending the set and move on with the minimal set for now
Naturally, I would prefer the latter option as I am not confident about anticipating the future needs in such an uncertain environment.
Another thing we would need to figure out is a universal protocol (another protocol ) for these different ARMs to interoperate, inter-ARM communication protocol, so to speak. Given that we want the set of ARM designs to be dynamic, that protocol would have to be fairly abstract.
So, to summarize, we would need:
- design a lean bootstrapping-friendly flavour of ARM
- adjust the existing ARM to reflect the proper bulky ARM flavour
- develop the protocol for extending the ARM flavour set
- develop the communication protocol for different ARM flavours
That all IN ADDITION to everything else we have to design for the big Anoma to become real.
Conclusion
I don’t know how possible it is to design such a system in principle, but it certainly seems like a potentially interesting alternative to designing a toggle-based unified ARM-architecture. In some sense, the approaches are equivalent, the question is only if the protocols are external-only or both internal and external.
