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.
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.
- Issuance data structures:
- A builder embedded as part of
verify_issue_bundle()for consensus verification.
- Extensive unit tests for issuance.
- Extensive e2e tests for zsa transfer functionality.
- value commitment changes and tests.
- 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.
- 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
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
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.
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!
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!
The ZSA team
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!
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.
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:
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.
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.
Circuit changes are in progress, currently working on couple of potential ways of implementing the
split_note logic inside the circuit.
Work on the client (
zcashd) code is in progress. Currently working on adding support for asset identifiers and reading them from the orchard protocol.
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.
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:
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
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!
The ZSA team.
Good feature! While technically I assume the implementation of this feature is to simply reject the new notes and un-nullify the old ones I might suggest we rethink the name on this one. I assume one of the first things that come to mind with this feature is reducing ZSA spam. It’s definetly not good for that. Users might get the wrong idea and bork at having to pay fees to reject a spam . “Return to sender” or something might be more palatable?
While technically very different we will also likely want transactions that are rejected (e.g. not executed) by default. I discussed this a little in a seperate thread discussing “open recipient atomic swaps” (see below). While in the thread I’m talking about atomic swaps it should also applied to normal transactions too.
Here is the thread where I discussed some ideas on “open recipient atomic swaps”. It’s not perfect but might be a step in the right direction in terms of “combinatory” and “privacy” concerns (at least for one side).
Thanks for all your work.
When do you think we should expect for you guys to finally come up with a viable fee mechanism for ZSAs?
Funding all this development before ensuring that ZSAs will be economically viable, and not a burden on ZEC holders, does not seem like the smartest approach.
Similar to how you don’t build a bridge without having run the numbers to make sure the bridge won’t crash once in use.
To be honest, it is quite worrisome that you have not come up with a viable fee mechanism yet.