Resource Machine Applications

Anoma Research Topics
1

This report will contain motivations and definitions of applications of the anoma protocol.

v1

In v1 of the report, we will focus on applications that function as “primitives” the system needs for its operation.

Kudos

Thread

Governance

Thread

For both of the above, we should focus on anything relevant to the implementation and try to at most sketch the mechanism design problems, to be researched in followup reports, if we can not cite pre-existing results.

v2

I propose to move multichat and public signal into v2 of this report (contrary to this thread) and start work on it as soon as all more potential engineering blocks have been resolved. This could be immediately after the release of v1.

Multichat

Thread

Public Signal

Thread

v3

I propose to also work out details of modular logistics, since it is a great example to show a more complex, user facing application that leverages intent matching and kudos.

Modular Logistics

Thread

3 Likes
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
3

I’ve added “resource initialization” as a pattern because this is not straightforward.

Let’s say we have a token T with a fixed supply of 100. The RM makes sure for each transaction that the number of consumed and created Ts balances to 0.
To initialize the supply of 100 T, we consume an ephemeral 100 T' resource, allowing us to create 100 T after encoding this special case in the resource logic function.
However, how can we make sure that this special case can happen exactly once and not be repeated? Am I missing something here @vveiln?

A simple solution could be to require a specific r.cm to be present in the transaction via Ts logic function. Since resource commitments are unique (because of nonce and rseed) this would guarantee that this can only happen once. I haven’t thought about the implications for the shielded case yet.

As this resource initialization has its caveats (also the use of ephemeral), I wonder if it could make sense to have an abstraction for this.

2 Likes
4

However, how can we make sure that this special case can happen exactly once and not be repeated?

One simple way to do that is to require a signature from e.g. a controller for the init case

A simple solution could be to require a specific r.cm to be present in the transaction via T s logic function

I think you cannot hardcode the commitment in the resource logic because you would have to know the commitment in advance and you can’t know it before you create the resource, for which you need the logic

I think Forall / negative checks in resource logics might be a helpful thread to read

1 Like
5

Yes, the commitment would need to be done in a previous transaction, which is less than ideal.

6

You don’t necessarily need a signature from the controller. Maybe we should have some kind of standard sentinel resource of which each controller has one that you can read / insert map entries into (in some referenced storage), and for this case simply check the non-existence of a map entry (the first time the 100 T’ is initialized), and write the map entry so that it cannot be initialized again.

2 Likes
7

Some more notes after a discussion with @cwgoes :

Report Goals

With v1 of the report one of the goals the examples should be in service of is to render the models as clear as possible.

@Michael has been making great progress so far on outlining the developer workflow, including identifying and specifying common patterns that will be used, which is a great basis for introducing and explaining the examples.

Some of the needed patterns are still not clearly defined, and e.g. in authorization there are some choices to be made, but for now it seems most useful to figure out solutions that are straightforward and useful for the concrete example applications.
We might figure out different types of authorization are going to be needed in the long term and its fine to iterate on the model we come up with now.

Also, the initial scope seems a bit ambitious, so maybe something like the following makes more sense:

v1

Kudos

For Kudos we want the following functionalities:

  • create
  • send
  • swap
  • calculate balances of identities, subject to available information given a users view of the network.

With these, we should be able cover initial use cases and we can refine if we notice anything is missing after a few examples.

Multichat:

Given the featureset @Michael described, we want to clarify how the application model deals with heterogenous trust and how that increases optionality.

For example, why and how is this qualitatively different from existing chat solutions?

PoS

@vveiln specified PoS already, which we can just include in v1

v2:

Governance

We should figure out a minimal useful example for e.g. voting which is sufficiently non-trivial to clarify the application model.

Voting could look like this, in a first order approximation:

  • propose and action and encode it as a resource
  • have specific identities vote on it within some specified timeframe

Public Signal

3 Likes
8

the initial scope seems a bit ambitious,

I would appreciate limiting and locking the scope a bit. I noticed that I am moving between too many topics currently.

Related to the kudos feature set, we should be specific. Does the following sound reasonable?

  • create: creates an amount a of Kudos A for another address (that can differ from the address of the creator).
  • send: sends an amount a to an address, where a can be the full or partial quantity of a resource.
  • swap: Sends an amount a of Kudos A to an address and requires another amount b of Kudos B to be sent from the receiver address.
  • Multiple create, send, and swap calls can be part of one transaction.

The latter is not straightforward w.r.t. resource logics and required signatures. However, I would like if we can get the functionalities in v1 to be atomic and composable.

calculate balances of identities, subject to available information

How can we do this currently?

1 Like
9

If you feel the scope should be tighter, that is probably the right call!

Your create, send and swap definitions sound reasonable.

For balance calculation, it depends on data retrieval, so its fine to postpone this until after retrieval is clarified, or use it as a guiding example to clarify the retrieval interface.

1 Like
10

@Michael The scope reduction and your proposal for kudos makes sense to me as well.

I think we should be able to cover this one - balance calculation just requires adding all the amounts of the kudos of a specific denomination owned by a specific identity.

1 Like