Resource Machine report v3 scope refinement

[vveiln]

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:
  • Add ReadInterface and projection functions, adapt the rest of the application definition
  • Application composition types: how do they relate to each other? Can we define them in a more unified manner?
• 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

Backlog:

• The list of the topics not yet covered from the rm brainstorming topic
• The list of the topics not yet covered from the v2 scope
• Generalise nullifier public key to a commitment with specified properties (binding but not necessarily hiding, etc)
• Standardize and extract the general notation for everything defined in the report (definitions, interfaces, type theory, etc)
• Use commitments to public inputs instead of commitments, nullifiers, etc directly to fix the public input size for variable-size txs: public inputs in a Merkle tree
• Store private inputs (resource plaintexts) in a Merkle tree
• Query interface for transaction functions

Links:

• Applications and service commitments
• Collective curation of topics to go in resource machine report v2
• Stored data format: resource machine <> storage
• [Proposal] Scope refinement for resource machine report v2
• Application read & write interfaces

@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

[cwgoes]

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.

[vveiln]

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

[cwgoes]

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.

[cwgoes]

@vveiln

Extract “optional” transaction fields that aren’t required to verify the state transition but hint at smth (IFC predicate, preference function)

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.