[Grant Update] Zcash Shielded Assets Monthly Updates

Community Grants Community Grants Updates
63

can you provide a sensitivity around a base case and expected?

64

I recently watched the QEDIT sessions at Zcon4, very interesting that ZSAs are not only useful for shielding coins but could be used for NFTs and even decentralized governance/voting.

With the transition to Zebra as the core, what kind of timing are we looking at to get this on testnet? Or the next NU?

6 Likes
65

@shawn You might also be interested in the ZSA updates from recent Arborist calls. (sorry abt the poor sorting)

https://github.com/search?q=repo%3AZcashCommunityGrants%2Farboretum-notes+zsa&type=code&p=1

4 Likes
66

That link is weird for me idk, gonna try this one

1 Like
67

Dear Zcash community,

Best wishes to all of you for 2024! We are happy to share with you an update on what we have been working on over the last few weeks. We have made some exciting progress on Zcash Shielded Assets as well as the Asset Swaps and Zebra node work, which we will be detailing below.

V6 Transaction structure for the Zebra node

We have implemented the initial V6 transaction format as specified in ZIP 230, thereby enabling support for Zcash Shielded Assets (ZSA) features such as burn and issuance.

The major changes involved in this include an extension to the ShieldedData struct and a Rust feature flag activation for all V6 transaction changes. More details can be found in PR#3 and PR#5 on our fork of the repository.

Zcash / Zebra Transaction Testing

Due to the move to Zebra and the fact that Zebra does not generate transactions but only verifies them, we are developing a test tool for transaction generation. While this tool will eventually be used for ZSA/TxV6 testing, it will also be helpful for testing the existing transaction structure. Therefore, we decided to add TxV5 support as well, and focus on this for the initial release. Later, when librustzcash is ready with full V6 transaction support, we will upgrade the tool to perform both V5 and V6 transaction testing.

Additionally, the Zcash Foundation has recently added an experimental test-only internal miner into the Zebra codebase, which allows us to mine native ZEC Assets more easily during our tests. This addition supports our testing effort since we can now focus on the Orchard pull and avoid dealing with unshielded transactions.

Zebra node test setup for forks

The Zebra node is currently being tested only against the main-net chain. We are therefore working on upgrading the existing test setup for the Zebra node to support different chains. This will allow us to test the node against modified chains that support different sets of consensus rules, such as the future ZSA-enabled chain.

Moving to the Bitcoin Schnorr scheme for the Issuance Authorization Signature

We had previously described our changes to the ZIPs in order to move to the BIP 340 Schnorr signature scheme for the issuance authorization signature. We have essentially completed the implementation of this scheme change in the Orchard-ZSA implementation and will merge it in the coming days after an internal review.

Extending Orchard-ZSA with backward compatibility for V5 transactions

We have been working on generalizing our additions to the Orchard crate so as to simultaneously support both V5 and V6 transactions, which is a necessary step for integration in NU6. We are excited to announce that we are in the final stages of this work, and that we will soon also be merging in these changes. We look forward to having a version of the implementation that handles both V5 and V6 Orchard bundles.

Atomic Swaps Design

We have made changes and improvements to the Atomic swap design as part of the initial review and the community feedback. We encourage everyone to have a look at the draft document!

Edits to the ZIPs

There aren’t significant changes in this area, our ZIPs have been largely stable for some time now. We received some comments from the ZIP Editors regarding rearrangements that would improve readability and clarify ambiguity, which we have incorporated. We look forward to having them merged and included on the zips.z.cash site soon!

As always, please feel free to play around with our work. Let us know if you have any questions, or just what you think!

Best,

The QEDIT Team.

27 Likes
68

I really appreciate this Grant, let’s pass everything on to Brazilian community. You’re sure to love it.

Thanks

3 Likes
69

Dear Zcash community,

We are really excited to share with you the first DRAFT versions of the ZIP (specifically ZIP 228) that covers the ZSA Swap protocol. This corresponds to Milestone #6 of our Asset Swaps and Beyond grant.

This ZIP has been in the works for the past few months and we have interacted with the community, the ECC and the ZF developers while designing for compatibility, usability, and security of the protocol. We’ve mentioned the draft Google Doc in previous posts, where we’ve had some great discussions in the process of creating this design.

A short description

Motivating use case

The primary scenario we have in mind is one where there are two parties who want to exchange some quantity of Assets between each other.

ZSA Swaps

  • The ZIP provides a specification for a Swap Order, which is what a party creates when it wants to send some quantity (q1) of an Asset (A1) in return for some quantity (q2) of another Asset (A2).
  • In the P2P case, one party sends it’s Swap Order off-chain to another party who wants to send the quantity q2 of Asset A2 in return for receiving q1 amount of Asset A1. This second party creates it’s own Swap Order to that effect independently
  • Once the two Swap Orders are present, the ZIP specifies how the party can combine them into a transaction that simultaneously transfers the respective amounts of the two Assets between the two parties.
  • We have included a time limit for the validity of a Swap Order, so that the party receiving the Order in order to settle it does not get the unfair advantage (free option) to wait indefinitely until it can profit from a more favourable exchange position.

Under the Hood

Our design required some changes to the Orchard-ZSA protocol in order to be able to handle valid Orders in all scenarios. The major update has been addition of the time limit as mentioned above, and the grouping of Actions based on the Merkle tree root they are constructed under, so that the zero-knowledge proofs in them can be verified appropriately.

Our aim has been to keep these changes to a minimum so that we can stand on the shoulders of the existing cryptography that is already in place in Orchard and Orchard-ZSA. We encourage you to go through the ZIP for the specifics and let us know your comments.

Discussion points

  • Though creating a design to support the peer-to-peer case has been our main focus, we do note that our design is flexible enough to allow for the secure use of Matchers in place of having one of the parties submit the Swap transaction to the chain. This allows for the support of Zcash transaction relays, and support for Matching Services, centralized or otherwise.
  • We have provided a discussion on the considerations for fees as well as some ideas for maintaining fairness and preventing denial of service attacks

Comments

These ZIPs are in DRAFT mode and will definitely see some changes in the months to come, as we receive feedback from the community and developers, as well as changes that arise in the implementation process. We will soon begin working on a prototype of these designs.

We welcome any comments and questions! We hope to hear from you all about your thoughts on our work.

Best,
The QEDIT Team.

15 Likes
70

are ZSAs like the engine part?
but someone has to build a DEX front-end for it also?
is this correct thinking? or is there more to make it all work after ZSAs are ready to launch?

71

The ZSA Protocol allows for issuing new Assets, and for transferring Assets between parties.

If we are keen to have a transaction where we want to exchange Assets, the Transfer protocol allows you to send me Assets and me to send you Assets. However, since the two transfers are not “linked”, there is a possibility that your transfer transaction gets on the chain and I prevent mine from getting on the chain. So then I have the Assets you sent me, but I haven’t held up my end of the bargain.

That’s where the Swaps protocol comes in. You create an Order for the transaction you want to happen, I create an Order for the transaction I want to happen (which would be the reverse of your Order, essentially). Neither of us lose custody of our Assets until the two Orders get combined into a single transaction, and that transaction gets on the chain.

This immediately allows for a much wider range of financial transactions using ZSAs, since it reduces the need for trust between two peers exchanging Assets. Swaps, as they stand, also support us sending our Orders to some matching service that looks at the orders coming in and matches them and creates the total transaction to settle on the chain. Those could be CLOBs, AMMs, and so on. But that would be separate work to build these services, it isn’t part of the consensus protocol on Zcash.

6 Likes
72

thanks. sounds great that swaps are possible with no other service.

but we will need someone to still build the AMMs etc. wonder who will do that.

1 Like
73

Dear Zcash community,

We have been working towards making progress on our milestones for the ZSA and Asset Swaps grants. On the back of our initial draft of the Asset Swaps ZIP a few days ago, we’re really excited to share that we have now published our tool for testing transactions to Zebra nodes. This corresponds to Milestone #8 of our Zcash Shielded Assets Grant.

We believe that this tool will help not just us as we continue with our implementation of ZSAs with Zebra, but also to other developers in general who want to locally test their wallets or other tools with Zebra nodes.

The repository for this tool can be found here: GitHub - QED-it/zcash_tx_tool: A testing tool for Zcash transaction generation

The functionality, in brief

Developers will be able to use this tool to create and send Zcash V5 transactions to a Zebra node. We have included a Docker image creation process to set up the testing scenario.

We highlight that there are a few changes to our mode of node operation as compared to the normal Zebra node.

  • We have an activation height of 1,060,755 blocks. For ease of operation and reduction in the sync time that would be needed to get these many blocks, we have pre-mined blocks up to the activation height and stored them in a database that is built into the Docker image.
  • The consensus branch ID is set to a custom value — this ensures that the testing takes place on a fork of the main chain.
  • The node does not connect to peers (it has an empty peers list). This allows for testing in a manner similar to Regtest mode on zcashd. Furthermore, while zcashd regtest mode had proof of work enabled but set to a low difficulty for block mining, this tool disables proof of work so as to simplify the generation of new blocks by the single node, and focuses on the creation and sending of transactions.

Please go ahead and try it out, and let us know your thoughts or comments!

Best,

The QEDIT Team.

17 Likes
74

Dear Zcash community,

As we progress with ZSA deployment work and Asset Swaps design, in March we’ve been focusing on Zcash backward compatibility to get ready for integration. This work touches on the core libraries of Zcash, allowing ZSA to be compatible with the rest of Zcash.

The deliverables for compatibility of ZSA with Orchard are part of a larger milestone related to NU6 Integration. We’re splitting this milestone in 2 parts, where the next part will consist of the work with ECC and ZF to support including ZSA in the coming network upgrade(s).

For more details:

Orchard crate backward compatibility

We have completed additions to the Orchard crate to achieve backward compatibility. We have confirmed and tested that our code now simultaneously supports both v5 and v6 transactions. This is a necessary step for integration in NU6, and we are currently working on a second pass through this code, refactoring to improve the code quality and optimize where possible.

Orchard test vectors backward compatibility

Alongside the orchard crate changes, we are also refactoring the changes we made to the zcash-test-vectors repository so that we can generate test vectors for Orchard and OrchardZSA in parallel. Here too, we are working to improve the code quality by minimizing the duplication of code.

Halo2 backward compatibility

We need to be able to generate circuits for the OrchardZSA circuit while still supporting generation of the original Orchard circuit. This required us to make certain changes to the structure of the routines while ensuring the generated Orchard circuit continues to remain unchanged. We have made good progress in this regard, and should be able to wrap this up soon.

Librustzcash support for V6 transactions

The changes in orchard above require changes to be made to the librustzcash crate to support the newly introduced generics. These changes are under internal review, though completion will have to wait for the stabilization of the orchard crate backward compatibility work.

Audit

We’re contacted the teams at Geometry Research and Least Authority (the Zcash Ecosystem Security Lead) about performing audits of the ZSA Protocol. The audit is an important step in getting the protocol deployed on the Zcash main-net, and we’re excited about the possibility of such accomplished teams helping us get there! We will provide updates about the status of this in future posts.

ZIPs

We are happy to share that the ZSA ZIPs, ZIP 226, ZIP 227 and ZIP 230, have been merged and included on the zips.z.cash site! Of course, please feel free to keep dropping comments about these ZIPs, we are always interested in hearing feedback and perspectives.

We have also submitted an initial draft of ZIP 228 for Asset Swaps (rendered version here), as was described in a previous post.

As always, please feel free to play around with our work. Let us know if you have any questions, or just what you think!

Best,

The QEDIT Team.

17 Likes
75

Hello Zcash Community,

We’re happy to share with you another update on the status of our work with getting ZSAs to you!

Halo2 gadgets

  • We have added a trait to generalize the existing lookup range check. This creates the ability to instantiate the relevant lookup range check for both the OrchardZSA circuit and the vanilla Orchard circuit.
  • Unlike for the Orchard circuit, the halo2 gadgets are not tested for layout changes. We are We are also testing the relevant halo2 gadgets against the vanilla Orchard circuit layout, and ensuring that any changes do not affect the layout of the existing circuit.
  • We are going to submit a PR for the above work to the halo2 repository as a stand-alone enhancement. This PR will include the trait, the vanilla Orchard instantiation, and the tests.

OrchardZSA and zcash_note_encryption

  • We have been merging the upstream changes in orchard, and we have stabilized our additions on top of the 0.8 version. The upstream changes in orchard have required some changes on our end, which we have completed. These changes have been around the builder, the output indexing and the flags.
  • The support for variable note sizes in zcash_note_encryption has been completed and submitted as a PR (PR#2) to the zcash/zcash_note_encryption repository. We are looking forward to the review and subsequent merging of the work.

V6 transaction format

  • This work involves additions to librustzcash — the generation of the new format transactions along with the updates to the TXID and SIGHASH computations. We will be ensuring these are compliant with the specification via comparison and testing against the alternative implementation in python discussed below.

Python reference implementation

  • We have added OrchardZSA functionality to this python implementation. This has been designed such that it leaves the Orchard functionality unchanged, while adding code and refactoring where possible in order to create the OrchardZSA functionality.
  • We are preparing a PR to the parent repository for review and merging. Furthermore, we are also working on updating the implementation to account for the TxV6 format and TXID and SIGHASH changes.

Testnet

  • We have also begun the groundwork for setting up a testnet for ZSAs.
  • The first iteration is a single Zebra node set up on a cloud provider in a reproducible way.
  • We will be adding the ZSA functionality as we go ahead and scaling up the work on this accordingly.

As always, please feel free to play around with our work. Let us know if you have any questions, or just what you think!

Best,

The QEDIT Team.

7 Likes
76

@vivek will share our June update now :slight_smile:

77

Hello Zcash Community,

We’re happy to share with you another update on the status of our work with getting ZSAs to you!

Zebra support

  • We have updated our Zcash Transaction Testing tool for the Zebra node to allow it to support V7 transactions in a backward compatible way.
  • This will allow for the generation of V7 transactions for the Zebra node while maintaining the support for V5 transactions that is there already. There is some of the refactoring to move from V6 to V7 that is still to be done here.
  • Full Zebra support also depends on v7 support by librustzcash and orchard, for which we outline our work below.

V7 transaction format support in librustzcash

  • This work involves additions to librustzcash — the generation of the new format transactions along with the updates to the TXID and SIGHASH computations. We will be ensuring these are compliant with the specification via comparison and testing against the alternative implementation in python discussed below.
  • We also made the refactor of our work from V6 to V7 and NU6 to NU7, to reflect the expected timelines for ZSA deployment.
  • We have also made changes to put all the ZSA related code within feature flags (specifically, the zcash_unstable="nu7" flag. This will enable the smooth merge of these features into the repository.

librustzcash and Orchard testing — Python reference implementation

  • We have added OrchardZSA functionality to the Zcash python reference implementation. This has been submitted as PR#100 to the parent repository. We are looking forward to it getting reviewed and merged.
  • We are currently working on updating the implementation to account for the TxV7 format and TXID and SIGHASH changes. This has also involved a refactor to switch from V6 to V7 and NU6 to NU7, as in the librustzcash setting.

Halo2 gadgets

  • We have a PR for the work to the halo2 repository as a stand-alone enhancement that is under review. This generalizes the existing lookup range check.
  • This is complemented by a separate PR that incorporates these changes into Vanilla Orchard, which is well underway. This will contain the vanilla Orchard instantiation, and tests the relevant halo2 gadgets against the vanilla Orchard circuit layout, and ensures that any changes do not affect the layout of the existing circuit.

ZIPs

  • We opened a new pull request, PR#854, to the upstream zips repository in order to track changes to the ZSA ZIPs that have been made since the earlier pull requests were merged at the start of 2024.
  • We are also working on the updates to the ZIPs to move to V7 and NU7, as in the other sections.

OrchardZSA and zcash_note_encryption

  • Our work to support variable note sizes in zcash_note_encryption in PR (PR#2) to the zcash/zcash_note_encryption repository is awaiting review and subsequent merging.

As always, please feel free to play around with our work. Let us know if you have any questions, or just what you think!

Best,

The QEDIT Team.

9 Likes
78

Thanks for your efforts!

Has any consideration gone into the decentralised order matching network? Would be very nice for Zebra node operators to have software bundled that allows them to earn ZEC for submitted ZSA swaps to the chain.

Its out of scope for ZIP-228 but hoping Qedit considers community feedback!

5 Likes
79

I want to understand better about Zsa, I want to do tests, learn how to program Zsa.

1 Like
80

How do I test ZSA? I wanted to create contracts, stablecoin style currencies, I wanted to learn how to use ZSA. Is there any way to create things in a test environment just to learn how to use ZSA?

3 Likes
81

Hello Zcash Community,

We’re here with another monthly update on the status of our work on the ZSA project!

Zebra node

  • We have been refactoring the ZSA portions to target the NU7 upgrade instead of NU6.
  • In addition, we have added a placeholder for the TXv6 additions that will come in for NU6. This is to proactively prepare for the NU7 work being added on top of what is deployed in NU6.
  • We have continued to work on the Zcash Transaction Testing tool for the Zebra node, providing functionality to support V7 transactions (TXv7).
  • We have also been progressing on the consensus changes for NU7 in the Zebra node.
  • In addition, we have been adding support for V7 transactions in the various repositories like librustzcash and orchard, since full Zebra support is contingent on this functionality being available. More details on that are below!

Halo2 gadgets

  • We’ve formally submitted a pull request (PR#823) to the upstream repository with the changes I had mentioned in our last update!
  • This PR is a generalization of some of the halo2 functionalities, that will serve as a stepping stone for further changes that are in progress (see last bullet).
  • To help seamlessly get this merged, we have also provided a pull request (PR#429) to the orchard repository that highlights the changes that would be needed to use the generalized halo2 version (without affecting Orchard functionality).
  • We are currently working on a bigger refactor, which will provide backward compatible halo2 gadgets. This work will build on top of the PR#823 mentioned above.

ZIPs

  • We have revisited the ZIPs for the ZSA protocol, and made some additions to the specification in order to more explicitly specify the serialization of the issue notes.
  • We have made an update the compactSize representation for the asset description size, allowing for better serialization and deserialization in the implementation.
  • We have better specified the data types of some of the fields in the transaction format, as well as made some minor rearrangements of the burn fields to better fit the spirit of the current specification.
  • These changes are being reviewed internally, following which we will merge them in to our existing pull request, PR#854, to the upstream zips repository.

V7 transaction format support in librustzcash and orchard

  • We have made changes to these crates to get the implementation in line with the changes to the ZIPs mentioned above. We have also been able to test these changes with the reference implementation (described below) to confirm there is no unexpected behavior.
  • We are also changing the type of the burn value in the Orchard-ZSA bundle to be of the orchard::NoteValue type instead of the transaction::Amount type, as that is a better fit for the properties we want the burn value to satisfy.

librustzcash and Orchard testing — Python reference implementation

  • In addition to the PR#100 we mentioned last time, we have made good progress towards updating the reference implementation to incorporate the ZSA changes to the transaction identifier and sighash.
  • We are in the process of cleaning up the code and aligning with some of the recent changes made in the librustzcash and orchard crates, post which we will be able to submit a second PR to the upstream repository.

As always, please feel free to play around with our work. Let us know if you have any questions, or just what you think!

Best,
The QEDIT Team.

5 Likes
82

crazy how it’s been almost 3 years already

nuclearFusion
nuclearFusion1074×664 39.3 KB

It’s truly frustrating to see year-long efforts being rendered ineffective because of, in part, an ongoing zebra migration.
If we’re on track then NU7 will happen in Q3/4 2025. That’s 4 years after the first ZSA draft; 1 entire halving cycle.

I’m very happy once there’s consensus around pure-vs-auditable ZSAs. That’s one last delay factor that I’m anticipating. At least we now have robust and tested shielded voting for checking community consensus :relieved:.

6 Likes