On the Will to Adapt: A Resource story

Protocol Design The Dominion
2

Thanks for the lovely write-up! This definitely helps me get a better intuition for the correspondence between resources and an object model that you have in mind, although I think many points remain to be clarified. Here are some clarification questions and ideas that come to mind for me:

(A) Correspondence between objects and resources

As I understand your proposal here:

  1. In a simple object system, at any point in time, there is a set of object instances. Each object instance belongs to a class, where some memory is shared between all objects of a given class (“class-side slots”), but each object instance also has its own memory (“instance-side slots”).
  2. In the resource machine, at any point in time, there is a set of unconsumed resources. Each unconsumed resource has a kind (derived from the label and logic), and also a value, where there may be many distinct resources of the same kind but different values.
  3. In your proposal, we map a class of objects to a kind of resources, and instance slots in objects to the value field in resources, such that each object instance (at this point in time) corresponds 1-1 to an unconsumed resource, where class slots are stored in (or referenced by) the label/logic (some details TBD here), and instance slots are stored in (or referenced by) the value.

Is that all accurate? This makes sense to me at a basic level, but I have a few questions:

  1. In an object model, do you expect to be able to modify class-side slots after you’ve created the class? That would be difficult to do in this representation (you’d need to consume all of the current object-resources and create new ones with a new label/logic). If this is desired, it could be done with a more complex correspondence, where “mutable class slots” would be represented by some designated resource kinds that would be referenced in the label.
  2. The resource model implies a certain separation of “object transitions” from “object invariants”. Namely, the resource logic (associated with a given class) constrains what updates are possible, but it does not itself specify how to compute them. Object “methods” as in the object model I assume would typically specify how to compute particular updates. It would be possible to simply write some methods and reference them in a resource label, but I also wonder if a more elegant solution would be possible here that allows for methods to be written even after one has defined a class (or something like that). What do you think?

(B) Distributed object system

A really nice aspect of implementing an object model on top of the resource machine is that with the controller system we should get a distributed object system (almost) for free. At least in my basic extrapolation, we could preserve the same REPL-like interaction loop, but the objects themselves would be owned by a particular controller (where maybe the default one is just the local chambers-controller) - but you could reference resources elsewhere easily, perform operations on them using the same syntax, etc. - and if all users are running Anoma nodes, the object operations they perform would be fully consistent thanks to the underlying RM and controllers system. Does that seem directionally correct to you?

3 Likes