owned this note
owned this note
Published
Linked with GitHub
# Zcash Shielded Assets - Issuance
The design concerns about ZSAs can be roughly split into three areas:
- How to issue (and redeem / burn) assets.
- How to transact with them.
- How to handle fees.
This document covers the first area: what is necessary for defining, issuing, and removing from issuance (redeeming or burning) non-ZEC assets.
The goal of this document is to document:
- the requirements that various use cases place on issuance functionality; and
- the functionality that various issuance designs provide,
to enable us to find the intersection of these two groups.
## Definitions
- "Asset ID": the globally-unique identifier for a specific asset within the Zcash block chain.
- "Native asset": an asset natively defined within the Zcash block chain.
- "Guest asset": an asset defined off-chain, that can be locked up there and represented equivalently within the Zcash block chain.
- "Issuance": addition of some amount of a specific asset to general circulation within the Zcash block chain.
- "Redemption": removal of some amount of a specific asset from general circulation within the Zcash block chain.
- "Governing body": the entity or entities that control a specific asset, and are permissioned to perform issuance, redemption, or other similar actions.
- "Rotation": altering the effective membership of the governing body for a specific asset. This might not alter the actual membership (e.g. a member rotating their key).
## Potential use cases
### Generating custom native currency assets.
TODO: Expand this.
Possible requirements:
- Asset issuance and redemption is public.
### Generating custom native non-currency tokens.
TODO: Expand this (and how it differs in use-case from "custom native currency asset").
Possible requirements:
- Asset issuance and redemption is public.
### Enabling existing off-chain assets to be wrapped as guest assets.
> This section needs expanding. In particular, we need feedback from existing bridgemakers to elucidate what they actually require.
> [name=str4d]
TODO: Expand on the ways in which people do cross-chain asset movement.
Requirements:
- Asset issuance and redemption is public.
- This is necessary to ensure that the amount of the guest asset within the Zcash block chain matches the amount of the guest asset locked up off-chain.
Possible requirements:
- Asset issuance and redemption is public.
- Support for some kind of multisig.
- [UNCONFIRMED] Support for FROST-like multisig.
- [UNCONFIRMED] Support for Bitcoin-style multisig.
- [UNCONFIRMED] Support for existing BTC/ETH sigs/curves/ideally keys.
### tBTC
> A dynamic set of keys with the power to issue a single asset ID would be ideal for our designs.
> [name=Matt Luongo]
Requirements:
- A signature scheme that's verifiable on Ethereum. So secp256k1 curve, but ECDSA or BLS works.
- I don't know of any Schnorr implementation that's efficient on the EVM [name=Matt Luongo]
- Multiple governing bodies for a specific asset ID.
- A way to verify redemptions. In particular, need to know:
- X amount of asset ID was burned to redeem,
- committing to Y Ethereum account.
## Possible issuance designs
We assume for the moment that all designs are implemented as a TZE. This would potentially enable some degree of custom issuance logic; we'd split the logic into "common to all ZSAs" (part of the TZE logic) and "per-ZSA" (provided in the TZE witness for each issuance or redemption transaction).
TODO: Rework how this is outlined; TZEs are conceptually just the implementation mechanism, but they do place some constraints on how issuance transactions actually work (mostly due to the UTXO model).
### Single-key == asset
An asset ID is derived from a single public key that controls the asset. Issuance and redemption transactions are authorized by a signature from this public key.
Full nodes would need to maintain:
- A list of currently-issued assets, and the amount of each that has been issued. Assets that have never been issued or never been redeemed could be elided.
Notes:
- This is the absolute simplest approach to design, specify, and implement.
- It is compatible with threshold multisignature schemes like FROST (where the multisignature public key is indistinguishable from a single key).
- It is _not_ compatible with Bitcoin-style multi-key multisignatures (where all keys involved in a signature are revealed).
- It does not support key rotation. Changing the public key changes the asset ID.
### Single-key registered to asset
When an asset ID is first "registered" (e.g. on first use), it can specify a single public key that controls the asset.
Full nodes would need to maintain an indefinitely-growing list of registered assets,
- It is compatible with threshold multisignature schemes like FROST.
- It could be extended to support key rotation, by having a "rotation" action that is authorized by the previous key.
### Multi-key == asset
Equivalent to "single-key == asset", but instead the asset ID is derived from a concatenated list of public keys.
- It could be extended to a threshold scheme by also including the required threshold in the asset ID derivation.
### Multi-key registered to asset
Equivalent to "single-key registered to asset", but instead registering a list of public keys.
- It could be extended to a threshold scheme by also including the required threshold in the asset ID derivation.
- The threshold could potentially be updateable.
Key rotation could be defined with a potentially-different authorization mechanism for individual keys:
- Issuance or redemption requires signatures from all keys on the list (or a subset of them if a threshold is specified).
- but rotating an individual key
### scriptpubkey registered to an asset:
We use a TZE to store {assetID: scriptpubkey} supporting two operations three operations:
1) register: creates a new assetID,scriptpubKey pair (either a random asset ID, or the hash of the scruptpubKey)
2) mint: issues x units of an asset with assID IFF the script pubkey is satisfied
3) update: for assetID ID, change the scriptpubkey from X to Y IFF x is satisfied.
### "Smart contract" registered to asset
We likely won't do this, but including it here as a design alternative.
TODO: Describe.