Resource Machine report v3 scope refinement

I tried to collect all the topics we ever wanted to cover in the rm report to agree on the scope for v3.

  • The first list contains the things we already decided to cover in v3,
  • the second list is an aggregation of the things we wanted to cover at some point,
  • and the links are mostly just for me for when i’m writing the report

v3 list (finalised):

  • Applications:
  • Restructure the paper to have clearer separations between motivations, definitions, and the rest
  • Storage writes as defined here (Isn’t it already in the report? Verify)
  • Extract “optional” transaction fields that aren’t required to verify the state transition but hint at smth (IFC predicate, preference function)
  • Extract actions
    • actions to include the compliance proofs
    • proven/unproven actions
  • Generalised information revelation



@cwgoes in addition to the things already mentioned in the v3 list, what do we want to cover in v3? I didn’t add the things that were explicitly listed as “v3 topics” here because I think we should re-evaluate


Thanks for the clear writeup. I agree that we should re-evaluate new topics for v3. From my perspective the most important additional point from that original v3 topics list is just:

  • Generalized information revelation (proofs to third parties). As far as I can see, these proofs would take the form of (a) a proof that I know a particular resource with particular properties (some arbitrary predicate), and (sometimes) (b) a proof that that resource (or some resource) is not yet spent, i.e. that its nullifier has not yet been revealed. This latter is particularly important to investigate because it may impose requirements on the structure of the nullifier set (namely, the ability to efficiently make and verify proofs of non-inclusion).

Apart from that, I think we could focus v3 on the backlog that you listed, and on clarifying all of the types, notation, and structure. It might be wiser anyways to split out topics like EVM integration and (T)FHE into separate ART reports, unless they require some deep structural integration or change, but I think that they probably don’t.

1 Like

Could you give some examples in which cases such proofs would be important?

Yes; for example:

  • I want to prove to a third party that I have a sufficient balance to pay them, without actually paying them (kudos).
  • I want to prove to a third party that I own a particular NFT (say, a passport NFT) with specific properties (say, that my age is greater than 21), without revealing more than the specific properties.
1 Like

In terms of data structures (discussed with @vveiln):

  • Transaction should have only the data which is needed to actually execute/verify
  • We should create a new structure TransactionWithMetadata that includes:
    • A Transaction
    • The information flow control predicate
    • The preference function
    • (could include more metadata in the future)

In particular, this metadata needs to be sent around the network and tracked, but does not affect state changes. We should only put data in the Transaction structure which we need in order to verify state changes.

1 Like