Skip to content

Commit

Permalink
Handling additional suggestions from PR#649 and PR#628 (#19)
Browse files Browse the repository at this point in the history
Making updates based on pending reviews from
[PR#649](zcash#649) and
[PR#628](zcash#628).
  • Loading branch information
vivek-arte committed May 25, 2023
1 parent c1c465d commit 3554adb
Show file tree
Hide file tree
Showing 2 changed files with 25 additions and 15 deletions.
27 changes: 18 additions & 9 deletions zip-0226.html
Expand Up @@ -122,7 +122,7 @@
<ul>
<li>
<span class="math">\(\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P}*\)</span>
is the unique element of the Pallas group <a id="footnote-reference-19" class="footnote_reference" href="#protocol-pallasandvesta">15</a> that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 <a id="footnote-reference-20" class="footnote_reference" href="#zip-0227">6</a>. The byte representation of the Asset Base is defined as
is the unique element of the Pallas group <a id="footnote-reference-19" class="footnote_reference" href="#protocol-pallasandvesta">15</a> that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 <a id="footnote-reference-20" class="footnote_reference" href="#zip-0227">6</a>, a valid non-bottom group element that is not the identity. The byte representation of the Asset Base is defined as
<span class="math">\(\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})\)</span>
.</li>
</ul>
Expand Down Expand Up @@ -168,7 +168,7 @@
in that for Custom Assets, the Asset Base will be added as an input to the commitment computation. In the case where the Asset is the ZEC Asset, the commitment is computed identically to the Orchard note commitment, without making use of the ZEC Asset Base as an input. As we will see, the nested structure of the Sinsemilla-based commitment <a id="footnote-reference-29" class="footnote_reference" href="#protocol-concretesinsemillacommit">18</a> allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.</p>
<p>The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function <a id="footnote-reference-30" class="footnote_reference" href="#protocol-concretesinsemillahash">17</a>. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:</p>
<div class="math">\(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output}\)</div>
<p>This definition can be viewed as a hypernym of the Orchard note commitment, and will allow maintaining a single commitment instance for the note commitment, which will be used both for pre-ZSA Orchard and ZSA notes.</p>
<p>This definition can be viewed as a generalization of the Orchard note commitment, and will allow maintaining a single commitment instance for the note commitment, which will be used both for pre-ZSA Orchard and ZSA notes.</p>
</section>
</section>
<section id="value-commitment"><h3><span class="section-heading">Value Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#value-commitment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
Expand Down Expand Up @@ -264,7 +264,7 @@
</ul>
</section>
<section id="value-commitment-correctness"><h4><span class="section-heading">Value Commitment Correctness</span><span class="section-anchor"> <a rel="bookmark" href="#value-commitment-correctness"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base, as represented in the notes:</p>
<p>The following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base:</p>
<ul>
<li>The fixed-base multiplication constraints between the value and the value base point of the value commitment,
<span class="math">\(\mathsf{cv}\)</span>
Expand All @@ -275,11 +275,11 @@
</ul>
</section>
<section id="asset-identifier-consistency-for-split-actions"><h4><span class="section-heading">Asset Identifier Consistency for Split Actions</span><span class="section-anchor"> <a rel="bookmark" href="#asset-identifier-consistency-for-split-actions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The following constraints must be added to prevent senders from changing the Asset Base for the output note in a Split Action:</p>
<p>Senders must not be able to change the Asset Base for the output note in a Split Action. We do this via the following constraints:</p>
<ul>
<li>
<dl>
<dt>The Value Commitment Integrity should be changed</dt>
<dt>The Value Commitment Integrity should be changed:</dt>
<dd>
<ul>
<li>Replace the input note value by a generic value,
Expand All @@ -296,11 +296,18 @@
<dt>Add a boolean <code>split_flag</code> variable as an auxiliary witness. This variable is to be activated <code>split_flag = 1</code> if the Action in question has a Split Input and <code>split_flag = 0</code> if the Action is actually spending an input note:</dt>
<dd>
<ul>
<li>If <code>split_flag = 1</code> then set
<li>If
<span class="math">\(\texttt{split_flag} = 1\)</span>
then constrain
<span class="math">\(\mathsf{v}' = 0\)</span>
otherwise
otherwise constrain
<span class="math">\(\mathsf{v}'=\mathsf{v^{old}}\)</span>
from the auxiliary input.</li>
<li>If
<span class="math">\(\texttt{split_flag} = 1\)</span>
then constrain
<span class="math">\(\mathsf{v^{old}} \neq 0\)</span>
.</li>
</ul>
</dd>
</dl>
Expand Down Expand Up @@ -339,7 +346,9 @@
<span class="math">\(\psi' = \psi^{old}\)</span>
. (Otherwise
<span class="math">\(\psi'\)</span>
should be sampled randomly.)</li>
should be sampled uniformly at random on
<span class="math">\(\mathbb{F}_{q_{\mathbb{P}}}\)</span>
.)</li>
</ul>
</dd>
</dl>
Expand Down Expand Up @@ -376,7 +385,7 @@
<ol type="1">
<li>We require that
<span class="math">\(\forall (\mathsf{AssetBase},\mathsf{v^{AssetBase}}) \in \mathsf{assetBurn}\ ,\ \mathsf{AssetBase} \neq \mathcal{V}^{\mathsf{Orchard}}\)</span>
. That is, Native Assets are not allowed to be burnt.</li>
. That is, ZEC or TAZ is not allowed to be burnt.</li>
<li>We require that for every
<span class="math">\(\forall (\mathsf{AssetBase},\mathsf{v^{AssetBase}}) \in \mathsf{assetBurn}\ ,\ \mathsf{v^{AssetBase}} \neq 0\)</span>
.</li>
Expand Down
13 changes: 7 additions & 6 deletions zip-0226.rst
Expand Up @@ -102,7 +102,7 @@ Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e.
A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the Asset Base, :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}}})`,
where

- :math:`\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P}*` is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 [#zip-0227]_. The byte representation of the Asset Base is defined as :math:`\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})`.
- :math:`\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P}*` is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 [#zip-0227]_, a valid non-bottom group element that is not the identity. The byte representation of the Asset Base is defined as :math:`\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})`.

Specifically, we define the note commitment scheme :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}` as follows:

Expand Down Expand Up @@ -233,7 +233,7 @@ Circuit Statement
Every *ZSA Action statement* is closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset Identifier system. We detail these changes below.

Asset Base Equality
'''''''''''''''''''''''''
'''''''''''''''''''

The following constraints must be added to ensure that the input and output note are of the same :math:`\mathsf{AssetBase}`:

Expand All @@ -244,20 +244,21 @@ The following constraints must be added to ensure that the input and output note
Value Commitment Correctness
''''''''''''''''''''''''''''

The following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base, as represented in the notes:
The following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base:

- The fixed-base multiplication constraints between the value and the value base point of the value commitment, :math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two.
- The witness to the value base point (as defined in the `asset base`_ equation) is the auxiliary input :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}`.

Asset Identifier Consistency for Split Actions
''''''''''''''''''''''''''''''''''''''''''''''

The following constraints must be added to prevent senders from changing the Asset Base for the output note in a Split Action:
Senders must not be able to change the Asset Base for the output note in a Split Action. We do this via the following constraints:

- The Value Commitment Integrity should be changed
- The Value Commitment Integrity should be changed:
- Replace the input note value by a generic value, :math:`\mathsf{v}'`, as :math:`\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}`
- Add a boolean ``split_flag`` variable as an auxiliary witness. This variable is to be activated ``split_flag = 1`` if the Action in question has a Split Input and ``split_flag = 0`` if the Action is actually spending an input note:
- If ``split_flag = 1`` then set :math:`\mathsf{v}' = 0` otherwise :math:`\mathsf{v}'=\mathsf{v^{old}}` from the auxiliary input.
- If :math:`\texttt{split_flag} = 1` then constrain :math:`\mathsf{v}' = 0` otherwise constrain :math:`\mathsf{v}'=\mathsf{v^{old}}` from the auxiliary input.
- If :math:`\texttt{split_flag} = 1` then constrain :math:`\mathsf{v^{old}} \neq 0`.
- The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes):
- Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^{old}}` to the anchor :math:`\mathsf{rt^{Orchard}}`.
- The Nullifier Integrity will be changed to prevent the identification of notes
Expand Down

0 comments on commit 3554adb

Please sign in to comment.