Great Progress and an excellent summary.
Are each of the ZSA team and ECC tracking Rust version compatibility to this project as their own risk entries? (or is this risk tracking isolated within the ZSA team’s work)
Can you share additional detail about the nature of the build problems that could manifest based on Rust 1.64 or later?
Hi @noamchom ,
The ECC is definitely tracking the compatibility of the Rust version for their own changes to their crates (orchard, librustzcash and so on). I don’t think the ZSA changes need the MSRV to be >1.61 at the moment, but we also want to keep track of how the issues resolve so that our code merges into the zcash repos as effortlessly as possible when the time comes.
As for the specific issues, there were a few messages on the Discord channel. To list the issues from there:
- librustzcash issue#800 talks about the build issue on Android that would occur post Rust 1.68 due to an upgrade in Android platform support.
- This comment also explains why there currently is a holdup moving to Rust MSRV >1.64.
Hope this helps!
Dear Zcash Community,
Right before we meet at Zcon4, we wanted to share with you the updates on our progress with the ZSA Project. Our main focus has been working on the implementation of the transfer circuit (milestone #6) and the client wallet (milestone #9), as well as getting to the final design on the ZIPs.
Implementation
We are happy to update that we have largely integrated the ZSA circuit into the Orchard code! We have also added a number of tests, both positive and negative, to confirm the implementation works as expected. We hope to update you with the completion of milestone #6 soon
On the client side, we have been working on adding and integrating RPC calls for wallet info, issuance and transfer of assets.
The overview of the updates is as follows:
- We have rebased our repositories on top of
Orchard 0.5
,zcash_primitives 0.12
,zcash_note_encryption 0.4
and a recent version ofhalo2
, something that is necessary to ensure that our additions are well in sync with the rest of the code. - The issuance key derivation has been updated to a new mechanism, similar to ZIP 32.
- We have added support for serialization of the burn mechanism data in
librustzcash
. - We have updated the Python test suite with further unit/integration tests.
- We have updated the way split notes are handled in the
orchard
crate. - In the
halo2
repository, we have added / exposed the necessary functions to support the new circuit functionality. - We now have a complete un-optimized circuit implementation for ZSA.
- The
zcashd
client has been updated to add support for issuance and wallet info RPC.
Our changes can be tracked at the orchard:#372 PR, and the zsa1
branches of the librustzcash, halo2, zcash-test-vectors, and zcash repositories. Please let us know if you have any comments, and stay tuned for more updates!
ZIPs
We have recently completed going through all the pending comments on the old pull requests for the ZSA ZIPs (namely, PR#628 and PR#649). We have moved to PR#680 for further comments at this stage of the discussion, and we are working on addressing comments there. Most of our recent changes have been towards increasing consistency with existing ZIPs and reducing ambiguities. Some of the changes are as follows:
- Updates to the
txid_digest
definition: Some changes were required to the Orchard component of the digest due to the increased size of the notes, and we have also added a section for the issuance digest. - Updates to the Action Description: Once again, the note changes necessitated updates to this data structure, which we have now detailed.
- The derivation of the nullifier for the Split Notes has been updated, based on the discussion with ECC here and here.
The updates to the transfer circuit have also now been included in the ZIPs, and we have also shared a draft document with all the details of these changes and how they fit into the context of the entire circuit. We will include this in the ZIPs as a PDF document once it is finalized.
We have also brought in additional eyes to go over our ZIPs from top to bottom and suggest improvements, so that our document has the highest quality.
Best,
The ZSA Team.
Dear Zcash Community,
It was great to meet and interact with the community at Zcon4! We had a lot of fruitful discussions, and we were also happy to present our progress with the ZSA and Asset Swap projects. The links to our talks at the event are linked below, please do let us know what you think!
We are very excited to update that we have integrated the ZSA circuit into the Orchard code, and are now submitting the implementation of the transfer circuit, corresponding to Milestone #6 of our grant! Simultaneously, we have been working on the zcashd
client, and have the RPC interface up and running.
Transfer Circuit Implementation
A summary of our changes are as follows:
Orchard
- We performed updates to the value commitment and note commitment equations, as well as added support for split notes as detailed in the spec. There were some iterations over the generation of the nullifier of the split note in order to achieve security.
- We added a few new witnesses to the circuit, namely the
asset
witness for the Asset Base, theis_native_asset
boolean for specifying privately whether we are dealing with ZEC or ZSAs, thesplit_flag
boolean for whether we are dealing with split notes or not, and thepsi_nf
witness for the random nullifier when we are working with split notes. - We added the
enable_zsa
boolean to allow for pausing of the ZSA functionality in case of any vulnerabilities (along the lines of theenableSpends
andenableOutputs
flags in Orchard).
The complete set of changes along with their context is documented here.
Link to code that corresponds to the circuit changes. This blob is included within the larger PR#372 that we have on the orchard repository.
Halo2
The changes here largely add functionality for use in the Orchard ZSA circuit.
- We added methods to perform Variable Base Signed Scalar Multiplication, since this support was needed in the value commitment calculation in the Orchard ZSA circuit (as opposed to the original fixed/variable base scalar multiplication that was sufficient for Orchard).
- We added functionality for performing the note commitment in constant time after the changes necessary for ZSA.
- We exposed functions for various requirements, such as to create curve points from constants, for the nullifier computation in the circuit;
Node Wallet State Implementation
We are also nearing completion for this milestone — we presented an early version of the RPC interface for the zcashd
client at Zcon4, in the ZSA Interaction Workshop! We will share more details about our work in this direction in a subsequent post, so stay tuned!
Next in line is our implementation of the updates to the Fees ZIP (see ZIPs PR#667 for the specification). We are also working on adapting our work for the zebra
client. As always, we look forward to hearing your comments on the relevant pull requests and the forum! We also encourage you to try out the demo as shown on stage in the ZSA Interaction Workshop at Zcon4, and let us know how you like it
Best,
The ZSA Team.
can you add a timeline? where are you on timeline for completion?
We are on track for ZSAs to be included in the next network upgrade (viz. NU6)!
Is there an NU6 delivery timeline?
Is it correspondent to the Halving?
It seems JXG (and myself) are wondering about approximate calendar estimates
Is going to happen with the POS transition
really looking for a date.
Very good!
Just to give an update on this, zcashd is currently on clang 15 and Rust 1.69.0. librustzcash is on MSRV 1.65.0. So that’s no longer a blocker.
I can’t make any strong predictions, but the progress on ZSAs is significantly ahead of that on PoS for Zcash, and neither NU6 nor ZSAs are blocked by PoS.