Hello, I am a part of the Anoma Builder’s Cohort!
I have been building Concordance; a ‘sever’ on Anoma’s distributed O.S.
I have used your specs, docs, and this forum to build my own conceptual model of this lower-level object system in Anoma, and figured my external perspective may be useful to the team.
Anoma operates similar to an existing pattern; the actor model. In terms of this thread, an actor appears synonymous to ‘objects’.
From chats in other threads:
Objects in Anoma are engines and resources (and potentially other things?). These objects have mailboxes that can send messages to each other. This is exactly what the actor model does. A good example is Mircosoft’s Orleans, a framework for distributed applications.
With Orleans, developers use an interface called Grains which have an identity + behavior + state. Grains can send messages to other grains during runtime.
In Anoma you have objects, and right now, provide developers with an interface for one of these objects; a resource, which has a similar structure to a grain:
Objects, in this case resources, can send messages to other objects. This structure aligns with Anoma’s atomicity requirements and application composibility.
Because a developer fully encapsulates the execution code as atomic resource logic, you gain some benefits:
- The resource logic becomes a clear and unified execution path for an object invoked at runtime.
- The origin resource called in the transaction becomes the source for higher-level incoming and outgoing messages.
- The transaction becomes the runtime handler (the entry point), for a clean runtime lifecycle. The lifecycle ends when the transaction is done executing. After execution, garbage collection, unlocking resources, etc is done.
The runtime compute itself is provided by the node executing the transaction.
Anoma as an ‘O.S.’ manages
- allocating memory and compute - locking resources and executing transactions
- reading from ‘main memory’ - scrying the Anoma blob storage
- Multi-threaded processes where processes create more than one thread - intents being broken down into partial transactions. Transactions and partial transactions acting on objects, which call other objects.
- Lifecycle of ‘processes’ and ‘threads’ - Lifecycle can send messages from a ‘process’ object, create new objects, relay to objects that may live on other clients/nodes, all objects eventually recursing back to the source object.
to name a few things.
Adopting the actor model will allow for atomic ‘multi-threaded’ processes; a clean separation of concerns for what a thread needs to execute (access memory, ‘update SSD’ - write state to a different controller), and the ability for the O.S. to ‘pause’ processes or threads, to allocate memory and execution to other threads, which is what I understand to be the basis for Chimera chains.
Another cool thing;
- because the resource logic is fully encapsulated within the resource
AND - because the node executing the transaction provides the runtime
AND - because mailboxes can intake messages and state
execution becomes ‘portable’. Meaning the origin node can pass a message and state to another node, which is all the context for another node to ‘take over’ the runtime.
So and Anoma apps are made up of its objects - resources and related resource logic.
I have not yet understood how Anoma will determine if the object it needs to pass messages to is another resource, or an engine, or something else. I assume developer can write resource logic that requires an engine, and that creates the engine. Related; will Anoma provide developers an interface for engines the same way it provides an interface for resources?
This comment:
highlights a higher-order execution environment, and speaks to a different type of object abstraction - which is the abstraction I have been building with Concordance.
There are many applications that run directly as executables on the O.S. to maximize performance, speed, and novel capability enablement. This is like running an application directly on Anoma using objects.
Severs, like apps, are executables that run on the O.S.
Concordance is a server, working at a higher order of abstraction to manage other parts of the application lifecycle and dispatch ‘kernel’ processes back to the OS, where the OS runs these processes, threads, and performs its native lifecycle.
Concordance does this by creating another layer of abstraction, what has been mentioned as a ‘conceptual object’ or ‘virtual object’.
This higher order of abstraction must do more than manage incoming messages, it must manage non-deterministic state, and interpolate non-deterministic actions to deterministic actions, which are then dispatched to the O.S. (Anoma). It must also manage its own lifecycle.
Anoma as an O.S. manages atomic object lifecycles where developers build native ‘desktop’ apps with better performance.
Concordance provides the Anoma ecosystem another way to build apps; in a server environment that manages bindings, ports, its own memory layer, queue, lifecycle, etc etc.