## Further notes for proposal

- talk about NFT and the need for privacy
- not necessarily
-

## ARBORIST CALL NOTES

- for when NU6?
- shared roadmap
- backwards compatibility?

https://electriccoin.co/blog/update-ecc-research-and-paths-forward-for-zsas/
# Zcash zkAssets QEDIT Grant Proposal

This post outlines a proposal by the [QEDIT team](https://qed-it.com/) to build generic shielded assets on the Zcash blockchain. These are usually referred to as User Defined Assets (UDAs) or as Zcash Shielded Assets (ZSAs).

## Motivation and overview

At QEDIT we believe that privacy is a universal human right. We also believe cryptography is a powerful tool to provide financial privacy, which promotes the freedom of the individual.

With this proposal, we want to bring DeFi to the Zcash ecosystem, and at the same time enable the use of the best privacy technology within the existing DeFi ecosystem! A couple of months ago we asked, and the community answered: [generic shielded assets (ZSAs / UDAs) are the most requested feature at the moment](https://twitter.com/BenarrochDaniel/status/1428327864034791429).

To pave the path for private DeFi, we wish to extend the Orchard protocol with these three features:

- Implement a permissionless issuance mechanism for native shielded assets, which will provide users with some degree of programmability over minting different types of assets (fungible vs non-fungible, public vs private supply, etc)
- Extend the transfer mechanism to allow for multiple types of assets to be transferred in the same transaction, while maintaining a single anonymity pool for all assets
- Enable a secure one-way bridge with other blockchains, allowing for existing assets to be imported onto the Zcash ecosystem

These features form the basis for a fully fledged native and private DeFi ecosystem on Zcash such as private DEX, AMM and lending (as well as anonymous credentials for identification), which we see as future work. Our goal is to develop these core features with extensibility in mind.

The project is expected to last between 8-10 months of design and development and another two months of review and merger with the main code-base (or as defined by the NU6 deployment roadmap, to be determined).

### Approach & desiderata

To build a usable MVP that will enhance adoption of Zcash, since this is the first core development project outside of the ECC and Zcash Foundation, we will work with the community and other stakeholders to test our assumptions, and ensure that our final design includes the user's feedback. The design must prioritize usability, economic and technical considerations. The following is a list of desiderata:

- *Usability:*
- take a product and experience (UX) design approach
- build easy-to-use, stable APIs
- ensure, when possible, the interoperability of different implementations (e.g. zcashd vs zebrad)
- *Economic:*
- design an incentive mechanism for the validators and current users of $ZEC (e.g.:ZEC-based fee structures)
- ensure reserve integrity for imported assets by verifying collaterals exist in the corresponding blockchain
- *Technical:*
- identify underlying commonalities (such as locking / burning mechanisms)
- ensure the development is aligned with other builder teams, creating a shared roadmap for the development of the Zcash ecosystem
- incorporate feedback from other experts and work with security teams for ensuring proper review of the code

### Applicant background

We are [QEDIT](https://qed-it.com/about-us/), the cryptography team that performed the audits for both [Sapling](https://medium.com/qed-it/sapling-audit-9b531be9d30) and [Orchard](https://qed-it.com/about-us/) before they launched into mainnet. We run the [ZKProof standardization effort](https://zkproof.org), and we are leading the [zkInterface interoperability standard]() within the DARPA-funded [SIEVE program](https://www.prnewswire.com/il/news-releases/qedit-joins-forces-with-galois-as-part-of-us-government-funded-initiative-to-advance-zero-knowledge-proof-cryptography-301132470.html) to advance the state-of-the-art of ZKPs. We've built the first enterprise-grade private asset transfer solution, extending the Sapling protocol.

## Technical components & scope

In this proposal we do not aim to provide the exact details of how the features will be designed or implemented. Our goal is to give some intuition of why we believe that this project can be done and to collect feedback and input from the community on these topics.

For each of the outlined components below, there are several aspects to their implementation:
- Core cryptographic protocol design, specification and implementation
- Circuit changes and implementation
- Integration within blockchain components, such as consensus rules, networking, etc.
- Integration with existing nodes (Zcashd & Zebra)
- Security assurance through tests coverage and internal reviews

### Core Feature: generalized shielded asset transfer

In order to be able to represent different assets in Orchard, one needs to define a new data field that uniquely represents the _type_ of the asset in question.

It has to be done in a way that enforces the balance of an action description to be preserved. Mainly, the $\mathsf{value^{old}}$ and the $\mathsf{value^{new}}$ must be balanced only **with respect to the same asset type**. Ideally we would also like to allow different action descriptions to transfer different asset types, where the overall balance is checked without revealing which assets (or how many different types) are being transferred.

Below we overview a possible direction for accomplishing this feature. As mentioned, it is not the goal of the proposal to outline the details of the design for each feature. This direction, which was first outlined by Daira Hopwood and Jack Grigg in [this github issue](https://github.com/zcash/zcash/issues/830#issuecomment-891855536), involves using a single _value base point_ (out of a fixed number) for the value commitment for each _asset type_ in a transaction. Today, the (net) value, $\mathsf{v}$, of a note in the Orchard protocol is committed using a Pedersen commitment [(§5.1.3)](https://zips.z.cash/protocol/protocol.pdf#concretehomomorphiccommit)

$\mathsf{ValueCommit}^{\mathsf{Orchard}}_{\mathsf{rcv}}(\mathsf{v}) := [\mathsf{v}] \mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}$

with fixed value base point, $\mathcal{V}^{\mathsf{Orchard}}$ and randomness base point $\mathcal{R}^{\mathsf{Orchard}}$, derived from a fixed string, using the $\mathsf{GroupHash}$ function:

- $\mathcal{V}^{\mathsf{Orchard}} := \textsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:Orchard-cv"}, \textrm{"v"})$
- $\mathcal{R}^{\mathsf{Orchard}} := \textsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:Orchard-cv"}, \textrm{"r"})$

In the ZSAs update, we would like to allow for each asset in a specific transaction to have a different value base point. In order to reduce the cost of the circuit, we do not require that the base point itself be tied to the unique asset type identifier, `ASSET_ID` (i.e.: the base points are not globally unique). Instead, we can generate a set of fixed value base points $\mathcal{V_1,...,V_l}$, one for each asset type in a transaction (up to $l$). As long as the same base point is used for each of the action descriptions with the same asset type, the balance will be verified correctly for a given transaction. This method does require the transaction to have pre-determined fixed fixed of asset types, where the value base points can be reused across different transactions and for different asset types (across those transactions). This enables the circuit to be the same for every action description. The different base points should be derived using the $\mathsf{GroupHash}$ function:

$\mathcal{V}_{\mathsf{idtype}}^{\mathsf{Orchard}} := \textsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:Orchard-cv:type_i"}, \textrm{"v"})$

Where `type_i` designates the asset type in slot `i`.

It makes sense for the specific `ASSET_ID` of that asset to be added to the note structure, and as we mention below, this `ASSET_ID` will be tied to the issuance mechanism. This is in order to make sure that the recevier can validate the asset type, and that the integrity of the UTXO chain for a given type is preserved.

Note that in order to keep the privacy of the transaction with respect to asset types, allowing different asset types to be aggregated within the balance check, the $\mathcal{R}^{\mathsf{Orchard}}$ will stay the same for all asset types, as it is the component where the binding signature verification key is aggregated.

Also, intuitively, the design yields for different asset types and the same balance verification process will ensure that homomorphically the balance is preserved between the same asset types. If different asset types are spent and output, the verification will fail with overwhelming probability. Making this design correct and sound, intuitively. Furthermore, this construction requires $\textsf{GroupHash}^\mathbb{P}$ to be resistant to second-preimage atttacks.

Of course, this is not the only possible way to implement this feature, and we will explore others before finalizing the design and specification. One such alternative is to append the unique string identifier to the value itself, while maintaining the same base points for all asset types. Though this may increase the development complexity, as it would imply changing the circuit to verify that the value commitment is a commitment to two values of the same type, it may yield for more extensibility in the future.

### Core Feature: issuance mechanisms

In order to transfer assets with different types, one must issue them on the blockchain. The [$ZEC]() asset is currently issued through a proof-of-work mechanism, and is implemented using a (private) mining transaction.

To support generic asset types, we will have to implement further transaction types to enable their issuance into the system. As outlined in Jack Grigg's [proposal](https://hackmd.io/88PN_LuiQPi4QSjwxTBTTg), various applications require different issuance functionality (e.g.: public vs private, schedules, crowdfunding, etc.)

There are two major components to the issuance mechanism, which we plan to implement as two different transaction, extending the Orchard protocol:
1. Registration of the token, which stamps on-chain all the information about the asset, making it official that the asset exists (though initially not in circulation). The specific information that we will add, may include the following:
- the registrar address: the user who established the registration
- a list of allowed minter addresses (those who can mint)
- asset type identifier, `ASSET_ID`
- maximum supply
2. Minting of the token, which generates a transaction and sets a specific amount of tokens in circulation. This could be
- The registrar address is only allowed to mint
- A list of minting addresses are allowed to mint
- Other rules will be explored to enable different types of minting.

We will explore the possibility of using [Transaction Zcash Extensions (TZEs)](https://zips.z.cash/zip-0222) in order to implement the registration and minting transactions. One way to make it work would be to implement them as a chain of UTXOs.

We aim to design a protocol that would also allow for key rotation within the minting addresses, allowing both for revocation and for key-recovery mechanisms. Having a UTXO chain may be used to enable this, as the "owner" could represent the "allowed minter" address.

We are currently considering designing these in a transparent manner (except for the transfer due to the minting transaction), and we leave private issuance of assets as an extension of the MVP and as future work. We would first like to ensure that there is an inherent economic incentive to add privacy while maintaining the integrity of each asset in circulation. In a transparent issuance mechanism, the total supply in circulation of each asset can be known by analysing the blockchain contents.

#### Asset type identifier `asset_id` definition

The `asset_id` can be generated using some random string, or even a hash derived from the issuer address (which could benefit a future private issuance mechanism).

Note that by generating a unique random string as an asset type, we remove the need to handle a naming system, preventing users from maliciously chosing pre-determined asset type names. The mapping of these strings to their actual asset type names is to be handled off-chain, similar to how smart contract addresses are handled off-chain for Ethereum.

#### Importing of assets

In the MVP, importing assets from a different chain can be done by having an explicit address be the importer of that asset, acting as a trusted party to maintain a locked reserve of the original asset. We will however, take this process into account when designing the issuance mechanism such that it is feasible to import, at least, the ERC20 token standard of Ethereum.

In fact, the most flexibility comes from letting any user declare off-chain that they will hold the reserves (say of [$ETH]()) in a smart contract, and since the asset supply will be public, anyone can verify that the supply is backed by a reserve collateral. Note that this would also allow for some form of "mutual fungibility" since two different entities may decide to hold a reserve and issue "zBTC" on the Zcash chain, while registering different asset types. As long as these two entities are trusted, the two asset types are fungible (as long as the protocol allows for it).

In the design phase we will work with the Zcash Foundation team around the [FROST](https://www.zfnd.org/blog/frost-update/) secret-sharing scheme in order to potentially use multi-signatures to implement committee-like structures for importing assets. This would indeed reduce the trust given to a single entity.

In the future, probably with other proposals, we intend to explore further how to use zero-knowledge proofs to enable fully untrusted cross-chain interoperability of assets, but this is currently out of scope.

#### Other extensions

The two transactions outline above are enough to deploy a usable MVP. However, we will consider more advanced issuance methods that include a set of consensus rules for automated issuance / redeeming mechanisms, for example:
- Any address that sends [$ZEC]() to the registrar address in exchange for that asset will be able to redeem that asset from the registration pool (note that this will require revealing to the validators the amount being sent for exchange).
- An initial value of exchange may have to be added to the registration transaction information
- This may require to implement a new type of "swap transaction"
- The proof will have to verify that the exchange rate and values of different types are correctly implemented
- Users send ZEC tokens to the issuer address for an amount of time (i.e.: number of blocks) and at the end the number of assets sent is proportional to the raised funds.

Though it is out of scope, other extensions to issuance mechanisms may be around on-chain governance (e.g.: rules determining who and when can issue or mint), or around parametrizing automatic issuance of tokens.

We will gather inputs from different stakeholders to ensure that the issuance mechanism represents the needs of the community and users.

### Core Feature: fees structures

In order to ensure that the ZSAs / UDAs MVP offers the right incentives to different stakeholders, we will also implement a fee mechanism that will apply to all transactions.

The Electric Coin Company has been working with a team at George Mason University to simulate different fee structures and how they could impact the Zcash ecosystem at large. We hope to build on this project and work with both teams to design such a mechanism for ZSAs. As part of the project we want to ensure that all the relevant parties are involved in designing a structure that truly benefits the whole ecosystem. In essence, we will start with two basic methods to explore:

1. Default method - use the existing fee mechanism today with [$ZEC](), applied to all asset types:
- fixed fee per transaction, indifferent of asset type
- same for issuance transactions
2. Low-hanging fruit - introduce some variability based on different criteria:
- change fees depending on the type of transaction, but still make it fixed
- change fees based on the number of action descriptions or per KB

We want to ensure that the fee mechanism fits well within the desired privacy model of indistinguishable transactions. We also believe that the fees should be paid in the native [$ZEC]() token to ensure its value in the ecosystem.

In a future proof-of-stake mechanism, there may be different type of "validators" and as such, fees may vary depending on the validating operation being performed (e.g.: verification of proofs vs staking validation).

### User-focused reference implementation for wallet APIs

We plan to provide a reference wallet API implementation for using multiple-assets. Given our experience in product development, we will always aim to design the protocols through that lense, focusing on its usability. Moreover, we hope to work with different wallet providers to ensure the smoothest user experience.

## Execution risks and mitigation strategies

We are aware that so far, there have not been other teams (outside of the ECC) building on the core protocol of Zcash. From our experience in building standards, communities and managing consortia of entities with diverse interests, we are ready to work with all the teams involved, and the community, to establish a shared roadmap of development, enabling smooth work and deployment of all the protocol updates.

We can see some interesting challenges that could come up, and we will put them upfront to ensure we do not miss any risk. Some of these include:

- Reducing the risk of code conflicts or lack of integration during development by other teams
- maintain communication with other development teams
- pull / align the codebase often
- Ensure that the deployment of NU6 is properly defined and scoped, not too long after our development.
- Ensuring the design of the protocol is extensible to and compatible with future updates. Specifically with certain DeFi protocols that the community may want.
- Ensuring that the design of the MVP is apealing enough to users to increase Zcash adoption. For this, we will
- use prototypes / stubs to test usability among the ecosystem
- start testing early before implementation
- work closely with the community
- Ensuring that the solution is financially viable for users (e.g.: high fees and low scalability)

## Milestones and deliverables

The following are the different milestones or outputs we will deliver as part of the project. The estimated timelines are provided below. These milestones will be used to define the budget of the project. In order to abide by the best practices of deployment in the Zcash ecosystem, we will work according to the processes outline in [this post for NU6 deployment](https://electriccoin.co/blog/network-upgrade-pipeline-2-0/). All ZIPs will be written according to the [ZIP Process ZIP](https://zips.z.cash/zip-0000).

1. **Transfer Functionality ZIP:** _Publish the final ZIP specification of the multi-asset support in Zcash transfers with minimal infrastructure for issuance of assets on chain_
- share initial designs of protocol and circuit changes
- gather feedback from stakeholders, dev teams and the community
- feature freeze for MVP
- write and publish ZIP draft after internal protocol security review
- engage the broader community for technical and usability feedback
2. **Transfer Functionality Implementation:** _Two pull requests to Orchard and blockchain node repositories respectively_
- includes protocol and circuit level extensions / changes
- includes consensus and local client validation of transfers
- includes minimal issuance method (e.g.: as-is fees in ZEC)
- API extensions for transfer transactions
- extensive tests
- self-contained environment for end-to-end testing
3. **Issuance Mechanism ZIP:** _Publish final ZIP specification of MVP for feature-based on-chain issuance mechanism_
- gather feedback on initial designs from the community and independent stakeholders
- feature freeze for MVP
- registry and minting transactions
- include simple mechanism for cross-chain asset import
4. **Issuance Mechanism Implementation:** _Two pull requests to Orchard an blockchain node repositories respectively_
- includes protocol level extensions / changes
- consensus and local client validation of issuance
- minimal fees structure
- API extensions for transfer transactions
- extensive tests
- private testnet environment for end-to-end testing
5. **Fees Structure ZIP:** _Final ZIP specification of fees structure_
- engage with different stakeholders & create a working group to define the ideal fee mechanism for ZSAs' MVP
- publish initial design for the community to provide feedback
- reach official consensus on the design
- publish final ZIP
- engage the broader community for technical and usability feedback
6. **Fees Structure Implementation & Final PRs:** _Pull requests for fees structures and final PRs for all three ZIPs to relevant repositories_
- implement final consensus rules changes
- implement final APIs in blockchain node
- implement extensive unit, functional and end-to-end tests
- merge with other branches and PRs into test development branch
- deployment of full implementation to (private) testnet for review and testing by the community
7. **ZSA-Orchard Deployement Strategy & Specification:** _Final ZIP specification and implementation of deployment mechanism, and updated [Zcash Protocol Specification](https://zips.z.cash/protocol/protocol.pdf) with all features_
- define and implement methodology for updgrading the Orchard protocol with backwards compatibility (e.g.: upgrading existing orchard-based ZEC to zsa-orchard-based ZEC, since notes may have a different format)
- write in LaTeX all necessary updates to the Zcash Protocol Specification and submit PR to the repository
- work with ECC, ZF and other dev teams throughout the project to agree on the roadmap and features included in the network upgrade
- work with the ECC, ZF to write the final NU6 ZIP specification (similar to the one written for [NU5](https://zips.z.cash/zip-0252))
8. **ZSA-Orchard Protocol Audit Support:** _support the audit process for the ZSA-based Orchard extension_
- publish call for proposal for an audit to ensure the security of the implementation and design
- support teams to submit a grant proposal to fund the project
- work with the chosen teams to ensure the audit is smooth and has highest amount of coverage
9. **NU6 Deployment Support:** _Support for deployment to public testnet and mainnet as part of the NU6 network upgrade_
- ensure that all PRs are properly reviewed and merged with the testnet branch
- participate in community roadmap calls to ensure the processes is carried out according to the plan
- work with the community and users to test the deployment and fix any issues before mainnet
- - ensure that all final issues are taken care of and the PRs are merged with the mainnet branch
- advertise the upgrade jointly with other teams to ensure adoption as a main result of the project

### Timeline

| Milestone | Title | Estimated starting date | Estimated delivery date|
| --------| -- | -------- | -------- |
| 1 | Transfer Functionality ZIP | January 15th | March 15th |
| 2 | Transfer Functionality Implementation | March 15th | June 15th |
| 3 | Issuance Mechanism ZIP | February 1st | May 1st |
| 4 | Issuance Mechanism Implementation | May 1st | July 31st |
| 5 | Fees Structure ZIP | May 1st | June 15st |
| 6 | Fees Structure Implementation & Final PRs | June 15th | August 1st |
| 7 | ZSA-Orchard Deployement Strategy & Specification | June 1st | July 31st |
| 8 | ZSA-Orchard Protocol Audit Support | August 1st | November 1st |
| 9 | NU6 Deployment Support | TBD | TBD |

## Budget and payment plan

Given the complexity of this project, as a core set of features to the protocol and with multiple coordination, consensus and integration efforts needed, it makes more sense to price the project per output. Our proposal is as follows:

| Milestone | Title | Budget | Work Type|
| --------| -- | -------- | -------- |
| 1 | Transfer Functionality ZIP | $121,000.- | Design |
| 2 | Transfer Functionality Implementation | $217,800.- | Development |
| 3 | Issuance Mechanism ZIP | $181,500.- | Design |
| 4 | Issuance Mechanism Implementation | $217,800.- | Development |
| 5 | Fees Structure ZIP | $72,600.- | Design |
| 6 | Fees Structure Implementation & Final PRs | $72,600.- | Development |
| 7 | ZSA-Orchard Deployement Strategy & Specification | $48,400.- | Dev & Spec |
| 8 | ZSA-Orchard Protocol Audit Support | $33,000.- | Coordination |
| 9 | NU6 Deployment Support | $33,000.- | Coordination & Development |
| **TOTAL** | - | **$997,700.-** | - |

The team size may vary from 2-5 people according to the needs of the specific milestone, at a cost of $1,000.- per person-day. The budget includes a 10% conservative buffer.

## Acknowledgements

The QEDIT team involved in writing this proposal includes Daniel Benrroch, Pablo Kogan, Michael Adjedj, Aurel Nicolas, Eran Tromer, Jonathan Rouach and Prof. Aviv Zohar.

We would like to thank the following individuals and teams for their help in thinking about the proposal, its contents and implications, as well as for the fruitful discussions since this idea was brought up: Mary Maller, Matt Luongo and the ECC core development team.