User defined asset extensions for Sapling

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!

5 Likes

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.

2 Likes

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