[Grant Update] Zcash Shielded Assets Monthly Updates

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