ART: Shielded Resource Machine

Anoma Research Topics
1

I was talking with @alberto about our shielded resource machine report, and we agreed on the value of discussing here the outline structure of the document we are envisioning.

Protocol Details

Using the ZCash specs as a blueprint, I suggest it would be best to have a abstract protocol which is back-end agnostic and contains descriptions of:

  • Cryptographic schemes: describe in detail the cryptographic schemes used across all protocol.
  • Key Components and Derivation
  • Nullifier Derivation
  • Compliance circuit
  • Resource Logic: I am not sure on how to expand this section. I would start by writing examples, for instance the ones present on the Taiga repo are worth writing down.
  • Balance and Binding Signature
  • Constants
  • Encodings

These section of the report could also come with Cairo code snippets. I am aware that the content above partially overlaps with the Resource Machine specs, however it is best for the sake of ease in writing to ignore such overlaps during the fist version of the document. We can discuss later about what should be kept and where. It could also be useful to split this section in two (one more abstract and one more concrete), however I do not think it is necessary for the time being.

Back-end Specifics

Afterwards, sections specific to each used back-end (Cairo, Risc0, Halo2):

  • Back-end specification:
    • Finite fields
    • Curves
    • Hash function parameters
  • Benchmarks

In practice I would write a rather vertical first draft concerning the cairo resource machine implementation, which would help visualizing the abstractions better.
A question we should address is: do we need to write different compliance circuits (in juvix) for different back-ends? I am aware that Alberto is writing a Rust implementation of the compliance circuit in Risc0, and I wonder if we could reuse the compliance circuit written in Juvix for Cairo,

@xuyang @vveiln @cwgoes @Lukasz

3 Likes
2

I am aware that Alberto is writing a Rust implementation of the compliance circuit in Risc0, and I wonder if we could reuse the compliance circuit written in Juvix for Cairo

In principle, I think yes, but not immediately. From what I’ve seen, the compliance circuit implementation uses operations specific to Cairo – Poseidon and Pedersen hashes and elliptic curve operations. Currently, we can’t compile Cairo-specific operations to RISC0. You would need to replace them with some RISC0 cryptographic builtins that are yet to be implemented in Juvix.

1 Like
3

Thanks for this!

I would also include in this report sections on:

  • Interfacing with Juvix (as a consumer of the zkVM)
  • Interfacing with Anoma (e.g. as a provider if we use their API)
  • Introduction and motivation on why Taiga, Cairo and Risc0 in the first place.
4

Exactly! We’re using accelerated primitives like sha256 and spec256k1 curve in RISC0 for building the compliance circuit. In my opinion, we currently need a quick benchmark to evaluate if RISC0 works for RM. It should only take a few days to implement it in Rust based on RISC0.
@camofu @alberto

1 Like
5

Yes, I think a reasonable way forward is that you benchmark it in Rust, and only when it’s deemed good enough I spend time implementing access to the accelerated primitives in Juvix. Then we can maybe abstract out a common Juvix implementation of the compliance circuit for Cairo and RISC0, with only the primitives differing.

2 Likes