User defined asset extensions for Sapling

Technology
1

Hi everyone, Cryptium Labs has been doing R&D on a shielded pool for contract-defined tokens, based on this proposed ZIP and toy implementation. We are currently analyzing the changes needed to the Sapling circuits, and posting here as the project seems to have mutual interest (technical discussion/feedback, peer-review, etc)

To start off, it seems there are a few technical items to consider:

  1. Development of a group hash implementation in-circuit. It seems like the existing BLAKE2 implementation could be acceptable for this, and then a check that the value generator is a valid curve point (or at least not a small order point)

  2. It seems to me that if the value generator is included in the note commitment, then the group hash does not need to be (re-)computed in the Spend circuit, since the note commitment included a generator that was witnessed to be a PRF-image in the Output circuit.

Thanks all!

7 Likes
2

Just as an additional note: our working repository is here & the current set of circuit changes is in this pull request. We’re also working on updating the Sapling protocol spec to match the circuit changes.

3 Likes
3

To give some context for the state of my branch, the two approaches I’ve been experimenting with are:

  1. “typecast” the &[Boolean] image of the blake2 hash to AllocatedNum and then to an edwards point, doing various checks to ensure consistency (some commits exist in zcash_hackworks repo for this)
  2. witness an edwards point in addition to the blake2 preimage. use repr to compute &[Boolean] of the point and enforce equality to the image of the blake2 hash. Then use the witness point.

I think there are some tradeoffs to each approach and so I’m open to opinions

1 Like
4

Hey @joebebel and @cwgoes

Sorry this thread seems to have flown under the radar. Have you been successful with this approach?

There are funds available for this kind of work: Zcash Community Grants | The Zcash Community Grants program funds independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem.

CC @secparam

1 Like
5

Hiya! We’ve actually already finished the MASP and conducted a security audit - you can find more details on our MASP website.

All of this work is open source and it would be fantastic if Zcash were interested in integrating it somehow - I don’t think we (Cryptium/Metastate) have the experience or capacity at the moment to work on integrations with the C++ zcashd codebase, but we’d be happy to help an implementation team which was interested ensure that they’re using the library correctly, and if ECC or the ZF reviews our circuit alterations and has suggestions or requests we’d be more than happy to accommodate.

9 Likes
6

Why isn’t there more discussion here?

1 Like
8

If there is anyone interesting in working on this, see above for more information on how to apply for a grant!