[Proposal] Anoma Research Topic Report: Controllers

Anoma Research Topics
1

The idea here is to produce an Anoma Research Topic Report specifying how we want Controllers to work, and why they should work that way.

2

Scope

Here I try to lay out the scope of this report: what it should cover, and what it should not cover.

Report should include / answer:

  • what is a controller?
    • does a controller differ from a (replicated) state machine?
    • does a controller differ from an (external signing) identity?
  • what makes a good controller?
  • what can controllers do (to resources)?
  • how do resources reference controllers?
    • this should include a notion of a resource graph
    • this should include some description of policy languages for creating / destroying / moving resources
  • what kind of resource “moves” (destroying a resource and creating a similar one with a different resource graph) should be possible?
    • what does each move require from its controller?
    • what does each move require from its resource?
    • this may include a notion of resource “shares” for asynchronously moving resources “up their resource graph.”
    • this may include an examination of whether it’s possible to “simplify” a resource graph while “using” the resource.

Report should not:

  • specify a precise policy language of resource controller permissions (just examine what kind of things are possible / impossible).
  • specify how to implement any particular kind of controller (we’re much more interested in the interface: what does a controller need to be able to do?)
  • rule out possible controllers just because they seem unlikely to be useful.
  • rely on any more specifics concerning resource structure / logics than absolutely necessary.
1 Like
3

Broadly aligned, a few specific comments:

  • I think we should include a scope section describing our design goals and constraints for the controllers system, perhaps a bit similar to the first part of the “controllers from first principles” topic, but further explicated and refined.
  • I think we should describe what logic the resource machine - or a particular resource logic, perhaps - must run in order to enforce the controller system correctly. I think your last section is similar to this - my request is specifically that we aim to get this all the way to pseudocode describing exactly what transition conditions must be checked.
  • I think it is worth including a section on how controllers are similar to and different from what IBC does, as this is a design many people will be familiar with, and has some similar constraints (and some constraints that we don’t have because we control the whole protocol stack).
1 Like
4

Additional note for conversation: this report should cover basic domain/time partitioning of the commitment tree and nullifier set, which is weakly synchronized across all domains.

As a note, this task is tracked here.