Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolving comments from ZIP Editors #96

Draft
wants to merge 3 commits into
base: zsa1
Choose a base branch
from
+17 −22
Draft

Resolving comments from ZIP Editors #96

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4b81d7c
initial commit
vivek-arte Jan 30, 2025
5a5b629
responding to Arya's comments
vivek-arte Jan 30, 2025
718077c
responding to str4d's comments, part 1
vivek-arte Jan 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions rendered/zip-0226.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -458,7 +458,7 @@ <h4>The
</section>
</section>
<section id="orchardzsa-transaction-structure"><h2><span class="section-heading">OrchardZSA Transaction Structure</span><span class="section-anchor"> <a rel="bookmark" href="#orchardzsa-transaction-structure"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The transaction format for v6 transactions is described in ZIP 230 <a id="footnote-reference-51" class="footnote_reference" href="#zip-0230">12</a>.</p>
<p>The transaction format for v6 transactions is described in ZIP 230 <a id="footnote-reference-51" class="footnote_reference" href="#zip-0230">13</a>.</p>
</section>
<section id="txid-digest"><h2><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The transaction digest algorithm defined in ZIP 244 <a id="footnote-reference-52" class="footnote_reference" href="#zip-0244">14</a> is modified by the OrchardZSA protocol to add a new branch for issuance information, along with modifications within the <code>orchard_digest</code> to account for the inclusion of the Asset Base. The details of these changes are described in this section, and highlighted using the <code>[UPDATED FOR ZSA]</code> or <code>[ADDED FOR ZSA]</code> text label. We omit the details of the sections that do not change for the OrchardZSA protocol.</p>
Expand Down Expand Up @@ -590,7 +590,7 @@ <h4>The
</section>
<section id="other-considerations"><h2><span class="section-heading">Other Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#other-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="transaction-fees"><h3><span class="section-heading">Transaction Fees</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-fees"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the OrchardZSA protocol upgrade, and are described in ZIP 230 <a id="footnote-reference-61" class="footnote_reference" href="#zip-0230-orchardzsa-fee-calculation">13</a>.</p>
<p>The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the OrchardZSA protocol upgrade, and are described in ZIP 227 <a id="footnote-reference-61" class="footnote_reference" href="#zip-0227-orchardzsa-fee-calculation">12</a>.</p>
</section>
<section id="backward-compatibility"><h3><span class="section-heading">Backward Compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>In order to have backward compatibility with the ZEC notes, we have designed the circuit to support both ZEC and OrchardZSA notes. As we specify above, there are three main reasons we can do this:</p>
Expand Down Expand Up @@ -709,19 +709,19 @@ <h4>The
</tr>
</tbody>
</table>
<table id="zip-0230" class="footnote">
<table id="zip-0227-orchardzsa-fee-calculation" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0230.html">ZIP 230: Version 6 Transaction Format</a></td>
<td><a href="zip-0227.html#orchardzsa-fee-calculation">ZIP 227: Issuance of Zcash Shielded Assets: OrchardZSA Fee Calculation</a></td>
</tr>
</tbody>
</table>
<table id="zip-0230-orchardzsa-fee-calculation" class="footnote">
<table id="zip-0230" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="zip-0230.html#orchardzsa-fee-calculation">ZIP 230: Version 6 Transaction Format: OrchardZSA Fee Calculation</a></td>
<td><a href="zip-0230.html">ZIP 230: Version 6 Transaction Format</a></td>
</tr>
</tbody>
</table>
Expand Down
10 changes: 4 additions & 6 deletions rendered/zip-0227.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -286,7 +286,7 @@
<ul>
<li>
<span class="math">\(\mathsf{asset\_desc}\)</span>
be the asset description, which includes any information pertaining to the issuance, and is a byte sequence of up to 512 bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.</li>
be the asset description, which includes any information pertaining to the issuance, and 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.</li>
<li>
<span class="math">\(\mathsf{ik}\)</span>
be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.</li>
Expand Down Expand Up @@ -366,9 +366,7 @@
<section id="issuance-action"><h3><span class="section-heading">Issuance Action</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-action"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An issuance action, <code>IssueAction</code>, is the instance of issuing a specific Custom Asset, and contains the following fields:</p>
<ul>
<li><code>assetDescSize</code>: the size of the Asset description, a number between
<span class="math">\(0\)</span>
and
<li><code>assetDescSize</code>: the size of the Asset description, a non-zero number that is at most
<span class="math">\(512\!\)</span>
.</li>
<li><code>asset_desc</code>: the Asset description, a byte string of up to 512 bytes as defined in the <a href="#specification-asset-identifier-asset-digest-and-asset-base">Specification: Asset Identifier, Asset Digest, and Asset Base</a> section.</li>
Expand Down Expand Up @@ -568,7 +566,7 @@
<span class="math">\(\mathsf{issued\_assets}\)</span>
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:</p>
<ul>
<li>The issuance state for the first block post the activation of the OrchardZSA protocol is the empty map.</li>
<li>The input issuance state for the activation block of the OrchardZSA protocol is the empty map.</li>
<li>The input issuance state for the first transaction of a block is the final issuance state of the immediately preceding block.</li>
<li>The input issuance state of each subsequent transaction in the block is the output issuance state of the immediately preceding transaction.</li>
<li>The final issuance state of a block is the output issuance state of the last transaction in the block.</li>
Expand Down Expand Up @@ -716,7 +714,7 @@
<li>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.</li>
</ul>
<section id="rationale-for-global-issuance-state"><h3><span class="section-heading">Rationale for Global Issuance State</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-global-issuance-state"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>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 <a id="footnote-reference-33" class="footnote_reference" href="#zip-0209">8</a>. 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.</p>
<p>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 <a id="footnote-reference-33" class="footnote_reference" href="#zip-0209">8</a>. 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 case we specify a consensus rule to reject the transaction or block.</p>
<p>We limit the total issuance of any Asset to a maximum of
<span class="math">\(\mathsf{MAX\_ISSUE}\!\)</span>
. This is a practical limit that also allows an issuer to issue the complete supply of an Asset in a single transaction.</p>
Expand Down
4 changes: 2 additions & 2 deletions zips/zip-0226.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -560,7 +560,7 @@ Other Considerations
Transaction Fees
----------------

The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the OrchardZSA protocol upgrade, and are described in ZIP 230 [#zip-0230-orchardzsa-fee-calculation]_.
The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the OrchardZSA protocol upgrade, and are described in ZIP 227 [#zip-0227-orchardzsa-fee-calculation]_.

Backward Compatibility
----------------------
Expand Down Expand Up @@ -603,8 +603,8 @@ References
.. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance <zip-0227.html#txid-digest-issuance>`_
.. [#zip-0227-sigdigest] `ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest <zip-0227.html#signature-digest>`_
.. [#zip-0227-authcommitment] `ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment <zip-0227.html#authorizing-data-commitment-issuance>`_
.. [#zip-0227-orchardzsa-fee-calculation] `ZIP 227: Issuance of Zcash Shielded Assets: OrchardZSA Fee Calculation <zip-0227.html#orchardzsa-fee-calculation>`_
.. [#zip-0230] `ZIP 230: Version 6 Transaction Format <zip-0230.html>`_
.. [#zip-0230-orchardzsa-fee-calculation] `ZIP 230: Version 6 Transaction Format: OrchardZSA Fee Calculation <zip-0230.html#orchardzsa-fee-calculation>`_
.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.html>`_
.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment <zip-0244.html#authorizing-data-commitment>`_
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_
Expand Down
13 changes: 5 additions & 8 deletions zips/zip-0227.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,7 +192,7 @@ From the Asset Digest, we derive a specific Asset Base within each shielded prot

Let

- $\mathsf{asset\_desc}$ be the asset description, which includes any information pertaining to the issuance, and is a byte sequence of up to 512 bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.
- $\mathsf{asset\_desc}$ be the asset description, which includes any information pertaining to the issuance, and 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.
- $\mathsf{ik}$ be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

Define
Expand Down Expand Up @@ -265,7 +265,7 @@ Issuance Action

An issuance action, ``IssueAction``, is the instance of issuing a specific Custom Asset, and contains the following fields:

- ``assetDescSize``: the size of the Asset description, a number between $0$ and $512$.
- ``assetDescSize``: the size of the Asset description, a non-zero number that is at most $512$.
- ``asset_desc``: the Asset description, a byte string of up to 512 bytes as defined in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
- ``vNotes``: an array of Issue Notes containing the unencrypted output notes to the recipients of the Asset.
- ``flagsIssuance``: a byte that stores the $\mathsf{finalize}$ boolean that defines whether the issuance of that specific Custom Asset is finalized or not.
Expand Down Expand Up @@ -377,7 +377,7 @@ Management of the Global Issuance State
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.
- The input issuance state for the activation block of the OrchardZSA protocol is the empty map.
- The input issuance state for the first transaction of a block is the final issuance state of the immediately preceding block.
- The input issuance state of each subsequent transaction in the block is the output issuance state of the immediately preceding transaction.
- The final issuance state of a block is the output issuance state of the last transaction in the block.
Expand All @@ -395,12 +395,11 @@ For every transaction:
- 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.
- If the transaction contains an Issuance Bundle, it MUST also contain at least one OrchardZSA Action Group.
- The issuance authorization signature, $\mathsf{issueAuthSig}$, MUST be a valid $\mathsf{IssueAuthSig}$ signature over $\mathsf{SigHash}$, i.e. $\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{ik}, \mathsf{SigHash}, \mathsf{issueAuthSig}) = 1$.
- For every issuance action description ($\mathsf{IssueAction}_\mathsf{i},\ 1 \leq i \leq \mathtt{nIssueActions}$) in the issuance bundle:

- It MUST be the case that $0 < \mathtt{assetDescSize} \leq 512$.
- It MUST be the case that $\mathsf{asset\_desc}$ is a string of length $\mathtt{assetDescSize}$ bytes.
- Every Issue Note in ``IssueAction`` MUST be a valid encoding of the $\mathsf{Note^{Issue}}$ type, and MUST encode the same $\mathsf{AssetBase}$.
- This $\mathsf{AssetBase}$ MUST satisfy the derivation from the issuance validating key and asset description described in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
- It MUST be the case that $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{final} \neq 1$.
Expand All @@ -417,8 +416,6 @@ For every transaction:
- The node MUST compute the note commitment, $\mathsf{cm}_{\mathsf{i,j}}$, as defined in the Note Structure and Commitment section of ZIP 226 [#zip-0226-notestructure]_.
- If $\mathsf{finalize} = 1$ within the ``flagsIssuance`` field of ``IssueAction``, the node MUST set $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{final} = 1$.
- If all the consensus rules are satisfied, the node MUST add the note commitments, $\mathsf{cm}_{\mathsf{i,j}}\ \forall\ \mathsf{i} \in \{1..\mathtt{nIssueActions}\},\ \mathsf{j} \in \{1..\mathtt{nNotes}\}$, to the Merkle tree of note commitments.
- (Replay Protection) If an issue bundle is present, the fees MUST be greater than zero.



Rationale
Expand All @@ -443,7 +440,7 @@ Rationale for Global Issuance State
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.
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.

We limit the total issuance of any Asset to a maximum of $\mathsf{MAX\_ISSUE}$.
This is a practical limit that also allows an issuer to issue the complete supply of an Asset in a single transaction.
Expand Down