# Notes on the ZSA asset naming problem

A ZSA asset has three kinds of identifiers:

* $\mathsf{AssetId} = (\mathsf{ik}, \mathsf{asset\_desc})$ - the canonical reference for an asset.
* $\mathsf{AssetDigest_\mathsf{AssetId}}$ - a short commitment derived from $\mathsf{AssetId}$.
* $\mathsf{AssetBase}_\mathsf{AssetId}$ - the representative of an asset within a specific shielded pool (currently only the Orchard pool). Derived from $\mathsf{AssetDigest}$.

When a user's wallet receives a non-ZEC shielded note, it learns $\mathsf{AssetBase}$ for that note. To learn more about the asset type, it may need to:
* perform a lookup from $\mathsf{AssetBase}$ to $\mathsf{AssetDigest}$, in order to link notes received across distinct shielded pools as being the same asset type (not currently relevant).
* perform a lookup from $\mathsf{AssetDigest}$ to $\mathsf{AssetId}$ in order to learn `asset_desc`.

We expect that there could be several ways that ZSAs could be used, that may require distinct wallet UX (or other kinds of UX distinctions that need to be clear and comprehensible for users), for example:

* Well-known assets for which wallets could plausibly have an allowlist.
* Such a whitelist would likely use $\mathsf{AssetBase}$ directly as a key (one for each pool that supports ZSAs), and include $\mathsf{AssetId}$ somewhere on the value side of the map, to encode the above protocol lookups alongside the semantic lookup.
* Assets that potentially could be well-known in future, but are currently obscure.
* Assets that represent the same logical / semantic asset, but have concretely different $\mathsf{AssetId}$s. For example:
* Two assets that have the same `asset_desc` but different issuers.
* Two different bridges for the same asset (e.g. Litecoin - something sufficiently obscure that it's unlikely to be in the well-known asset list).
* Daira-Emma wants this case not to exist.
* Someone attempting to phish an existing asset.
* Two assets that have different `asset_desc` (and maybe different issuers, but that's irrelevant here), but represent the same logical asset.
* Two different bridges for the same asset, where they choose to encode their bridge identifier in `asset_desc`.
* Sme subset of `asset_desc` may still identify that these are intended to be the same logical asset, but if `asset_desc` is an arbitrary string from a wallet UX level, then the wallet can't make this distinction.
* Assets that are closer to being per-use (e.g. an NFT series).
* etc.

Daira-Emma's desirables:

* When creating a new well-known asset, there is a way to choose the `asset_desc` that avoids collisions, so that if I see two identical `asset_descs` with different `ik`, either this is a reissue/key rotation of "the same" asset in a loose sense, or an attack. I.e. *accidental* collisions don't happen.
* As a developer or power user, I don't have to rely on a centralized whitelist in order to figure out what organisation probably issued an asset.

Daira-Emma's "simplest thing that could possibly work" proposal:

An asset_desc is a (semantic asset name, domain name of issuer) pair. It is considered rude to use someone else's domain name for your asset.

Alternatively, consider using [tag URIs](https://en.wikipedia.org/wiki/Tag_URI_scheme). This disambiguates in the case where control of the domain changes.

str4d suggestion: if the note plaintext encoded $\mathsf{AssetDigest}$ instead of $\mathsf{AssetBase}$, then _in a future where multiple shielded pools support ZSAs_ wallets would not need to perform an $\mathsf{AssetBase}$ to $\mathsf{AssetDigest}$ lookup in order to determine the full set of distinct asset types that it holds spend authority for.
* Daira-Emma reasons that $\mathsf{AssetDigest}$ could potentially be shortened to 256 bits (i.e. output of BLAKE2b-256 instead of BLAKE2b-512). In that case, note plaintexts would be no larger than when storing $\mathsf{AssetBase}$.
* TODO: Write out original rationale for a 512-bit $\mathsf{AssetDigest}$, and then potentially why it is safe to shorten.