[Grant Update] Zcash Shielded Assets Monthly Updates

Community Grants Community Grants Updates
5

I’m in. Max issuance divided evenly amongst valid addresses memo’d to me :astronaut::rocket:… :full_moon_with_face:.

6

I think there should be some kind of sybil resistance to this mechanism. I propose a shielded memo with a proof of forum account :stuck_out_tongue:

3 Likes
8

Very exciting!

9

Is NFT issuance possible with ZSA? Is that out-of-scope?

10

@dontbeevil That’s a good question. As far as I understand it each token is fungible. Asset types are not.

@LeCryptoMath how many bytes will the asset type ID be? I imagine rather then needing NFTs to represent art/collectibles we could issue a seperate new ZSA type for each seperate piece of art/collectible.

2 Likes
11

Dear Zcash community,

We are super excited to share with you the first DRAFT versions of the two ZIPs that cover the ZSA protocol, which @naure @PabloK @shahafn @vivek and myself worked on for the past months with the help of @daira @str4d and @tromer:

These ZIPs have been in the works for the past two months and we have interacted with the community, the ECC and the ZF developers to ensure the compatibility, usability, privacy & security and elegancy of the protocol.

You can find here the three different calls that we had discussing these ZIPs

A short description

Issuance

As our MVP, the issuance mechanism is transparent, and enables several interesting applications of issuance on Zcash. We have designed a protocol that enables batch issuance for finite or infinite supply of assets. It allows for NFT-style issuance, and is off-chain extensible to allow for bridges to be built. In terms of security, we provide the ability for the chain to track the total supply of any token, as well as for individuals to revoke the issuance of an asset id in case of compromise.

Transfer

In terms of the transfer mechanism, we have designed a circuit that ensures that old-style ZEC Orchard notes can be used as-is within the ZSA protocol, making the transactions totally indistinguishable from the Orchard transactions. This means that we have backward-compatibility and in terms of upgrade, we will not have to create a turnstile.

The transfer has been reviewed to be secure, albeit lacking of an actual security proof, which we hope to at least sketch.

Burn

In order to properly support an end-to-end ZSA protocol, we designed a very elegant burning mechanism. We will use the inherited format of the shielding/unshielding of ZEC in the Orchard protocol (that uses the transparent ValueBalance) in order to confirm that some amount of a given asset has been burnt and is unspendable. We define purely the protocol for burning, but we do not provide a specific implementation of how a bridge should be built, as there could be several ways to accomplish the bridge (the main question is how to transfer data to the bridge operator).

Discussion points

Comments

These ZIPs are in DRAFT mode and will definitely see some changes in the months to come, both as we receive feedback from the community and core developers, as well as changes that arise in the implementation process. We have started working on a prototype of these designs in order to have initial tests.

We welcome any comments and questions!

We will be hosting a live twitter spaces in a couple of weeks to discuss this, stay on the look out for more info!

22 Likes
12

Hi @LeCryptoMath,

The links are not working and I couldn’t find them on the /zips repository - can you help me fix it?

4 Likes
13

Hi!
I’m sharing the links here:

7 Likes
14

Thanks for the links! Are the ZIP drafts now in a state where they could actually be presented as draft PRs to the GitHub - zcash/zips: Zcash Improvement Proposals repository?

5 Likes
15

(Speaking as a ZIP Editor.)

Ditto! These look great!

They appear to be. I would strongly encourage filing them as a PR, so that GitHub’s comment/suggestion/review features can be used and so that changes can be tracked.

9 Likes
16

this is a great point! We will make sure to do this in the next few days.

4 Likes
17

Yes please, this would be great to track questions/reviews/suggestions/what has been discussed and what not

2 Likes
18

Dear all, after some time, please find our monthly update (sorry that we skipped one, between time off and initial development, there was not a lot to update on).

The last two months we have done important progress, ironing out many details of the design of the protocol and the circuit. Specifically,

  1. We have created a pull request with the draft versions of

  2. We have been advancing at a good pace with the implementation of the protocol

    • The transfer protocol changes are pretty advanced - see repo
    • The client implementation (RPC) for the ZSA functionality is also advancing well - see repo’s main branch
    • We are also getting started with the issuance implementation, having already implemented the issuance key structure - see this pull request

  3. We are advancing with the ZIP for the fee mechanism, though we do not feel like we are ready to share the draft. More on this soon!

  4. We are getting ready to present our work and progress at Zcon3!! We will have one session with concrete design overview, updates and (hopefully) a demo. And we will also host an interactive discussion on the future applications and protocol design for the Zcash blockchain (i.e.: towards real programmability). Do not miss it out.

We are hear to answer any questions!
Thank you all,
The QEDIT team.

17 Likes
19

Thankyou, this is awesome! We made a start on editing in the ZIP sync meeting on Wednesday. Looking forward to seeing the QEDIT team at Zcon!

7 Likes
20

Dear Zcash Community,

We are very excited to share with you that we are advancing well with the implementations of the Transfer, Issuance and Burn mechanisms. This update is divided in two parts: first, a detailed update on the project progress; second a request to change the project milestone structure.

Updates

Last month we had very productive conversations at Zcon3, including a talk we gave on the details of the ZSA project, a workshop we facilitated on the future of Zcash applications, and a panel discussion I participated on the future of Zcash. We welcome any feedback and questions on any of these.

In terms of the final ZIP, the Fees Mechanism ZIP

Regarding the implementations,

  • The transfer mechanism is mostly done (yay!), and we are writing tests, many tests. We are also currently working on the circuit updates, which ended up making the circuit a bit larger than expected, so we are also looking at how to optimize the floor plan of the circuit (see Str4d’s talk at Zcon3). The main overheads were that in order to compute the note commitment of typed assets, we needed to add an extra round of the sinsemilla hash window, and also the fact that we ended up having more branching in the circuit, due to the different cases that need to be handled (mainly the differences between ZEC and non-ZEC notes, real and split / dummy notes). Good news is that we have some ideas for how to optimize the circuit.
  • In terms of the issuance protocol, we are also done in the Orchard repo (woop!), and we are also writing many tests. There is work to be done at the client layer (especially given the complexity of the Zcashd client), in order to ensure that the issuers can easily program their concrete issuance application (NFTs, Multi-issuance, delayed, etc…). Given that the issuance is new to the core protocol, there are some consensus changes to implement.
  • We are working on the burn mechanism, for which we have decided to not implement any specific burning method, and instead leave it up to the bridge operators to decide how to transmit the necessary information between the user of the token and the bridge operator.

Milestones Refining

As we approach the end of the implementation milestones, we are preparing for the next part of the project, the review and deployment, and we would like to refine and reorganize some of the milestones in a formal way. This will allow QEDIT to define our timeline in a more concrete manner, especially as we look towards future projects. Currently, there is a single project and grant for everything from design, implementation, code review, testnet deployment to mainnet deployment.

Screen Shot 2022-09-20 at 14.32.17
Screen Shot 2022-09-20 at 14.32.17716×509 22.8 KB

Practically, we have worked on these milestones in a different order, so we would like to propose that we divide the project (all ZSA milestones, as defined here) into two different phases:

  1. For the first phase of the project, we include all the design and implementation milestones (number 1, 2, 3, 4, 5, 6, 7 and 8). Furthermore, we would like to divide milestone 3 (Transfer Functionality Implementation) into two different milestones, with two different PRs to the Orchard repository, making it a cleaner deliverable:
    1. Milestone 3a. Transfer Protocol Implementation: will include every aspect of the implementation pertaining to the actual protocol, and would comprise 60% of the budget allocated to milestone 3. The deliverable for this milestone is a PR to the main zcash/orchard repo.
    2. Milestone 3b. Transfer Proof Circuit Implementation: will include every aspect of the circuit writing, as this entails optimization work, and would comprise 40% of the budget allocated to milestone 3. The deliverable for this milestone is a PR to the main zcash/orchard repo.
  2. The second part of the project, preparing for deployment, we include the review, testnet and mainnet deployment milestones, which have a less specific delivery time and require on-going work. This would include milestones number 9 and 10 (as seen in the image above), expanding on the last milestone to include fixing any vulnerabilities or bugs found in any of the processes.

In terms of the budget, we would maintain the same budget as per the original project, but dividing the payment into two different sets, as per budget outlined in the original proposal.

We truly believe that this division should be adopted by all teams applying for grants to implement on the core layer of the Zcash ecosystem.

16 Likes
21

Thank you for providing the update on the implementation milestones and the adjusted timelines for the deliverables. And thanks for communicating the breakdown of Milestone 3 into two different milestones.

Please connect with @decentralistdan for help with updating the milestone setup on the zcashgrants.org platform.

9 Likes
22

awesome!!!

1 Like
23

Milestone #6 Submission

Dear Zcashers,

We are super excited to share that we have just pushed our first PR of the implementation of the ZSA protocol. This update includes most of the ZSA protocol (see the specifics below, as posted in the PR), which includes the issuance mechanism and the transfer mechanism. It does exclude the burn mechanism and the final version of the circuit for the transfer proof.

Hence with this update, we are submitting the implementation of the issuance, corresponding to milestone #6.

You can run an end-to-end test that will generate new custom assets and will transfer them (even if the proof is not fully correct or sound yet). Give it a try and let us know how it goes!

Please leave any comments on the PR so we can track everything.

In the coming weeks we will update this PR with another commit that will include the burn mechanism, and then follow with a finished circuit.

PR Text

Issuance in accordance with milestone #6 of the ZSA proposal and grant.

This PR should be reviewed as an implementation for milestone #6 of the ZSA milestone table. It should not be merged until the rest of the ZSA functionality is ready.

What’s included:

  • Issuance data structures: IssueBundle and IssueAction.
  • A builder embedded as part of IssueBundle.
  • verify_issue_bundle() for consensus verification.
  • Extensive unit tests for issuance.
  • Extensive e2e tests for zsa transfer functionality. tests/zsa.rs

Also included:

  • note_type derivation.
  • value commitment changes and tests.
  • note_type inside of note.
  • builder changes for zsa.Included but not activated:
  • Split note mechanism. It will be activated once the circuit is ready. This is done in order to preserve transfer functionality while the circuit is not ready.

Not included:

  • The burning mechanism for transfer. (in progress, part of milestone 3)
  • Circuit changes to support note_type, split notes, and all other new functionality. (in progress, part of milestone 3)
  • changes to note encryption to support note_type. Will require some changes to the zcash_note_encryption crate. (in-progress)
12 Likes
24

Dear Zcash Community,

We are excited to share that we have accomplished another formal milestone and another two important (non-formal) milestones!

See the latest PR with these updates - ZSA Protocol ZIPs - Tranfer&Burn, Issuance and Fees mechanism by daniben31 · Pull Request #649 · zcash/zips · GitHub

  1. We have just submitted the Fees ZIP, for now named ZIP-0317b, which is an extension of the Proportional Fee mechanism in ZIP-0317. This ZIP is supposed to be merged with its parent ZIP, once it has been reviewed and the proposed changes have been accepted.

  2. We have finished a major re-writing of the Issuance ZIP, ZIP-0227, since we felt that it was not in sync with the code we have written and the reviews we fixed there see here. The ZIP specification is now a close to one-to-one spec of the code - feedback is welcome!

  3. We have also adapted the Transfer ZIP to the changes in the Issuance ZIP, so we obtain an integrated pair of ZIPs that describe the design and spec of the ZSA protocol.

This means that once the code is final, there will be a period of reviewing both the ZIPs and the code hand in hand to make sure that everything is ready for testnet (and then mainnet)!
Of course, there is still some way ahead, as the core teams and the community need to get together and decide on what features and imoplemntations will be included in the next Network Upgrade (#6!)

In terms of the implementation, we will have a concrete milestone update for you in the coming weeks, as we get close to finish the implementation of the burning mechanism, which will give the full ZSA protocol (without the circuit, yet!).

Looking forward to hearing from all of you soon!
Best,
The ZSA team

19 Likes
25

Dear Zcash Community,

Best wishes for the new year to you all! We have been working hard on advancing the milestones, and we are excited to share our updates with you.

We have mostly been working on the transfer functionality implementation (milestone #3), and getting feedback on the ZIPs - we encourage heading over to the pull requests we link below and letting us know what you think!

ZSA Transfer Functionality Implementation

Burn mechanism

We have completed the implementation of the Burn mechanism for ZSAs and it can be found in the pull request QED-it/orchard#35. Note that this PR also includes E2E tests for the burning of Assets.

Note encryption

We have been working on updating the encryption of notes for ZSA notes — the presence of an additional AssetId field in the note means that new notes will be 32 bytes longer than current Orchard protocol notes. To encrypt these new notes while maintaining backward compatibility for decryption of the current notes, we have made updates in two parts:

zcash_note_encryption changes

We have generalized the zcash_note_encryption package in the librustzcash crate to allow for the encryption of note plaintexts of different lengths.

The draft PR for this change is available for review at zcash/librustzcash#746.

orchard crate changes

The changes that have been made to the librustzcash crate need to be propagated in the orchard crate to allow it to support new (V3) note encryption as well as current (V2) encryption.

This is still in progress, along with tests, for V2 and V3 encryption. We should be able to submit a PR to the orchard repo very soon, but the current state can be looked at in QED-it/orchard#38.

Orchard circuit

Circuit changes are in progress, currently working on couple of potential ways of implementing the split_flag and split_note logic inside the circuit.

Zcashd

Work on the client (zcashd) code is in progress. Currently working on adding support for asset identifiers and reading them from the orchard protocol.

ZIP changes and review

We have rearranged the ZIPs so that ZIP 226 and ZIP 227 are in one pull request, viz. zcash/zips#649, and we have another pull request for the Fees ZIP, viz. QED-it/zips#2.

We have addressed almost all comments from the old PR (aka zcash/zips#628), and we have a few points to iron out while ensuring the implementation matches the changes.

Similarly, we have begun addressing the comments in the initial review of PR#649, but that is still a work in progress.

We are also working on addressing the comments in the Fees ZIP that were present in PR#649, after which we will proceed to merge it with the existing draft of ZIP 317.

Preview of next ZSA features on the radar

With the start of a brand new year, it also seems a good time to think about what a future with Zcash Shielded Assets would look like. We’ve been gathering initial feedback on these features, and would be happy to hear more from the community:

Transaction Reject

This would introduce the ability to reject incoming Zcash Shielded Assets that you didn’t expect or don’t want.

Some considerations are:

  • Rationale and use-cases, such as refusing a payment that was sent by mistake, refusing assets from unknown origin, politely decline a friend picking up the tab
  • What is the on-chain status of assets that could be rejected, have been rejected, have been accepted etc.
  • A discussion on fees

Asset Swaps

We should support the ability to simultaneously send and receive assets in the same transaction, so that either both transfers happened or none happened. This allows for trustless settlement of asset exchanges, and sets the stage for Decentralized Exchange capabilities.

Here we will consider:

  • This feature could work for ZSA <> ZSA but also for ZSA <> ZEC.
  • The fees structure could be an extension of the ZSA fees.
  • Can we also have open-ended swaps, and allowing for combining these one-sided transactions together.
  • What are privacy considerations of such a capability.

Looking forward to hearing from all of you soon!

Best,

The ZSA team.

21 Likes