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:
- Add more features to issuance (e.g. multiple issuance, locked/limited/delayed/option/optional issuance, etc)
- 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.