[Grant Update] Zcash Shielded Assets Monthly Updates

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

20 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
26

Transaction Reject

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 :grimacing:. “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.

Asset Swaps

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).

1 Like
27

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.

5 Likes
28

Dear Zcash community,

We are excited to share that we have pushed our pull requests for the implementation of the Transfer Protocol, as described in draft ZIP 226. The PR is here (PR#372), and the specifics are detailed below.

With this update, we are submitting the implementation corresponding to milestone #5 of the ZSA proposal and grant - Transfer Protocol Implementation PR (previously called milestone 3a).

This submission builds on top of the Issuance PR submitted earlier for milestone #6. The submission includes:

Burning mechanism:

With this, you are now able to publicly burn ZSA notes in addition to being able to transfer them. This adds a burn field inside the Orchard bundle along with the necessary changes to make use of it.

The full list of changes is listed in ZSA burn functionality #35.

Note Encryption:

The encryption of the notes also now works for larger note sizes, as is required for the addition of the asset identifiers.

We extended the Domain trait in the zcash_note_encryption package to allow for variable length encryption and decryption, by converting the constants to trait-specific types. This also involved updating various parts of the librustzcash crate to adapt to this generalization. The PR for this is zcash_note_encryption generalization zcash/librustzcash#746.

We also implemented this updated Domain trait for V3 notes in the orchard crate. The PR for these changes is V3 encryption #38.

Python test vectors

We have updated the zcash_test_vectors repository to generate test vectors that account for the above changes. The details of these changes are in the Testing encryption v3 zcash-test-vectors#6 pull request and the zsa1 branch.

Other changes

  • To avoid the ambiguity of the word “type”, the term note_type used previously was renamed to asset of type assetID. (Thanks @daira )
  • We have also constructed test vectors for the derivation of AssetID . The details of this are in the AssetID test vectors #34 pull request.
  • The split note mechanism is also included, but not currently activated. Activation will be done only once the circuit is ready, so as to preserve the transfer functionality in the meantime (activation point).

There are tests included to allow you to check these changes out — do let us know any comments you have on the PR so that we can track everything.

Next steps

The status of other pending steps is as follows:

  • The changes to the circuit to support the AssetID, split notes, and the other functionality changes are in progress (part of milestone #3).
  • The backward compatibility for the serialization of the encrypted notes (to support both V3 and V2 simultaneously) is also in progress.
  • The relevant ZIPs (ZSA Protocol ZIPs - Transfer and Issuance. zcash/zips#649) are also currently being reviewed, and the fixes and comments made there might require implementation changes, which we will be working on as well.
  • We will also soon submit the ZIP and Specification changes, thereby completing Milestone #7 - ZSA Protocol Specification.

Going forward, we will finish the implementation of the circuit for the proof, with which we will also be able to activate other implemented mechanisms such as the split note functionality. We will also be completing the note serialization backward compatibility simultaneously.

Best,
The ZSA Team.

15 Likes
29

Bouncing Chammy’s comment above which was not addressed, and is not covered in the “Next Steps” bullets below.

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.

2 Likes
30

Thanks for pointing this out @noamchom.

Hello @Chammy, in the update last month we had provided a fee mechanism:

… we have another pull request for the Fees ZIP, viz. QED-it/zips#2 .

We have subsequently merged our additions into ZIP 317 and created a pull request on the zcash/zips repository, namely PR#667.

It would be great if you could add your concerns about the viability of this mechanism to the conversation in PR#667, so that we have a single place to keep track of the comments and ensure they are addressed. Otherwise you could reply in this thread and I will add it to the conversation there and we can work on addressing them :slight_smile:

Thanks!

9 Likes
31

Hi Vivek - Thanks for the follow-up.

Would it be possible for you to explain the economics of the fee mechanism that you propose, and specially, a) how does it protect ZEC holders from freeloaders shielding assets for an insignificant fraction of the asset value in ZEC fees, and b) how does it ensure that ZSAs won’t artificially multiply the value of the Zcash network without generating similar additional demand for ZEC?

Thanks!

1 Like
32

Hi Vivek, I thought that is why we have this forum and why you post your updates here.

So would it be possible that you answer my questions regarding the economics behind the fee mechanism that you propose?

It is very worrisome (or is it telling?) that these questions keep getting dodged.

3 Likes
33

Hi Chammy,

(“freeloaders”, “insignificant”, “worrisome”, “telling”, “dodged”) → this register makes me uncomfortable, but I see where it’s coming from, please consider we’re here to build stuff and we realize the importance to the Zcash community…

In the ZIPs & PRs that Vivek linked to, we proposed and implemented the most direct mechanism, which is referred to as “Computational-Cost Transaction Fees”. I like the simplicity of this mechanism, it’s aligned with changes in ZEC fees, but we could implement other mechanisms if the community sees an advantage.

The obvious tweak is to require higher fees for ZSAs transfers, in the form of a constant multiplier. For example, the ratio of ERC20 to Native Eth is 3x, according to this.

For ZEC holders, I think the upside is from the overall increased relevance of the Zcash ecosystem and the ability to innovate with ZSAs with less operational risk to ZEC itself.

I’m pretty sure this first proposal is not the final word in the fee conversation, if anything it’s more like a perfectly plausible stub :slight_smile:

10 Likes
34

Does rushing to conduct a million dollars worth of development, without having crunched the numbers that ensure economic viability for ZEC, also makes you uncomfortable?

Because it really should but it seems that it just doesn’t :slight_smile:

Not surprised that my questions made you uncomfortable as the mechanism you chose guarantees that ZEC holders can get abused by freeloaders shielding assets. It also allows for the Zcash network to artificially multiply its value without generating similar demand for ZEC.

In other words, everybody wins but ZEC holders

To zodlers: I apologise for my tone, but it just gets tiring that the ZCG part of the dev fund keeps getting exploited for self-gain and in detriment of ZEC holders. In this case in particular, a million dollars worth of community-funded R&D that can (and likely will) be used to profit in alternative or even competing projects.

2 Likes
36

Huge :+1: from me on this.

I’ve believed for quite some time (six years, to be precise) that adding the ability to atomically swap assets on-chain is the logical next step after ZSAs are deployed.

I would keep the design simple, in the interest of minimizing “time to deploy” over bells and whistles (or perfect privacy). I feel like latent demand for a private, truly decentralised digital asset trade settlement platform is likely to grow over the coming years, and it would be great is Zcash could be first to market with that capability.

12 Likes
37

Dear Zcash community,

We are excited to share that we have concluded the milestone on ZSA Protocol Specifications!

This is the fruit of working with the skilled devs from ECC and ZF, resulting in comments, iterations, joint discussions, fixes and re-implementations of key insights.

We have now opened new pull requests for the ZIPs of the Transfer and Issuance Mechanisms that include specification details, the PR can be found here: ZIPs 226 & 227 - ZSA Protocol: Transfer, Issuance and Burn by PaulLaux ¡ Pull Request #680 ¡ zcash/zips ¡ GitHub

With this update, we are submitting the material corresponding to milestone #7 of the ZSA proposal and grant - ZSA Protocol Specification (previously called milestone 5).

Some of the results of these discussions with ECC and ZF are:

  • We have discussed and addressed comments made in the earlier pull requests (viz. https://github.com/zcash/zips/pull/649 and https://github.com/zcash/zips/pull/628) and brought the documents even more in line with the structure and language of other Zcash Improvement Proposals.
  • We have separated out the rationale for our choices from the exact changes we propose, with a view to making it simpler for implementers and reviewers to read what has changed in the specification.
  • We have also added even more references to the protocol specification sections and ZIPs where it would help connect our ZIPs with the existing background material.
  • We have also made certain changes that help make ZSAs easier to use going forward, even if there is a move to a new (post-Orchard) anonymity pool. The most significant of those are:
    • The key structure for Issuance is now constructed in line with (but independent of) the Orchard and Sapling key structures in ZIP 32.
    • The asset identifiers are now independent of the protocol, and we have a separate step that converts the identifier into a format relevant for each protocol.

We look forward to hearing your comments on these proposals on this pull request!

Best,
The ZSA Team

27 Likes
38

Does each shielded asset have their own separate anonymity set, or do they share? And if they do share, do they also share with ZEC?

2 Likes
39

Yes, all shielded assets and Orchard ZEC will eventually share the same anonymity set. I say eventually because it’s obvious that all notes created prior to ZSA adoption are Orchard ZEC, but once all wallets adopt the new transaction format, it won’t be possible to tell whether you’re spending Orchard ZEC or any other asset. (Sapling and Sprout still have separate anonymity sets, of course.)

14 Likes
40

This is great, I gave the ZIPs a quick review and it looks solid to me!

7 Likes
41

This might actually mitigate the effect the transition to proof of stake will have on the shielded pool then.

2 Likes
42

Dear Zcash community,

We are excited to share an update on our efforts with the Zcash Shielded Assets (ZSA) project! We have been working hard towards getting our protocol ready for an external audit, and thus getting it on the path for integration with the NU6 network upgrade. There is still work to be done on this front, but we have made a significant amount of progress in the last few months, and are now in a position to mark the completion of Milestones #10 (Audit Preparation) and Milestone #11 (Preparation for Integration towards Deployment) of our grant proposal. In this post, we want to highlight some of our progress towards these milestones, that is also due to the comments and reviews of the members of the ECC and ZF teams and their regular syncs with our team.

Milestone 10: Audit Preparation

  • Clarification of UTF-8 usage in asset descriptions:

    Our discussions resulted in the consensus that the asset description string should be recommended to be encoded in UTF-8 according to Unicode 15.0.0 or later, without making it a mandatory requirement (which would require a consensus rule, and possible future encoding in a circuit).

  • Padding of input notes:

    Our initial design padded notes such that the numbers of Spends and Outputs were equal per Asset Identifier. A more efficient design, that we have incorporated now, is that padding can be applied to the overall number of notes.

  • Issuance Replay Vulnerability:

    Identified a potential replay vulnerability if we allow transactions containing only one bundle, viz. the issuance bundle. In that case, the SIGHASH will be created using only the issue bundle information, and hence a duplicated bundle will have the same issuance signature, which means a replay attack becomes possible. We solved this by requiring at least one input aside from the issuance bundle. This guarantees a change of the SIGHASH between transactions since inputs cannot be reused.

  • Choosing finalize at the block boundary instead of the transaction level:

    Our initial protocol was ambiguous about whether, if an Asset is finalized in one transaction in a block, it can no longer be issued in the same block. The existing Zcash principle is to allow shielded transactions to be freely rearranged within a block. Therefore, we made it explicit that the finalization becomes active at the block boundary, and no new Assets can then be issued from a subsequent block onwards.

Milestone 11: Preparation for Integration towards Deployment

  • Adjusting Asset Identifiers for improved future compatibility:

    Changed the Asset Identifier definition to the pair (ik, asset_desc) and derived the Asset Base for each shielded protocol using a hash into the curve. This has improved future compatibility than the original definition of the Asset Identifier as the point on the curve, since it allows the Asset Identifier to be fixed for every future protocol. Only the hashing to a point of the curve will vary from protocol to protocol. This would allow for easier movement between protocols in the future.

  • Updating Issuance key structure for improved future compatibility:

    This allows issuance keys to be picked independently of the Orchard keyspace. We now follow the mechanism of ZIP 32, which allows for future expansion of the issuance keyspace into a tree structure if it is deemed necessary.

  • Rust version compatibility:

    Our implementation currently uses Rust 1.61, and we have discussed with the ECC team that upgrading to beyond Rust 1.64 at the moment could cause issues with building on Android. We are keeping an eye on the status as this issue is resolved.

  • Updating the txid_digest structure to align with ZIP 244:

    We have ensured, in consultation with the ZIP editors and other stakeholders, that our updates and additions to the transaction digest conform with the existing ZIP 244 structure.

  • Using a flag byte with masking instead of a single bit for finalization:

    Having a full byte with masked bits allows for better serialization and deserialization, and therefore we have changed our design to use this improvement.

We thank the community for their reviews and comments on our ZIPs and implementation so far, as this is helping us roll out an even more robust protocol and implementation. We’re excited about the potential of Zcash Shielded Assets, and how close we are to making it a reality. As always, we welcome your comments and feedback, either on this forum or as comments on our pull requests (viz. PR#680 and PR#667) as we enter these final stages of fine-tuning our design.

Stay tuned for more updates!

Best,
The ZSA Team.

21 Likes