A Proposal for Shielded Assets (ZSA/UDA) for DeFi on Zcash

Community Grants Applications
1

This post outlines a proposal by the QEDIT team to build generic shielded assets on the Zcash blockchain. These are usually referred to as User Defined Assets (UDA) or as Zcash Shielded Assets (ZSA).

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 (ZSA/UDA) are the most requested feature at the moment.

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.

EDIT #1{
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, the cryptography team that performed the audits for both Sapling and Orchard before they launched into mainnet. We run the ZKProof standardization effort, and we are leading the zkInterface interoperability standard within the DARPA-funded SIEVE program 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 optimal execution.

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

\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{type_i}}^{\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 of the transaction.

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

EDIT #2{
We note that to build the issuance feature, we will focus on a developing a single mechanism that encompasses the most fundamental type of issuance, which will be defined according to the consensus reached with the community.
}

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 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 ZSA/UDA 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)

\begin{EDIT #3: add milestones, timeline and budget}

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. All ZIPs will be written according to the ZIP Process ZIP.

  1. Transfer Functionality ZIP: Publish a full draft 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 to upgrade ZIP to proposed status
  2. Issuance Mechanism ZIP: Publish a full 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
    • scope: registry and minting transactions, simple mechanism for cross-chain asset import
    • engage the broader community for technical and usability feedback to upgrade ZIP to proposed status
  3. Transfer Functionality Implementation: Full PRs 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
  4. Fees Structure ZIP: Publish a full 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
    • engage the broader community for technical and usability feedback
  5. ZSA-Orchard Deployement Strategy & Specification: Publish a full ZIP specification and implementation of deployment mechanism, and updated Zcash Protocol Specification 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)
  6. 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
    • API extensions for transfer transactions
    • extensive tests
    • private testnet environment for end-to-end testing
  7. Fees Structure Implementation & Full PRs: Full 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 (dedicated) testnet for review and testing by the community
  8. Node Wallet State Implementation: Full PR to the blockchain node repository
    • implement tracking of balances, notes and other node specific state
    • connect all ZSA APIs to the node, to expose ZSA via RPC API
    • enhance management of node-specific private state to support shielded assets in full
  9. 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
  10. Network Upgrade Deployment Support: Support for deployment to public testnet and mainnet as part of the NU6/NU7 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

By full ZIP and full PR , we mean complete and mature proposals that are ready for ratification/merging. We recognize that final ratification/merging by the community, ZF and ECC may require additional process and iterations, and we are committed to participating in that process and addressing any hurdles that arise.

Note that for the cryptographic development, we will work on the protocol and backend Rust crates, and for the node, wallet and API aspects our preference is to build on the Zebra codebase, but if the dependencies do not mature in time, our fall back is the Zcashd base.

Timeline

Milestone Title Estimated starting date (2022) Estimated delivery date (2022)
1 Transfer Functionality ZIP January 15th April 15th
2 Issuance Mechanism ZIP January 15th April 15th
3 Transfer Functionality Implementation March 15th June 15th
4 Fees Structure ZIP May 1st June 30th
5 ZSA-Orchard Deployment Strategy & Specification May 1st July 15th
6 Issuance Mechanism Implementation May 1st July 31st
7 Fees Structure Implementation & Final PRs June 15th August 31st
8 Node Wallet State Implementation August 1st September 30th
9 ZSA-Orchard Protocol Audit Support June 1st November 30th
10 Network Upgrade 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 $141,570 Design
2 Issuance Mechanism ZIP $188,760 Design
3 Transfer Functionality Implementation $235,950 Development
4 Fees Structure ZIP $94,380 Design
5 ZSA-Orchard Deployment Strategy & Specification $56,628 Coordination & Spec
6 Issuance Mechanism Implementation $235,950 Development
7 Fees Structure Implementation & Final PRs $102,245 Development
8 Node Wallet State Implementation $62,920 Development
9 ZSA-Orchard Protocol Audit Support $31,460 Coordination
10 NU6 Deployment Support $37,752 Coordination & Development
TOTAL - $1,187,615 -

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

\end{EDIT #3}

Acknowledgements

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

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.

We welcome feedback from the community to improve this proposal. Once we collect feedback we will submit it as a grant proposal to the ZOMG for review.

62 Likes
2

:clap: … so excited to see this on a number of levels. This seems to me to be a thoughtful and well designed approach to achieving something many in the community would love to see, by a well respected and qualified team.

But perhaps more importantly, it would bring another strong team into building significant capability to the protocol. This is what I had personally hoped to see with the creation of ZOMG! It’d be a massive step forward for the project.

Love it!!

34 Likes
3

I endorse everything that @joshs wrote. I’m very excited at the prospect of QEDIT joining the Zcash ecosystem! :smiley:

24 Likes
4

Welcome to the forum @LeCryptoMath Excited to see this proposal being discussed here. I hope this proposal will be accepted very soon.

Some comments regarding the fee mechanism:

The current default fee is not currently enforced by the protocol. It is conventional and were only intended as social consensus between “wallet developers, miners & Zcash users”. A transaction can still be valid even if they don’t follow ZIP-313. If ZSA were to be added with this mechanism, are you guys proposing the fee to be enforced or “as-is” (i.e. enforced socially but not at protocol-level)?

13 Likes
5

This is inspiring! Thank you @LeCryptoMath for your time on this post and in the past work with the core team!

Is there a way to implement a minimum ZEC balance in ZSA capable wallets? This would be a step in the right direction towards avoiding a free rider problem. I posted before an idea where maybe we could make it so as more wallets are created (with ZSA capabilities) we could create a function that decreases the minimum ZEC balance required and vice versus. This would allow this idea to scale with demand.

Thanks in advance for any feedback.

p.s. All though we have amazing talent working at ECC and ZF, attracting third parties like this is so needed. Let the dominos fall! :slight_smile:

11 Likes
6

I’m very excited and optimistic to see this team bring this vision to the community.

Not only has ECC’s collaboration with qed-it on audits been excellent, and not only is this an inspiring vision and early proposal, but having more independent teams showing up and focusing on different areas of improving the Zcash protocol is a major boon. We look forward to collaborating!

18 Likes
7

I really like this proposal well written and as others have said, it’s exciting to see another development team interested in developing Zcash further, this was the whole point of ZOMG.

13 Likes
8

Welcome @LeCryptoMath to the forums!

The level and scope of work in this proposal is one of the core reasons I supported a new development fund for Zcash in the first place; to bring major teams to help offset the work being performed by ECC and ZF.

I’m also excited by the prospect of ZSAs in general and am very excited to see a team tackle them as a project for NU6. My only concern (besides possible cost) with this proposal is work structuring and coordination with ECC/ZF.

As you mentioned under “risks” heading in your post;

ECC/ZF has not historically coordinated with outside entities for core design decisions and I’m wondering how “hard” design questions will be approached.

For example; what if the research ECC contracted from George Mason comes back with one fee solution, and QEDIT has a differing fee solution, and ZF proposes another? Assuming everything goes smoothly it’s just a matter of a few Zoom meetings to work out a solution. Or if they don’t go smoothly there would have to be some sort of poll/vote? Or worse case, groups “agree to disagree” and do thier own thing resulting in wasted effort?

I hope these questions don’t come off as negative, I highly doubt it will come to a worst case scenario but it’s a non-zero possibility because there are humans involved. I really want something like a “multi-party core development team” to work but to get there we need to assume good faith, get up-front commitments from parties that they want this to work, and later be willing to compromise on things when needed.

I hope that everyone realizes what a fundamental shift in the future development of Zcash this proposal could represent. This type of work is something Zcash needs not only for decentralization but to be anti-fragile as a global currency supporting the greater good.

:zcash: :earth_americas: :hearts:

24 Likes
9

In my opinion, we need to progressively spend here ~ in a big way. Let us keep in mind, this proposal may very well set precedent to future organizations moving to zcash. Also, if done correctly and demand in the market shows up for these products ~ we will most likely see an increase in price of zcash. This GREATLY increases our capabilities to fund even more organizations and hopefully simultaneously!

This could be the start to a compounding investment!

ZOMG is setup such that they don’t need to ZODL zcash as long as the investments we bring in increase demand materially and ultimately promote more transactions/fees.

I propose, in this scenario, we document the three opinions. Then we send it to the zcap to vote on which strategy they like best. After this, we let the three organizations try to reach consensus on which method works best ~~ all in view of the public square (multiple public zoom calls, with preset schedule). If consensus is not reached, before the end if the preset schedule, we let zcap vote again and be the tie breaker! Power to the community.

Love where this is headed.

I share the same concerns as @Shawn but ultimately the community should have the final say. As long as everyone contracted can have an equitable voice in the public square I believe our community will choose wisely.

17 Likes
10

Welcome to Thought Club.

I call the privacy debate thought club, because our thoughts are where the most sensitive data is filtered.

7 Likes
11

This is what we need to complement the roadmap just published by the ECC! Totally support the initiative!! :clap::clap::clap:

9 Likes
12

Thank you @joshs ! Very much looking forward to making this happen with the community :slight_smile:

3 Likes
13

This is a great question. We did not finalize any design yet, and as such we hope to hear from the community what it is that works best.
In the proposal we do mean the former (enforced socially) by the default mechanism. That being said we do hope to not go for the default mechanism, it just depends on whether consensus is reached by all stakeholders (or a majority thereof).

Since the fee mechanism structure is independent of the actual cryptographic protocol, we are hoping to work on these two in parallel (at least for the design phase) in order to reach some kind of consensus on the fees by the time we start implementing the ZSA protocol for transfer and issuance.

What would you say is the ideal fees structure for you?

8 Likes
14

Thank you @rekodi for the input - we had briefly considered this problem but did not try to formulate a solution yet. I appreciate this proposal and will consider it.

Could you potentially elaborate on how it mitigates the “free-rider” problem?
As I understand it we would like to have some form of incremental funding on new tokens, correct?

5 Likes
15

All it would do is require anyone wanting to use the zcash network to acquire and store a stake in the limited supply of zcash. Without it, they would only need very little zcash due to the small transaction fee structure that is native to the zcash protocol. @LeCryptoMath

5 Likes
16

@Shawn you bring up a super valid point.
I will start by saying two things:

  1. The point here is not to prioritize one solution over another one as per the team’s preferences. It is to enable a community-backed solution.
  2. QEDIT does not have (yet) a solution fully outlined, which gives us the flexibility to be on the neutral side and take in as much feedback as possible. We have been in this situation before (in ZKProof and in DARPA), as the middle objective technical team in charge of bringing consensus for a solution and we never allow any technical, security or usability compromise.

Of course we hope that things will go smooth, but there are key aspects to this proposal where people in the community have strong opinions about, and we are aware of these. For this it is also important that all discussions happen openly such that there is enough transparency to create the right pressure.

Specifically, when it comes to technical aspects, we will absolutely work with the core ECC team as they have built the Orchard (and every other) protocol (basically) from the ground up (sprout was a result of the Zerocash paper). At QEDIT we have also built such systems, so we know what it entails from a security stand point. Our approach is to first collect all functionality requirements and then ensure that the design encompasses all of these.

In terms of fee structures, we do not have a strong opinion, and we will make sure to align the different parties around an initial MVP solution. If it comes to it, we will go for a community-based vote (why the ZCAP exists), making sure there is enough education on the solutions for individuals to make informed decisions.

12 Likes
17

I totally agree as well, and I hope the proposal shares this spirit!
I think, and as a general note to how the ZOMG will start funding large core projects, there is a need for the community to own the Zcash roadmap, and not just the ECC and ZF (mostly independently). This is especially important for teams that are being funded directly from the dev fund.

The community should define how this roadmap should be built and how decisions should be made. Different teams should be able to give proposals and then vote on schedules, functionality and features to be included, etc…

16 Likes
18

:clap: @LeCryptoMath Very well written post!

I’m a big supporter of having broad utility for ZSAs. I have only been thinking about this for a short time but have been pondering how much utility we can achieve from a small set of generic ZSA transaction types/features (e.g. ZCash programmability vs L2 using ZSAs).

I’ll try and simplify some functionality I’ve been thinking on below but I’m hoping that by using this simple base we could then offload any more advance features (like programmability) onto L2 POS style chains that using ZCash ZSAs as their L1…

ZSAs minting/transacting other ZSAs

Scenario 1 - Minting Token

A single user mints a “Minting” asset.

A new “IOU” asset is created and the “Minting” asset is assigned as the “allowed minter” with a 100% weighted threshold for minting. Since there is only 1 Minting token any minting request is 100% weighted and is automatically valid.

The user can transfer the minting token to other addresses which can then be used as the address to mint IOUs.

Scenario 2 - Multiparty Minting Tokens

Four “Minting” token assets are created. 3 joint business owners share the tokens. User 1 is assigned 2 assets while user 2 and 3 are assigned 1 each. The Minting token assigns itself as the “allowed minter” requiring 100% weighting to mint more (e.g. all parties must agree to mint more minting tokens).

A new “IOU” asset is created by the company for assigning IOUs to contractors. The “Minting” asset is assigned as the “allowed minter” with a 51% weighted threshold for minting. Since there are 4 Minting tokens any minting of IOU requires at least 3 of the 4 tokens are required to mint new IOUs.

Scenario 3 - Multiparty Minting Tokens using On-chain “voting”

100 anonymous users are giving 1 “Minting” token.

A new “IOU” asset it created and assigns the “Minting” token as the “allowed minter” and requires 50% weighted threshold for minting. Since the anonymous users don’t know each other they have to “register” their vote to mint on-chain with a new “transaction type” (e.g. vote/sign). I like the pseudo “sign” analogy since we can think of them as signature objects that possibly have things like valid after/before timestamps.

If the 50% threshold is reached the tokens are minted.

Scenario 4 - L2 programmability using ZSAs

100 stakers all run a “ZCompute” (fictional programable L2) node while holding/staking/locking “ZCompute Staking” tokens.

The staking tokens have “minting” and “transaction” rights for the ZCompute tokens and require at least 50% vote for minting and/or transactions to occur. As they compute (or verify a compute/proof) they place their votes for minting or transacting tokens.

Additionally to this ZCompute staking tokens need to be “lockable/destroyable/0x0 transferable” to disincentivize bad actors. Stakers can vote to “destroy” staker tokens from bad actors.

@LeCryptoMath I’d be interested to know your thoughts on this and if this is a feasible end goal :).

8 Likes
19

Fantastic proposal from QEDIT and very good approach.

I think, and as a general note to how the ZOMG will start funding large core projects, there is a need for the community to own the Zcash roadmap, and not just the ECC and ZF (mostly independently). This is especially important for teams that are being funded directly from the dev fund.

Looking forward to see the community involvement, this is another aspect that should be thought carefully considering also past experiences.

5 Likes
20

Hi all, just wanted to point out that we updated the proposal with concrete milestones, an estimated timeline and a budget. This is officially our proposal submitted to the ZOMG (hopefully to be made public as soon as they review it).

Any thoughts are welcome :slight_smile:

18 Likes