ZIP 227: Replace asset_desc with its hash in AssetId
#975
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
daira
reviewed
Feb 6, 2025
| .. math:: \mathsf{ZSAValueBase}(\mathsf{AssetDigest_{AssetId}}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{AssetDigest_{AssetId}}) | ||
|
|
||
| where $\mathsf{GroupHash}^\mathbb{P}$ is defined as in [#protocol-concretegrouphashpallasandvesta]_. | ||
| This Asset Base is included in shielded notes within the shielded protocol. |
There was a problem hiding this comment.
Suggested change
| This Asset Base is included in shielded notes within the shielded protocol. | |
| This Asset Base is included in shielded notes within the shielded protocol. | |
| The definition of $\mathsf{ZSAValueBase}$ for the OrchardZSA protocol is given | |
| in `OrchardZSA Custom Assets`_. |
daira
reviewed
Feb 6, 2025
| the issuance. $\mathsf{asset\_desc}$ is a non-empty byte sequence of at most 512 bytes | ||
| which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later. | ||
| the issuance. $\mathsf{asset\_desc}$ is a non-empty byte sequence which SHOULD be a | ||
| well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later. |
There was a problem hiding this comment.
Suggested change
| well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later. | |
| well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later. [#Unicode]_ |
Also add in References:
.. [#Unicode] `Unicode 15.0.0. Unicode Consortium, September 2022. <https://www.unicode.org/versions/Unicode15.0.0/>`_
daira
reviewed
Feb 6, 2025
| @@ -454,15 +459,40 @@ The following is a list of rationale for different decisions made in the proposa | |||
|
|
|||
| - The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This keeps the issuance details and the Asset Identifiers consistent across multiple shielded pools. It also separates the issuance authority from the spend authority, allowing for the potential transfer of issuance authority without compromising the spend authority. | |||
| - The Custom Asset is described via a combination of the issuance validating key and an asset description string, to preclude the possibility of two different issuers creating colliding Custom Assets. | |||
| - The $\mathsf{asset\_desc}$ is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: | |||
| - We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack. | |||
There was a problem hiding this comment.
TODO(daira) file a separate issue: this is no longer needed as a separate rule, since we require at least one action from the same shielded protocol as the notes being issued.
daira
reviewed
Feb 6, 2025
|
|
||
| - If issuance transactions include the asset descriptions directly, wallets will discover | ||
| them during scanning. This is an "attractive nuisance" because it would result in | ||
| wallets being more likely to expose the asset description directly to users without any |
There was a problem hiding this comment.
Suggested change
| wallets being more likely to expose the asset description directly to users without any | |
| wallets being more likely to expose the asset description directly to users, without any |
daira
reviewed
Feb 6, 2025
| verification that the received asset has the value that a user might expect from that | ||
| description. By instead using a collision-resistant hash of an asset description, | ||
| wallets are forced to look up the corresponding asset description when a payment is | ||
| received in an unknown asset. That lookup can be mediated by a trusted party or common |
There was a problem hiding this comment.
Suggested change
| received in an unknown asset. That lookup can be mediated by a trusted party or common | |
| received in an unknown asset. That lookup can be mediated by a trusted party or a common |
PaulLaux
reviewed
Feb 12, 2025
There was a problem hiding this comment.
Yes, technically, this change is fully possible.
However, if we don't post the asset_desc to the blockchain at least once, we are burdening the issuer and users with keeping and maintaining a mapping from asset_desc to assetDescHash.
If this mapping is lost, it is not recoverable.
This will increase the burden and increase the operation cost of the issuer. Is this what we really want?
The alternative is to post it to the chain once and collect a proper fee for the storage.
Including an asset description in the first issuance but only an asset digest in later issuances seems practically similar to and better than including the asset description in a memo by convention. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.