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