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

Community Grants Applications
62

Yay it lets me listen without logging in, cool!

4 Likes
63

Fyi: The Twitter app doesn’t like the link for recording on my phone. Works if I search for it or put link in browser.

1 Like
64

Issuance

TLDR; we should consider only allow for a single issuance of assets at asset creation time. My understanding of the issuance discussion was that allowing for multiple issuance calls was one of the likely options. That might be the best option but I want to make sure the team has thoroughly thought through if there are actually any benefits or if we are just complicating ZSAs for the sake of having nice sounding “issue” function.

It might be better for users to issue large amounts of assets at ZSA creation and disperse them as needed from a single/multisig address.

There are a few concerns I have with multiple issuance:

  • How does an owner of “wrapped Bitcoin” transfer the issuance keys to a new owner?
  • We can barely trust certificate authorities to never leak private keys let alone a $1B wrapped Bitcoin asset.
  • It adds extra consensus rules
  • There’s a meaningful amount of work for providers, exchanges, explorers, wallets, developers, and users to adapt to the idea of multiple issuance.
  • When we implement DAOs we have the extra complexity of DAOing transfers AND issuance.
  • How does burning work?

Single issuance answers a few of these questions:

  • An owner of “wrapped Bitcoin” can transfer the remaining issuance holding to a new owners address.
  • If the owner of “wrapped Bitcoin” was worried about the safety of their private keys (e.g. hardware lost/compromised) they can transfer assets to new address (with their backup).
  • Single issuance during asset creation simplifies implementation of ZSAs and reduces surface area for attack/audit.
  • Single issuance would mean explorers/wallets don’t have to worry about the UX concerns of multiple issuance.
  • Zcash DAOs might be simpler to implement if only having to deal with transactions and not issuance.
  • In most cases sending an asset back to the asset disperser/DAO would be equivalent to a burn.

Unfortunately we don’t have DAO like structures yet but I imagine sometime in the future we have something similar to ZSA-addresses.

I feel like multiple issuance adds unnecessary complexity to implementing DAOs. For example could a ZSA-address control issuance?

4 Likes
65

Reflecting on my reply if we were to have multiple issuance we need to make sure we implement burning correctly. If we advocate issuance should be transparent (in some way) we should have a native (and simple) transparent burn too.

3 Likes
66

I very much agree with the idea of keep it simple and I share your worry things will get complex. But I think its needless complexity we can eliminate and I think single issuance in the way you suggest would actually result in more work.

Each ZSA requires an identifier. The simplest way to do that is have it be the hash of the public key you sign the issuance statement with. Absent adding global state keeping and consensus rules, that allows unlimited issuance. (Ideally, we’d support keys and sigs people can already custody in hardware)

The easiest way to allow single issuance would be to support the same signing key as identifier trick, but append/prepend the blockhash its issued in before hashing.

Moreover, I suspect multi issuance is a key thing if you wanted to have, for example, shielded tether. The alternative would end up hurting privacy: whenever tether wanted to issue more, they’d have to make another distinct ZSA. This is a fungibility and privacy issue.

6 Likes
67

Reducing complexity is always good :+1:.

This is the part I haven’t grasped yet. What’s the difference between multiple issuance and tether performing a single issuance with the max amount (2^56?) assets to a transparent-like address and transfering them out when required?

  • Both create visible on-chain actions
  • Both are controlled by a private keys
  • Both can be used to calculate the effective issuance

My understanding was this would be easier to implement then multiple issuance. If that’s not the case I stand corrected.

1 Like
68

In the case of single issuance I think the biggest benefit is at least tether could transfer any uncirculated assets to a new address if needed. Not sure it’ll be possible to transfer an “issuance” address in this MVP?

1 Like
69

Are you referring to the DAO mechanism I mentioned? Yes I think that’s a lot of work and am sure there are better solutions so let’s ignore that part :person_facepalming:.

The only aspect I’m still unclear of is what benefits we get from multiple issuance over a single max issuance to a transparent-like address and dispersing them as required.

But if multiple issuance doesn’t add that much extra complexity I’m happy to take your word for it :slightly_smiling_face:. My intuition is telling me multiple issuance adds just enough complexity it’ll create a little snowball effect which adds complexity all the way down the chain but like you said maybe it’s manageable? I was just curious if there was any actual benefit or is just “easy enough” we may as well do it anyways?

1 Like
70

Oh, if you assume theres both transparent issuance and a pending state before it gets shielded, yes you can do that. At least pre QEDIT, no one had proposed that and I don’t think QEDIT did either. But this just moves all the problems you worried about + managing a pending state to this transparent asset.

Popping up a level: I agree, the thing we do need to avoid, and I think this is what you’re getting at more generally, is complexity. ZSAs should be as minimalist a feature as possible. And making a complicated feature seems like a real risk. Preventing that will require constantly proposing alternatives and seeing if we can get something radically simpler (maybe by dropping a requirement).

In particular, we should avoid adding a very complex state machine to handle multiple issuance (as i said above, I think thats possible), key rotation, and whatever other features are deemed necessary.

Luckily I think this is doable. And I think we can make a system that only requires a tiny amount of simple state kept in a UTXO. No global state or smart contracts. Just a local object that you can do two things with 1) issue new units of currency under the objects identifier (if it was created to allow that) by signing under an associated key 2) replace the key that allows issuance (also by signing under and associated key)

5 Likes
71

The thing i’d ask both @GGuy and everyone else, is track what the features are for ZSAs and then see if you can propose a simpler way of doing it. Ideally dropping no features, possibly dropping at most one.

I’ve heard a part of the community wants issuance to not use transparent transactions.
So the amount of an issued asset in almost all cases needs to be public. So any method that extends Orchard TXs would have to do that. None the less, not using transparent has an appeal, both philosophically and technically: it doesn’t intrench tadds. And indeed, I think the inability for Zcash as a community to say, at some point in the distant future, taddrs should go away, is a major problem.

BUT, my guess is doing issuance (but again, fully shielded transactions) via transparent is radically simpler. We have an existing design for simple statekeeping via TZEs, so the engineering is simpler. Perhaps more importantly, tooling exists for signing bitcoin like transactions that partners can readily adapt.

To go the other way is to risk complicated features interacting with complicated cryptography. That’s not a good way to ship something on time or on budget.

4 Likes
72

Should these be combined into the issuance mechanism? An issuance specifies the subsequent (or same) key required for next issuance?

I imagine there is more in common between a transparent transaction and a transparent issuance then there is between a shielded transaction and a transparent issuance.

Maybe we need to consider where transparent transactions will exist in the future.

  • A seperate recursive proof based transparent pool?
  • Within a shielded pool?
  • Not at all?

I’d probably argue we’d want transparent issuance to happen in the same place transparent transactions happen.

1 Like
73

Hey @GGuy, I just saw this discussion and it is great.

We have not yet fleshed out all the challenges associated with a 2-step issuance, but we are also considering a 1-step issuance (currently the preferred option).

Essentially we are thinking about

  • issuance through an “output-only” note using the sapling or orchard structures, while ensuring that the encryption keys are always some 0 vector, known to all, or the viewing keys are provided (tbd what is more efficient / robust / easier to implement)
  • burning mechanism through a “spend-only” note in a similar fashion as the issuance. This would be very elegant in my opinion, but there is also the simpler version of just sending the tokens through a usual transfer to a pre-determined burn address that no one has the keys for.

In general I tend to agree with your pros/cons list, except that

  1. Even if a two-step issuance is more complicated to implement, it may allow for more flexibility in the future in terms of extending the issuance functionality (i.e.: describing issuance schedules, auctions, etc…), so we are also evaluating the extensibility
  2. Even if two-step issuance requires more consensus rules (i.e.: two transaction structures and the second one must match the first, etc…), the two-step would probably provide a more “secure” issuance mechanism as the first transaction would essentially register the tokens, sort of committing to them. In this respect, I am not sure what you mean by

Why would a two-step issuance imply easier leakage?

  1. I actually believe that the two-step issuance may be easier to track for explorers / wallets, as there is even more information that can be provided (e.g.: amount of assets in circulation vs the amount of assets to be put in circulation)

Regarding the ZSA addresses, we were also playing with the idea, and though it is in principle out of scope for the project, it is one of the use-cases that I am personally most excited about.
Having “contract-like” addresses in Zcash would not only enable DAO-like structures for funds to be controlled by some specific trigger or other, but also things like non-interactive atomic-swaps, fund locking mechanisms for DeFi, as liquidity providers / custodian addresses.

And regarding this

In fact, the first step issuance may be used to enable the ZSA-address to issue tokens as a DAO structure, whereas the one-step issuance may not.

8 Likes
74

ZSAs

I assume by two-step you are referring to a process whereby the second step is issuance and could happen more then once? With one-step I wasn’t sure if you were referring to a single issuance, multiple issuance, or both. I’ll assume multiple for my responses.

Two-Step

Using the past precedent that transactions can have outputs that have never been seen maybe that means issuance should too?

While I do agree two-steps would give us more flexibility I’m not sure these extra options need to be a compulsory first step. Rather it could be implemented as an optional first or second step. Hopefully that means any future additions of this as an optional first or second step shouldn’t break existing ZSA users if we only implement one-step for the MVP.

One-Step

One-step could support single or multiple issuance. In the case of multiple issuance I imagine the parameters could include the ID (random for a new asset?), the amount of the asset, and the subsequent issuance address thats allowed to issue more. This subsequent address could be the same or different to the previous issuer. Also if you wanted to announce an asset but not issue any just set amount to 0. Not sure if this would make things drastically simpler though.

We might also want to mark the first issuance in a one-step scenario so in the future we could take advantage of any optimisations that could be gained by partially or fully ignoring blocks before genesis of the asset in certain use-cases.

Burning

While I imagine it’s unlikely to be used in the near term I imagine if both were available a spend-only note could signify a recyclable asset (one that might be reissued) while a burn address would signify an asset that shouldn’t be reissued (as is the case today). So yes I also like the idea of a spend-only note to mark why that action is special.

Encryption/viewing keys

Don’t know what’s best. While hardcoding some known keys for this feels a bit hacky it’s probably not a bad hack, especially for an MVP :slightly_smiling_face:.

DAOs

I imagine, as mentioned above, a one-step approach could specify a DAO as the next address with a 0 issuance. In the future we could allow for that optional “setup” step to configure more complex configurations/options.

Changing/Revoking issuance keys

I made this statement assuming issuance keys can have a long life and can’t be easily changed or revoked. CAs feel similar as they could also be thought of as two-step.

  1. Creation of root certificate
  2. Issuance of intermediate and end entities certs

Are you thinking about a mechanism for how we can change the issuing keys? Could be as simple as a one-step issuance I mentioned where we specifying the new key (which could be the same) to be used for the next issuance. Or could be a seperate method/mechanism. Removing issuance could also be achieved by setting the next issuer to 0x0.

ZSA Addresses (off topic)

The way I like to think of it is what are the minimum set of features that allow for a decentralized L2? I imagine a DAO-like ZSA-address controlled by staked nodes could give us that. Then the debate is no longer “what features should Zcash have?” but rather “should this feature exist in L1 or L2”? :exploding_head:

2 Likes
75

Single issuance

If you were referring to one-step issuance as a single issuance mechanism I agree with everything you said with regards to us losing some of that extra information on-chain. Multiple issuance is one way to get that. This is probably the strongest justification for multiple issuance.

The other is a more generic labelling/marking of transactions but that’s outside the scope of this work. It also introduces a significant side-channel an attacker could use to leak/disseminate information so would require some deeper thinking before commiting to it.

1 Like
76

TLDR;

The simplest version of a ZSAs on Orchard would be:
1. Single issuance of 2^56 assets using an output-only note.
2. The issuing entity publically reveals their viewing keys so users can audit/calculate the number of assets in circulation (e.g. 2^56 - current assets - burnt assets).
3. The entity burns any excess asset they won’t need with a spend-only note (e.g. 2^46)
4. The issuing entity circulates the assets as required.

When we start with this design we have 2 options to add more features to the design:

  1. Add more features to issuance (e.g. multiple issuance, locked/limited/delayed/option/optional issuance, etc)
  2. Add more features to transactions/addresses (e.g. transparent addresses in Orchard, locked/limited/delayed/option/optional transactions, etc)

I vote 2 because both these features benefits the whole Zcash ecosystem. 1 only benefits ZSA use cases and would requiring extra work and maintenance if added it to transactions as well.

I’m not advocated we do all of 2 now. Just that we should build ZSAs with the expectation that we will add more features to transactions in the near future. Because if that’s the case it might not be necessary to implement 1 if we expect to have 2. And implementing both would just increase the attack surface for malicious actors which is always bad.

Long Version

Arborist Call

Just listened to the call. Good to see everyone is talking around the same page. (P.S. calls are invaluable, people are watching!)

Assumptions

Before I dive into specific comments I think some of these decisions are strongly influenced by the individual’s assumptions of what Zcash will look like in the future. Let me list mine.

ZK based Transparent Addresses

Eventually we will want to deprecate the old Bitcoin based transparent addresses. But I believe this will only happen once we have ZK based transparent addresses.

Lock/Limited/Delayed Addresses/Transfers

We will need the ability to lock, limit, and delay ZEC/assets in the future to allow for custodian and DAO like scenarios. I think there is an elegant way if implementing this but I won’t bring it up here.

Single Issuance (currently my prefered)

My fundamental belief is that if there is a use case we can’t achieve with “single issuance + transactions” we should try to fix transactions to fit those use cases before we make issuance more complex.

Auditablity Of Assets In Circulation

The only way we can audit the number of assets in circulation is if the circulating entities transactions are viewable.

Viewing Keys

The use of viewing keys in Orchard could be an effective way for asset providers to allow the auditing of assets in circulation. Unfortunately that probably requires the keys to be distributed off-chain which isn’t optimal but it’s by far the easiest.

Transparent Orchard Addresses

IMO the optimal solution for auditablity of assets in circulation, in Orchard, when using single issuance is to support transparent addresses in Orchard. Then when a single issuance occurs to a transparent address it can be used for distributing of assets into circulation.

An explorer or wallet can easily calculate and display “assets in circulation” by viewing this address and looking at its current balance. I’d even argue that this is so effective we shouldn’t even allow for the initial issuance amount to be configurable. Always issue 2^56 assets to the requesting address and they can choose to publically burn some huge amount (e.g 2^46).

@LeCryptoMath I understand adding transparent orchard addresses is technically outside the scope of this project but on the surface to me it would appear to be in the same realm with implementation complexity as some of the other two-step multiple issuance ideas. Although risk is higher of course since it would involve ZEC. I wonder if we went this route if ECC (or Zfnd) would have capacity to partially or fully assist with this work?

Extending ZSAs

One of the primary goals of the ZSA MVP is to allow ZSAs to be extended for more advanced use cases. I think some of these first extensions might include delayed/conditional transactions, custodian/locking of assets (disable transactions), time/amount limited transactions, options/optional transactions, schedules transactions, etc.

We could utilise any advances in transaction functionality to facilitate more complex issuance/circulation use cases. Do we want issuers to utilise these functions directly through transactions or do we want issuance specific versions? Extending transactions likely benefits more users then putting effort into issuance specific functions.

No Turnstyle

If this is going to be built ontop of Orchard I agree with @daira. No turnstyle, same pool, etc. I feel this is the obvious decision so won’t discuss unless someone has opinions otherwise.

One-Step

Of course with what I’ve been describing above I prefer the idea of one-step. But I would also argue that even if we think two-step issuance might be something we need in the future we should still do one-step and make two-step optional. If two-step was then added in the future a one-step issuance would just be a shortcut for a two-step with some defaults.

5 Likes
77

Store of value network is going to have assets issued on it: https://lightning.engineering/posts/2022-4-5-taro-launch/

2 Likes
78

Wow that’s awesome a defi on Zcash, you guys are wonderful team.

79

Id like to see a proof of concept on a testnet before this is funded. The amount of research that appears to be necessary to get a useful utility from user assets, is taking a back seat to the rush to get a product to market.

The minimum viable product solution is not going to provide a utility to any use cases for UDA’s, transparent blockchains that provide NFT’s and other assets like tokens, can improvise with pseudo-anonymity without funding. It seems like we would be spending money on a To Be Announced product that is not proven to have a utility that offers anything that another blockchain isn’t already providing.

3 Likes
80

I have just assigned ZIP numbers 226 and 227 for the ZSA ZIPs: [ZIPs 226, 227] Zcash Shielded Assets ¡ Issue #618 ¡ zcash/zips ¡ GitHub

16 Likes
81

@LeCryptoMath Gentle reminder to file a PR for ZIPs 226/227 on zcash/zips :slight_smile:

5 Likes