Resource Machine Applications

Anoma Research Topics
2

After a brainstorming session with @cwgoes, we defined the scope for the Applications ART as follows:

The goal is to

  • provide a clear understanding of how applications practically work
  • define initial versions of applications and implementations

Accordingly, we want to first explain the general structure of applications

  • resource logics
  • resources (state)
  • transaction functions

aided by diagrams visualizing intent/tx flow (in particular for apps having state in multiple places).

In this context, we also want to explain how applications connect to other components in Anoma’s architectural topology

  • Storage of resource logics and resources in the data availability domain
    • persistent vs. temporary
    • incentivized
    • conditional (e.g., store data until the transaction has been executed)
  • Indexers (which could be another node role)
    • computes properties of application state, (e.g., the sum of unspent kudos resources = kudos balance)
    • ideally composable (e.g., to index the balances at block 105, I can use an already indexed balances from block 0-100, and just index the remaining 5 blocks)
  • Composition of applications
    • e.g., the intent of user A: “Increment a counter and send a Multichat message with the new value to user B” in one transaction
  • Interaction of UIs with applications

Before defining applications, we introduce common primitives/patterns

  • Resource Initialization
  • Counter
  • Account
  • Expressing ownership
  • Token (fungible + non-fungible)
  • Dynamic code loading

On the application side, we focus on

  • Kudos
  • Multichat with the following feature set:
    • Channel resource kind
      • Channel has publishers who can post messages
      • Channel has subscribers who want to read messages
    • A transaction to send a message simply
      • Increments the counter in the channel resource (consumes old
        channel, creates new channel)
      • Channel resource logic can check that a signature over the message
        from one of the publishers is included + valid
      • Stores a message which is a data blob encrypted to the subscribers
        associated with this counter
  • Proof-of-stake
  • Public Signal

In order to be able to provide concrete Juvix examples, Chris asked @mariari if we can fix the discrepancies between the Anoma node implementations and the ARM (that translated into the juvix-anoma-stdlib) soon.

3 Likes