[Grant Update] Zcash Shielded Assets Monthly Updates

Community Grants Community Grants Updates
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