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.