ZSA Protocol: Transfer, Issuance and Burn: ZIPs 226, 227, and 230 #960

vivek-arte · 2024-11-13T16:17:00Z

This PR continues the discussion on the ZSA ZIPs from the merged #854.

It contains any recent changes to the following ZIPs:

ZIP 226: Transfer and Burn of Zcash Shielded Assets
ZIP 227: Issuance of Zcash Shielded Assets
ZIP 230: Version 6 Transaction Format

Note that the target issue for the ZSA ZIPs is #618.

This pull request contains changes that resolve the following issues related to ZSAs:

[ZIP 227] Attack against Spendability due to ρ potentially not being unique in an issuance action #955
[ZIP 227] Should there be a limit on total issuance of an asset lower than 2^96? #956
[ZIPs 226 and 227] The relative ordering of accesses to issuedAssets(AssetBase).balance for issuance and burning is undefined #957
[ZIP 227] Finalization should occur immediately, not at the next block boundary #958
ZSAs: Addition of reference notes to the global issuance state to prepare for ZSA Swaps #969

This merges in the changes from upstream post the merging of our PR#854 to upstream.

This makes a few changes to the usage of terminology such as the use of the capital MUST terms in the specification.

…ock boundary (#81) This completes the changes needed to make sure the finalization comes into effect immediately. A part of this was done in #75, the remainder is covered here. This solves zcash#958.

This removes the tables with the encoding of the issuance action description and issuance bundle from ZIP 227. This same material has been included in ZIP 230 as part of the V6 transaction format, and thus it is simpler to have it defined in a single place. ZIP 227 has been updated with references to the relevant sections of ZIP 230 where necessary.

zips/zip-0226.rst

zips/zip-0227.rst

This changes the encoding of the transaction format to add Action Groups to TxV6. The motivation is to avoid the need of a further transaction format upgrade while introducing Asset Swaps for ZSAs in a subsequent upgrade. It also makes some consistency improvements to the ZIPs, and updates outdated references.

This PR adds an explicit upper bound of $$2^{64} - 1$$ to the total supply of issued assets in the specification of ZIP 227. It also does a major rewrite of the consensus rule changes, bringing them more in line with the protocol specification, and using MUST terminology where necessary. Furthermore, these changes make explicit the order of processing fields within a transaction, and the order of updates to the issuance state.

This PR moves the description of the fees required for OrchardZSA issuance and transfer to ZIP 227. This is a more contextual place to have the material, compared to ZIP 230, which specifies the V6 transaction format.

This updates the `zsa1` branch with the changes from upstream, and resolves conflicts.

This adds the explicit specification (with types) for the Issue Note.

This defines a new function and uses it to derive the value of the $\rho$ field in Issue Notes. It also updates the consensus rules accordingly and makes some typographical improvements.

This simplifies the encoding of the $\mathsf{nf}$ argument in the computation of $\rho$, so that it avoids the double use of $\mathsf{LEBS2OSP(I2LEOSP(...))}$.

This adjusts the type and specification of the notes to mirror the implementation, specifically that the Asset Base occurs in the middle of the tuple, and not at the end.

This adds the specification of reference notes, which are to be created at the time of first issuance of a Custom Asset. Alongside, we also update the issuance state and consensus rules to account for these changes.

arya2 · 2025-01-14T22:29:37Z

zips/zip-0227.rst

+The issuance state, that is, the $\mathsf{issued\_assets}$ map, MUST be updated by a node during the processing of any transaction that contains burn information, or an issuance bundle.
+The issuance state is chained as follows:
+
+- The issuance state for the first block post the activation of the OrchardZSA protocol is the empty map.


Nitpick: The first block post the activation of the OrchardZSA protocol is the second block that could have issuance or burn actions.

Suggested change

- The issuance state for the first block post the activation of the OrchardZSA protocol is the empty map.

- The input issuance state for the activation block of the OrchardZSA protocol is the empty map.

arya2 · 2025-01-14T22:32:14Z

zips/zip-0227.rst

+- The $\mathsf{assetBurn}$ set MUST satisfy the consensus rules specified in ZIP 226 [#zip-0226-assetburn]_.
+- It MUST be the case that for all $(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}$, $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} \geq \mathsf{v}$. The node then MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase})$ prior to processing the issuance bundle in the following manner. For every $(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{AssetBurn}$, $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} - \mathsf{v}$.
+- Let $\mathsf{SigHash}$ be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification [#protocol-sighash]_ with the modifications described in ZIP 226 [#zip-0226-txiddigest]_, using $\mathsf{SIGHASH\_ALL}$.
+- If the transaction contains an Issuance Bundle, it MUST also contain at least one OrchardZSA Action.


Should this currently be at least one, or exactly one?

arya2 · 2025-01-14T22:38:50Z

zips/zip-0227.rst

+It is necessary to ensure that the balance of any issued Custom Asset never becomes negative within a shielded pool, along the lines of ZIP 209 [#zip-0209]_. 
+However, unlike for the shielded ZEC pools, there is no individual transaction field that directly corresponds to both the issued and burnt amounts for a given Asset.
+Therefore, we require that all nodes maintain a record of the current amount in circulation for every issued Custom Asset, and update this record based on the issuance and burn transactions processed. 
+This allows for efficient detection of balance violations for any Asset, in which scenario we specify a consensus rule to reject the transaction or block.


Nitpick/Optional:

Suggested change

This allows for efficient detection of balance violations for any Asset, in which scenario we specify a consensus rule to reject the transaction or block.

This allows for efficient detection of balance violations for any Asset, in which case we specify a consensus rule to reject the transaction or block.

vivek-arte added 3 commits November 11, 2024 09:46

Catching up with upstream (#77)

2e1c16b

This merges in the changes from upstream post the merging of our PR#854 to upstream.

Some smaller updates (#79)

5416929

This makes a few changes to the usage of terminology such as the use of the capital MUST terms in the specification.

[ZSAs] Ensuring Finalization occurs immediately rather than at the bl…

bb6b791

…ock boundary (#81) This completes the changes needed to make sure the finalization comes into effect immediately. A part of this was done in #75, the remainder is covered here. This solves zcash#958.

vivek-arte mentioned this pull request Nov 13, 2024

[ZIP 227] Finalization should occur immediately, not at the next block boundary #958

Open