From 4b81d7c84611554ddadb568149b41c3dba473e51 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Thu, 30 Jan 2025 15:33:13 +0530 Subject: [PATCH 1/6] initial commit --- rendered/zip-0227.html | 2 +- zips/zip-0227.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index a75aff283..0f292d211 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -568,7 +568,7 @@ \(\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:

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 8. 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.

+

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 8. 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.

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.

diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index df572af60..e8fb30dd6 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -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 ---------------------- @@ -603,8 +603,8 @@ References .. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance `_ .. [#zip-0227-sigdigest] `ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest `_ .. [#zip-0227-authcommitment] `ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment `_ +.. [#zip-0227-orchardzsa-fee-calculation] `ZIP 227: Issuance of Zcash Shielded Assets: OrchardZSA Fee Calculation `_ .. [#zip-0230] `ZIP 230: Version 6 Transaction Format `_ -.. [#zip-0230-orchardzsa-fee-calculation] `ZIP 230: Version 6 Transaction Format: OrchardZSA Fee Calculation `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index ea08bde8c..3035442f2 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -443,7 +443,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. From 718077c6218d4531074a9f319aa0b4100844b425 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Fri, 31 Jan 2025 16:48:08 +0530 Subject: [PATCH 3/6] responding to str4d's comments, part 1 --- rendered/zip-0227.html | 6 ++---- zips/zip-0227.rst | 9 +++------ 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 14854514e..8ea2aa0fa 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -286,7 +286,7 @@
  • \(\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.
    • + 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.
    • @@ -366,9 +366,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 +
    • 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.
      • diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 3035442f2..85b5ea648 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -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 @@ -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. @@ -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$. @@ -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 From d325d45f3f23e6d4cd65e0cf41f131b7e3510190 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 4 Feb 2025 20:56:21 +0530 Subject: [PATCH 4/6] working on str4d's comments, part 2 --- rendered/zip-0227.html | 86 ++++++++++++++++++++---------------------- rendered/zip-0230.html | 4 +- zips/zip-0227.rst | 16 ++++---- zips/zip-0230.rst | 2 - 4 files changed, 52 insertions(+), 56 deletions(-) diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 8ea2aa0fa..9859e38a8 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -308,7 +308,7 @@
      \(\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 30.

      + is defined as in 31.

      The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

      @@ -400,32 +400,25 @@

      Computation of ρ

      We define a function \(\mathsf{DeriveIssuedRho} : \mathbb{F}_{q_{\mathbb{P}}} \times \{0 .. 2^{32} - 1\} \times \{0 .. 2^{32} - 1\} \to \mathbb{F}_{q_{\mathbb{P}}}\) - as follows:

      -
      \(\mathsf{DeriveIssuedRho}(\mathsf{nf}, \mathsf{i_{A}}, \mathsf{i_{N}}) := \mathsf{ToBase}^{\mathsf{Rho}}(\mathsf{PRF}^{\mathsf{Rho}}(\mathsf{I2LEOSP}_{256}(\mathsf{nf}), [\mathtt{0x84}] \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{A}}) \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{N}}))),\)
      -

      where

      -
        -
      • - \(\mathsf{ToBase}^{\mathsf{Rho}} : \mathbb{B}^{512} \to \mathbb{F}_{q_{\mathbb{P}}}\) - is defined as - \(\mathsf{ToBase}^{\mathsf{Rho}}(x) := \mathsf{LEOS2IP}_{512}(x) \mod q_{\mathbb{P}}\) -
        • -
      • - \(\mathsf{PRF}^{\mathsf{Rho}} : \mathbb{B}^{256} \times \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}} \to \mathbb{B}^{512}\) - is defined as - \(\mathsf{PRF}^{\mathsf{Rho}}(\mathsf{k},t) := \textsf{BLAKE2b-512}(\mathtt{"ZSA\_IssueNoteRho"}, \mathsf{k} \| t)\) -
        • -
      + for Issue Notes in the OrchardZSA Protocol as follows:

      +
      \(\mathsf{DeriveIssuedRho}(\mathsf{nf}, \mathsf{i_{A}}, \mathsf{i_{N}}) := \mathsf{ToBase}^{\mathsf{Orchard}}(\mathsf{PRF}^{\mathsf{expand}}(\mathsf{I2LEOSP}_{256}(\mathsf{nf}), [\mathtt{0x84}] \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{A}}) \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{N}}))),\)
      +

      where + \(\mathsf{ToBase}^{\mathsf{Orchard}}\) + is defined in §4.2.3 of the protocol specification 27, and + \(\mathsf{PRF}^{\mathsf{expand}}\) + is defined in §5.4.2 of the protocol specification 30.

      The \(\text{ρ}\) field of an Issue Note is computed as

      \(\text{ρ} := \mathsf{DeriveIssuedRho}(\mathsf{nf}_{1,1}, \mathsf{index_{Action}}, \mathsf{index_{Note}}),\)

      where \(\mathsf{nf}_{1,1}\) - is the nullifier of the first Note in the first Action of the OrchardZSA Bundle of the transaction, + is the nullifier of the first Note in the first Action in the first Action Group of the OrchardZSA Bundle of the transaction, \(\mathsf{index_{Action}}\) - is the index of the Issuance Action in the Issuance Bundle, and + is the zero-based index of the Issuance Action in the Issuance Bundle, and \(\mathsf{index_{Note}}\) - is the index of the Issue Note in the Issuance Action.

      + is the zero-based index of the Issue Note in the Issuance Action.

      +

      NOTE: This implicitly requires that there always is an Action Group in the OrchardZSA bundle of the transaction. This is enforced by the sixth consensus rule in the Specification: Consensus Rule Changes section.

      Issuance Protocol

      The issuer program performs the following operations:

      @@ -497,7 +490,7 @@ \((\mathsf{d}, \mathsf{pk}_{\mathsf{d}})\) is set to the default diversified payment address (i.e. the diversified payment address with diversifier index \(0\!\) - ) derived from the all-zero Orchard spending key using the algorithm specified in §4.2.3 of the protocol specification 27. This corresponds to a 43 byte u8 array with the following entries:

      + ) derived from the all-zero Orchard spending key using the algorithm specified in §4.2.3 of the protocol specification 27. This corresponds to a 43 byte u8 array with the following entries:

      [
   204, 54, 96, 25, 89, 33, 59, 107, 12, 219, 150, 167, 92, 23, 195, 166, 104, 169, 127, 13, 106,
   140, 92, 225, 100, 165, 24, 234, 155, 169, 165, 14, 167, 81, 145, 253, 134, 27, 15, 241, 14,
@@ -581,12 +574,13 @@
         
      Specification: Consensus Rule Changes 
      
             
      For every transaction:
      
             
        
+                
      • The nActionGroupsOrchard field MUST have a value of either 0 or 1 and the nAGExpiryHeight field MUST have a value of 0.
        • 
                 
      • The output issuance state of the transaction MUST be initialized to be the same as the input issuance state,
                     \(\mathsf{issued\_assets}_{\mathsf{OUT}} = \mathsf{issued\_assets}_{\mathsf{IN}}\!\)
                 .
        • 
                 
      • The
                     \(\mathsf{assetBurn}\)
-                 set MUST satisfy the consensus rules specified in ZIP 226 12.
        • 
+                 set MUST satisfy the consensus rules specified in ZIP 226 12.
                 
      • It MUST be the case that for all
                     \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}\!\)
                 ,
@@ -600,10 +594,10 @@
                 .
        • 
                 
      • Let
                     \(\mathsf{SigHash}\)
-                 be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification 28 with the modifications described in ZIP 226 13, using
+                 be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification 28 with the modifications described in ZIP 226 13, 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
@@ -620,11 +614,6 @@
                         
      • 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
@@ -677,7 +666,7 @@
                                 .
        • 
                                 
      • The node MUST compute the note commitment,
                                     \(\mathsf{cm}_{\mathsf{i,j}}\!\)
-                                , as defined in the Note Structure and Commitment section of ZIP 226 11.
        • 
+                                , as defined in the Note Structure and Commitment section of ZIP 226 11.
                             
      
                         
                         
    • If
@@ -690,7 +679,6 @@
                 
    • 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

    @@ -714,7 +702,7 @@
  • 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.

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 8. 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.

+

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 8. 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.

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.

@@ -727,7 +715,7 @@
  • By using the \(\mathsf{finalize}\) - boolean and the burning mechanism defined in 10, issuers can control the supply production of any Asset associated to their issuer keys. For example, + boolean and the burning mechanism defined in 10, issuers can control the supply production of any Asset associated to their issuer keys. For example,
    • by setting \(\mathsf{finalize} = 1\) @@ -760,7 +748,7 @@

TxId Digest - Issuance

-

This section details the construction of the subtree of hashes in the transaction digest that corresponds to issuance transaction data. Details of the overall changes to the transaction digest due to the OrchardZSA protocol can be found in ZIP 226 13. As in ZIP 244 19, the digests are all personalized BLAKE2b-256 hashes, and in cases where no elements are available for hashing, a personalized hash of the empty byte array is used.

+

This section details the construction of the subtree of hashes in the transaction digest that corresponds to issuance transaction data. Details of the overall changes to the transaction digest due to the OrchardZSA protocol can be found in ZIP 226 13. As in ZIP 244 19, the digests are all personalized BLAKE2b-256 hashes, and in cases where no elements are available for hashing, a personalized hash of the empty byte array is used.

A new issuance transaction digest algorithm is defined that constructs the subtree of the transaction digest tree of hashes for the issuance portion of a transaction. Each branch of the subtree will correspond to a specific subset of issuance transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

issuance_digest
 ├── issue_actions_digest
@@ -796,7 +784,7 @@
                         
In case the transaction has no Issue Notes, ''issue_notes_digest'' is:

                         
BLAKE2b-256("ZTxIdIAcNoteHash", [])

                         
T.5a.i.1: recipient 

-                            
This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification 31.

+                            
This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification 32.

                         

                         
T.5a.i.2: value 

                             
Note value encoded as little-endian 8-byte representation of 64-bit unsigned integer (e.g. u64 in Rust) raw value.

@@ -830,7 +818,7 @@

Signature Digest

-

The per-input transaction digest algorithm to generate the signature digest in ZIP 244 20 is modified so that a signature digest is produced for each transparent input, each Sapling input, each Orchard action, and additionally for each Issuance Action. For Issuance Actions, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.

+

The per-input transaction digest algorithm to generate the signature digest in ZIP 244 20 is modified so that a signature digest is produced for each transparent input, each Sapling input, each Orchard action, and additionally for each Issuance Action. For Issuance Actions, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.

The overall structure of the hash is as follows. We highlight the changes for the OrchardZSA protocol via the [ADDED FOR ZSA] text label, and we omit the descriptions of the sections that do not change for the OrchardZSA protocol:

signature_digest
 ├── header_digest
@@ -845,14 +833,14 @@
 S.3: sapling_digest         (32-byte hash output)
 S.4: orchard_digest         (32-byte hash output)
 S.5: issuance_digest        (32-byte hash output)  [ADDED FOR ZSA]
-

The personalization field remains the same as in ZIP 244 19.

+

The personalization field remains the same as in ZIP 244 19.

S.5: issuance_digest

Identical to that specified for the transaction identifier.

Authorizing Data Commitment - Issuance

-

This section covers the construction of the subtree of hashes in the authorizing data commitment that corresponds to issuance transaction data. Details of the overall changes to the authorizing data commitment due to the OrchardZSA protocol can be found in ZIP 226 14.

+

This section covers the construction of the subtree of hashes in the authorizing data commitment that corresponds to issuance transaction data. Details of the overall changes to the authorizing data commitment due to the OrchardZSA protocol can be found in ZIP 226 14.

A.4: issuance_auth_digest

In the case that Issuance Actions are present, this is a BLAKE2b-256 hash of the field encoding of the issueAuthSig field of the transaction:

A.4a: issueAuthSig            (field encoding bytes)
@@ -863,7 +851,7 @@

OrchardZSA Fee Calculation

-

In addition to the parameters defined in the Fee calculation section of ZIP 317 21, the OrchardZSA protocol upgrade defines the following additional parameters:

+

In addition to the parameters defined in the Fee calculation section of ZIP 317 21, the OrchardZSA protocol upgrade defines the following additional parameters:

@@ -917,7 +905,7 @@
-

The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 32 and the global state. They are defined in the Fee calculation section of ZIP 317 21. Note that +

The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 33 and the global state. They are defined in the Fee calculation section of ZIP 317 21. Note that \(nOrchardActions\!\) , that is used in the computation of \(logical\_actions\!\) @@ -947,7 +935,7 @@

Security and Privacy Considerations

Displaying Asset Identifier information to users

-

Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the Specification: Asset Identifier, Asset Digest, and Asset Base section.

+

Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the Specification: Asset Identifier, Asset Digest, and Asset Base section. Wallets also need to

Issuance Key Compromise

The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended:

@@ -962,7 +950,7 @@

Bridging Assets

-

For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 10. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

+

For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 10. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

Other Considerations

@@ -976,7 +964,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

Fee Structures

-

The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317, and is described in ZIP 230 18.

+

The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317, and is described in ZIP 230 18.

Test Vectors

@@ -1226,10 +1214,18 @@ - +
+ + + +
30Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.2: Pseudo Random Functions
+ + + + @@ -1237,7 +1233,7 @@
31 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.8: Group Hash into Pallas and Vesta
- + @@ -1245,7 +1241,7 @@
3132 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.6.4.2: Orchard Raw Payment Addresses
- + diff --git a/rendered/zip-0230.html b/rendered/zip-0230.html index 0373bee5f..c10ed734c 100644 --- a/rendered/zip-0230.html +++ b/rendered/zip-0230.html @@ -218,7 +218,7 @@ - + @@ -440,7 +440,7 @@ - + diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 85b5ea648..fce930216 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -293,21 +293,20 @@ The detailed encoding of the issuance bundle as a part of the V6 transaction for Computation of ρ ---------------- -We define a function $\mathsf{DeriveIssuedRho} : \mathbb{F}_{q_{\mathbb{P}}} \times \{0 .. 2^{32} - 1\} \times \{0 .. 2^{32} - 1\} \to \mathbb{F}_{q_{\mathbb{P}}}$ as follows: +We define a function $\mathsf{DeriveIssuedRho} : \mathbb{F}_{q_{\mathbb{P}}} \times \{0 .. 2^{32} - 1\} \times \{0 .. 2^{32} - 1\} \to \mathbb{F}_{q_{\mathbb{P}}}$ for Issue Notes in the OrchardZSA Protocol as follows: -.. math:: \mathsf{DeriveIssuedRho}(\mathsf{nf}, \mathsf{i_{A}}, \mathsf{i_{N}}) := \mathsf{ToBase}^{\mathsf{Rho}}(\mathsf{PRF}^{\mathsf{Rho}}(\mathsf{I2LEOSP}_{256}(\mathsf{nf}), [\mathtt{0x84}] \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{A}}) \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{N}}))), +.. math:: \mathsf{DeriveIssuedRho}(\mathsf{nf}, \mathsf{i_{A}}, \mathsf{i_{N}}) := \mathsf{ToBase}^{\mathsf{Orchard}}(\mathsf{PRF}^{\mathsf{expand}}(\mathsf{I2LEOSP}_{256}(\mathsf{nf}), [\mathtt{0x84}] \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{A}}) \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{N}}))), -where - -- $\mathsf{ToBase}^{\mathsf{Rho}} : \mathbb{B}^{512} \to \mathbb{F}_{q_{\mathbb{P}}}$ is defined as $\mathsf{ToBase}^{\mathsf{Rho}}(x) := \mathsf{LEOS2IP}_{512}(x) \mod q_{\mathbb{P}}$ -- $\mathsf{PRF}^{\mathsf{Rho}} : \mathbb{B}^{256} \times \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}} \to \mathbb{B}^{512}$ is defined as $\mathsf{PRF}^{\mathsf{Rho}}(\mathsf{k},t) := \textsf{BLAKE2b-512}(\mathtt{"ZSA\_IssueNoteRho"}, \mathsf{k} \| t)$ +where $\mathsf{ToBase}^{\mathsf{Orchard}}$ is defined in §4.2.3 of the protocol specification [#protocol-orchardkeycomponents]_, and $\mathsf{PRF}^{\mathsf{expand}}$ is defined in §5.4.2 of the protocol specification [#protocol-concreteprfs]_. The $\text{ρ}$ field of an Issue Note is computed as .. math:: \text{ρ} := \mathsf{DeriveIssuedRho}(\mathsf{nf}_{1,1}, \mathsf{index_{Action}}, \mathsf{index_{Note}}), -where $\mathsf{nf}_{1,1}$ is the nullifier of the first Note in the first Action of the OrchardZSA Bundle of the transaction, $\mathsf{index_{Action}}$ is the index of the Issuance Action in the Issuance Bundle, and $\mathsf{index_{Note}}$ is the index of the Issue Note in the Issuance Action. +where $\mathsf{nf}_{1,1}$ is the nullifier of the first Note in the first Action in the first Action Group of the OrchardZSA Bundle of the transaction, $\mathsf{index_{Action}}$ is the zero-based index of the Issuance Action in the Issuance Bundle, and $\mathsf{index_{Note}}$ is the zero-based index of the Issue Note in the Issuance Action. +**NOTE:** This implicitly requires that there always is an Action Group in the OrchardZSA bundle of the transaction. +This is enforced by the sixth consensus rule in the `Specification: Consensus Rule Changes`_ section. Issuance Protocol ----------------- @@ -391,6 +390,7 @@ Specification: Consensus Rule Changes For every transaction: +- The ``nActionGroupsOrchard`` field MUST have a value of either ``0`` or ``1`` and the ``nAGExpiryHeight`` field MUST have a value of ``0``. - The output issuance state of the transaction MUST be initialized to be the same as the input issuance state, $\mathsf{issued\_assets}_{\mathsf{OUT}} = \mathsf{issued\_assets}_{\mathsf{IN}}$. - 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}$. @@ -693,6 +693,7 @@ Displaying Asset Identifier information to users ------------------------------------------------ Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. +Wallets also need to Issuance Key Compromise ----------------------- @@ -769,6 +770,7 @@ References .. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.2.3: Orchard Key Components `_ .. [#protocol-sighash] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.10: SIGHASH Transaction Hashing `_ .. [#protocol-constants] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants `_ +.. [#protocol-concreteprfs] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.2: Pseudo Random Functions `_ .. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ .. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ .. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1: Transaction Encoding and Consensus `_ diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index 5d24ae7e9..df7948497 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -172,7 +172,6 @@ Transaction Format | **OrchardZSA Transaction Fields** | +------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ |``varies`` |``nActionGroupsOrchard`` |``compactSize`` |The number of Action Group descriptions in ``vActionGroupsOrchard``. | -| | | |This MUST have a value of either ``0`` or ``1``. | +------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ |``varies`` |``vActionGroupsOrchard`` |``ActionGroupDescription[nActionGroupsOrchard]`` |A sequence of Action Group descriptions, encoded as per the | | | | |`OrchardZSA Action Group Description`_. | @@ -297,7 +296,6 @@ The OrchardZSA Action Group Description is encoded in a transaction as an instan +------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ |``4`` |``nAGExpiryHeight`` |``uint32`` |A block height (in the future) after which the Actions of the | | | | |Action Group become invalid and should be rejected by consensus. | -| | | |This MUST have a value of ``0``. | +------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ |``64 * nActionsOrchard`` |``vSpendAuthSigsOrchard`` |``byte[64 * nActionsOrchard]`` |Authorizing signatures for each Action of the Action Group in a | | | | |transaction. | From c3a8cc993d8853730eee0c26f4bcef35e7c7b405 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 4 Feb 2025 23:15:02 +0530 Subject: [PATCH 5/6] specifying order of note commitment addition --- rendered/zip-0226.html | 145 ++++++++++++++++++++++------------------- rendered/zip-0227.html | 20 ++++-- zips/zip-0226.rst | 3 + zips/zip-0227.rst | 16 ++++- 4 files changed, 110 insertions(+), 74 deletions(-) diff --git a/rendered/zip-0226.html b/rendered/zip-0226.html index 4d892a6ae..eddcf989c 100644 --- a/rendered/zip-0226.html +++ b/rendered/zip-0226.html @@ -50,18 +50,18 @@ . This Asset Identifier maps to an Asset Base \(\mathsf{AssetBase}\) that is stored in OrchardZSA notes. These terms are formally defined in ZIP 227 5.

-

The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description 18 31 is preserved across Assets (see the Orchard Binding Signature 21), and by extension the balance of an Orchard transaction. That is, the sum of all the +

The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description 19 32 is preserved across Assets (see the Orchard Binding Signature 22), and by extension the balance of an Orchard transaction. That is, the sum of all the \(\mathsf{value^{net}}\) from each Action Description, computed as \(\mathsf{value^{old}} - \mathsf{value^{new}}\!\) , must be balanced only with respect to the same Asset Identifier. This is especially important since we will allow different Action Descriptions to transfer notes of different Asset Identifiers, where the overall balance is checked without revealing which (or how many distinct) Assets are being transferred.

-

As was initially proposed by Jack Grigg and Daira-Emma Hopwood 32 33, we propose to make this happen by changing the value base point, +

As was initially proposed by Jack Grigg and Daira-Emma Hopwood 33 34, we propose to make this happen by changing the value base point, \(\mathcal{V}^{\mathsf{Orchard}}\!\) , in the Homomorphic Pedersen Commitment that derives the value commitment, \(\mathsf{cv^{net}}\!\) , of the net value in an Orchard Action.

-

Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset Identifiers for a given shielded protocol used in a transaction. We propose to make the Asset Base an auxiliary input to the proof for each Action statement 23, represented already as a point on the Pallas curve. The circuit then should check that the same Asset Base is used in the old note commitment and the new note commitment 28, and as the base point in the value commitment 27. This ensures (1) that the input and output notes are of the same Asset Base, and (2) that only Actions with the same Asset Base will balance out in the Orchard binding signature.

-

In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 20 for Custom Assets, as we need to enforce that the +

Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset Identifiers for a given shielded protocol used in a transaction. We propose to make the Asset Base an auxiliary input to the proof for each Action statement 24, represented already as a point on the Pallas curve. The circuit then should check that the same Asset Base is used in the old note commitment and the new note commitment 29, and as the base point in the value commitment 28. This ensures (1) that the input and output notes are of the same Asset Base, and (2) that only Actions with the same Asset Base will balance out in the Orchard binding signature.

+

In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 21 for Custom Assets, as we need to enforce that the \(\mathsf{AssetBase}\) of the output note of that Split Action is the output of a valid \(\mathsf{ZSAValueBase}\) @@ -95,7 +95,7 @@

Note Structure & Commitment

-

An OrchardZSA note differs from an Orchard note 17 by additionally including the Asset Base, +

An OrchardZSA note differs from an Orchard note 18 by additionally including the Asset Base, \(\mathsf{AssetBase}\!\) . So an OrchardZSA note is a tuple \((\mathsf{d}, \mathsf{pk_d}, \mathsf{v}, \mathsf{AssetBase}, \text{ρ}, \text{ψ}, \mathsf{rcm})\!\) @@ -103,12 +103,12 @@

  • \(\mathsf{AssetBase} : \mathbb{P}^*\) - is the unique element of the Pallas group 29 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 7, a valid group element that is not the identity and is not + is the unique element of the Pallas group 30 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 7, a valid group element that is not the identity and is not \(\bot\!\) . The byte representation of the Asset Base is defined as \(\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase})\!\) .
    • -
  • The remaining terms are as defined in §3.2 of the protocol specification 17.
    • +
  • The remaining terms are as defined in §3.2 of the protocol specification 18.

Note that the above assumes a canonical encoding, which is true for the Pallas group, but may not hold for future shielded protocols.

Let @@ -117,7 +117,7 @@

\(\mathsf{Note^{OrchardZSA}} := \mathbb{B}^{[\ell_{\mathsf{d}}]} \times \mathsf{KA}^{\mathsf{Orchard}}.\mathsf{Public} \times \{0 .. 2^{\ell_{\mathsf{value}}} - 1\} \times \mathbb{P}^* \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathsf{NoteCommit^{Orchard}.Trapdoor},\)

where \(\mathbb{P}^*\) - is the Pallas group excluding the identity element, and the other types are as defined in §3.2 of the protocol specification 17.

+ is the Pallas group excluding the identity element, and the other types are as defined in §3.2 of the protocol specification 18.

Non-normative note: The type and definition of the OrchardZSA note reflect that it is a tuple of all the components of an Orchard note, with the addition of the Asset Base into the tuple.

We define the note commitment scheme \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) @@ -135,9 +135,9 @@

where \(\mathbb{P}, \ell_{\mathbb{P}}, q_{\mathbb{P}}\) - are as defined for the Pallas curve 29, and where + are as defined for the Pallas curve 30, and where \(\mathsf{NoteCommit^{Orchard}.\{Trapdoor, Output\}}\) - are as defined in the Zcash protocol specification 19. This note commitment scheme is instantiated using the Sinsemilla Commitment 28 as follows:

+ are as defined in the Zcash protocol specification 20. This note commitment scheme is instantiated using the Sinsemilla Commitment 29 as follows:

\(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase}) := \begin{cases} \mathsf{NoteCommit^{Orchard}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}), &\!\!\text{if } \mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}} \\ @@ -156,21 +156,22 @@ \(\mathsf{repr}_{\mathbb{P}}\) and \(\mathsf{GroupHash}^{\mathbb{P}}\) - are as defined for the Pallas curve 29, + are as defined for the Pallas curve 30, \(\ell^{\mathsf{Orchard}}_{\mathsf{base}}\) - is as defined in §5.3 25, and + is as defined in §5.3 26, and \(\mathsf{I2LEBSP}\) - is as defined in §5.1 24 of the Zcash protocol specification.

-

The nullifier is generated in the same manner as in the Orchard protocol 22.

-

The OrchardZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 30. It consists of

+ is as defined in §5.1 25 of the Zcash protocol specification.

+

The nullifier is generated in the same manner as in the Orchard protocol 23.

+

The OrchardZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 31. It consists of

\((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[\ell_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)
+

We make explicit the order of addition of the note commitments to the note commitment tree in ZIP 227 9.

Rationale for Note Commitment

In the OrchardZSA protocol, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\!\) , differs from the Orchard note commitment \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - 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 28 allows us to add the Asset Base as a final recursive step.

-

The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 26. OrchardZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

+ 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 29 allows us to add the Asset Base as a final recursive step.

+

The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 27. OrchardZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

\(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{g_d}), \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d}), \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase}) \in \mathsf{NoteCommit^{Orchard}.Output}\)

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 OrchardZSA notes.

@@ -191,20 +192,20 @@ respectively,
  • \(\mathsf{AssetBase_{AssetId}}\) - is defined in ZIP 227 5, and
    • + is defined in ZIP 227 5, and
  • \(\mathcal{R}^{\mathsf{Orchard}} := \mathsf{GroupHash^{\mathbb{P}}}(\texttt{“z.cash:Orchard-cv”}, \texttt{“r”})\!\) , as in the Orchard protocol.

    • For ZEC, we define \(\mathsf{AssetBase}_{\mathsf{AssetId}} := \mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 4. As such + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 4. As such \(\mathsf{ValueCommit^{Orchard}_{rcv}}(\mathsf{v})\) - as defined in 4 is used as + as defined in 4 is used as \(\mathsf{ValueCommit^{OrchardZSA}_{rcv}}(\mathcal{V}^{\mathsf{Orchard}}, \mathsf{v})\) here.

    Rationale for Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 27 to perform the value commitment, with fixed base points +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 28 to perform the value commitment, with fixed base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) @@ -246,12 +247,12 @@ \(\mathsf{assetBurn}\!\) . -

    The other consensus rule changes for the OrchardZSA protocol are specified in ZIP 227 8.

    +

    The other consensus rule changes for the OrchardZSA protocol are specified in ZIP 227 8.

    Note: The transparent protocol will not be changed with this ZIP to adapt to a multiple Asset structure. This means that unless future consensus rules changes do allow it, unshielding will not be possible for Custom Assets.

    Value Balance Verification

    -

    In order to verify the balance of the different Assets, the verifier MUST perform a similar process as for the Orchard protocol 21, with the addition of the burn information.

    +

    In order to verify the balance of the different Assets, the verifier MUST perform a similar process as for the Orchard protocol 22, with the addition of the burn information.

    For a total of \(n\) Actions in a transfer, the prover MUST still sign the SIGHASH transaction hash using the binding signature key @@ -274,7 +275,7 @@ the set of indices of Actions that are related to Custom Assets.

    The right hand side of the value balance verification equation can be expanded to:

    \(((\sum_{i \in S_{\mathsf{ZEC}}} \mathsf{cv}^{\mathsf{net}}_i) + (\sum_{j \in S_{\mathsf{CA}}} \mathsf{cv}^{\mathsf{net}}_j)) - ([\mathsf{v^{balanceOrchard}}]\,\mathcal{V}^{\mathsf{Orchard}} + [0]\,\mathcal{R}^{\mathsf{Orchard}}) - (\sum_{(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}} [\mathsf{v}]\,\mathsf{AssetBase} + [0]\,\mathcal{R}^{\mathsf{Orchard}})\)
    -

    This equation contains the balance check of the Orchard protocol 21. With ZSA, transfer Actions for Custom Assets must also be balanced across Asset Bases. All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer. Custom Assets can be burnt, the mechanism for which reveals the amount and identifier of the Asset being burnt, within the +

    This equation contains the balance check of the Orchard protocol 22. With ZSA, transfer Actions for Custom Assets must also be balanced across Asset Bases. All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer. Custom Assets can be burnt, the mechanism for which reveals the amount and identifier of the Asset being burnt, within the \(\mathsf{assetBurn}\) set. As such, for a correctly constructed transaction, we will get \(\sum_{j \in S_{\mathsf{CA}}} \mathsf{cv}^{\mathsf{net}}_j - \sum_{(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}} [\mathsf{v}]\,\mathsf{AssetBase} = \sum_{j \in S_{\mathsf{CA}}} [\mathsf{rcv}^{\mathsf{net}}_j]\,\mathcal{R}^{\mathsf{Orchard}}\!\) @@ -323,11 +324,11 @@ \(\mathbb{F}_{q_{\mathbb{P}}}\!\) , \(\mathcal{K}^{\mathsf{Orchard}}\) - is the Orchard Nullifier Base as defined in 22, and + is the Orchard Nullifier Base as defined in 23, and \(\mathcal{L}^{\mathsf{Orchard}} := \mathsf{GroupHash^{\mathbb{P}}}(\texttt{“z.cash:Orchard”}, \texttt{“L”})\!\) .

    Rationale for Split Notes

    -

    In the Orchard protocol, since each Action represents an input and an output, the transaction that wants to send one input to multiple outputs must have multiple inputs. The Orchard protocol gives dummy spend notes 20 to the Actions that have not been assigned input notes.

    +

    In the Orchard protocol, since each Action represents an input and an output, the transaction that wants to send one input to multiple outputs must have multiple inputs. The Orchard protocol gives dummy spend notes 21 to the Actions that have not been assigned input notes.

    The Orchard technique requires modification for the OrchardZSA protocol with multiple Asset Identifiers, as the output note of the split Actions cannot contain just any Asset Base. We must enforce it to be an actual output of a GroupHash computation (in fact, we want it to be of the same Asset Base as the original input note, but the binding signature takes care that the proper balancing is performed). Without this enforcement the prover could input a multiple (or linear combination) of an existing Asset Base, and thereby attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    Therefore, for Custom Assets we enforce that every input note to an OrchardZSA Action must be proven to exist in the set of note commitments in the note commitment tree. We then enforce this real note to be “unspendable” in the sense that its value will be zeroed in split Actions and the nullifier will be randomized, making the note not spendable in the specific Action. Then, the proof itself ensures that the output note is of the same Asset Base as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof (aka the \(\mathsf{split\_flag}\) @@ -336,8 +337,8 @@

    Circuit Statement

    -

    Every OrchardZSA Action statement is closely similar to the Orchard Action statement 23, except for a few additions that ensure the security of the Asset Identifier system. We detail these changes below.

    -

    All modifications in the Circuit are detailed in 34.

    +

    Every OrchardZSA Action statement is closely similar to the Orchard Action statement 24, except for a few additions that ensure the security of the Asset Identifier system. We detail these changes below.

    +

    All modifications in the Circuit are detailed in 35.

    Asset Base Equality

    The following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetBase}\!\) @@ -346,12 +347,12 @@

  • The Asset Base, \(\mathsf{AssetBase_{AssetId}}\!\) , for the note is witnessed once, as an auxiliary input.
    • -
  • In the Old note commitment integrity constraint in the Orchard Action statement 23, +
  • In the Old note commitment integrity constraint in the Orchard Action statement 24, \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{g_d^{old}}), \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d^{old}}), \mathsf{v^{old}}, \text{ρ}^{\mathsf{old}}, \text{ψ}^{\mathsf{old}})\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{g_d^{old}}), \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d^{old}}), \mathsf{v^{old}}, \text{ρ}^{\mathsf{old}}, \text{ψ}^{\mathsf{old}}, \mathsf{AssetBase_{AssetId}})\!\) .
    • -
  • In the New note commitment integrity constraint in the Orchard Action statement 23, +
  • In the New note commitment integrity constraint in the Orchard Action statement 24, \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{g_d^{new}}), \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d^{new}}), \mathsf{v^{new}}, \text{ρ}^{\mathsf{new}}, \text{ψ}^{\mathsf{new}})\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{g_d^{new}}), \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d^{new}}), \mathsf{v^{new}}, \text{ρ}^{\mathsf{new}}, \text{ψ}^{\mathsf{new}}, \mathsf{AssetBase_{AssetId}})\!\) @@ -453,15 +454,15 @@

    The

    • Backwards Compatibility with ZEC Notes

    -

    The input note in the old note commitment integrity check must either include an Asset Base (OrchardZSA note) or not (pre-ZSA Orchard note). If the note is a pre-ZSA Orchard note, the note commitment is computed in the original Orchard fashion 19. If the note is an OrchardZSA note, the note commitment is computed as defined in the Note Structure & Commitment section.

    +

    The input note in the old note commitment integrity check must either include an Asset Base (OrchardZSA note) or not (pre-ZSA Orchard note). If the note is a pre-ZSA Orchard note, the note commitment is computed in the original Orchard fashion 20. If the note is an OrchardZSA note, the note commitment is computed as defined in the Note Structure & Commitment section.

    OrchardZSA Transaction Structure

    -

    The transaction format for v6 transactions is described in ZIP 230 13.

    +

    The transaction format for v6 transactions is described in ZIP 230 14.

    TxId Digest

    -

    The transaction digest algorithm defined in ZIP 244 14 is modified by the OrchardZSA protocol to add a new branch for issuance information, along with modifications within the orchard_digest to account for the inclusion of the Asset Base. The details of these changes are described in this section, and highlighted using the [UPDATED FOR ZSA] or [ADDED FOR ZSA] text label. We omit the details of the sections that do not change for the OrchardZSA protocol.

    +

    The transaction digest algorithm defined in ZIP 244 15 is modified by the OrchardZSA protocol to add a new branch for issuance information, along with modifications within the orchard_digest to account for the inclusion of the Asset Base. The details of these changes are described in this section, and highlighted using the [UPDATED FOR ZSA] or [ADDED FOR ZSA] text label. We omit the details of the sections that do not change for the OrchardZSA protocol.

    txid_digest

    A BLAKE2b-256 hash of the following values:

    T.1: header_digest       (32-byte hash output)
@@ -469,13 +470,13 @@ 
    The
 T.3: sapling_digest      (32-byte hash output)
 T.4: orchard_digest      (32-byte hash output)  [UPDATED FOR ZSA]
 T.5: issuance_digest     (32-byte hash output)  [ADDED FOR ZSA]
    -

    The personalization field remains the same as in ZIP 244 14.

    +

    The personalization field remains the same as in ZIP 244 15.

    T.4: orchard_digest

    When OrchardZSA Actions Groups are present in the transaction, this digest is a BLAKE2b-256 hash of the following values:

    T.4a: orchard_action_groups_digest   (32-byte hash output)          [ADDED FOR ZSA]
 T.4b: orchard_zsa_burn_digest        (32-byte hash output)          [ADDED FOR ZSA]
 T.4c: valueBalanceOrchard            (64-bit signed little-endian)
    -

    The personalization field of this hash is the same as in ZIP 244 14

    +

    The personalization field of this hash is the same as in ZIP 244 15

    "ZTxIdOrchardHash"

    In the case that the transaction has no OrchardZSA Action Groups, orchard_digest is

    BLAKE2b-256("ZTxIdOrchardHash", [])
    @@ -490,7 +491,7 @@

    The

    The personalization field of this hash is set to:

    "ZTxIdOrcActGHash"
    T.4a.i: orchard_actions_compact_digest
    -

    A BLAKE2b-256 hash of the subset of OrchardZSA Action information intended to be included in an updated version of the ZIP-307 16 CompactBlock format for all OrchardZSA Actions belonging to the Action Group. For each Action, the following elements are included in the hash:

    +

    A BLAKE2b-256 hash of the subset of OrchardZSA Action information intended to be included in an updated version of the ZIP-307 17 CompactBlock format for all OrchardZSA Actions belonging to the Action Group. For each Action, the following elements are included in the hash:

    T.4a.i.1 : nullifier            (field encoding bytes)
 T.4a.i.2 : cmx                  (field encoding bytes)
 T.4a.i.3 : ephemeralKey         (field encoding bytes)
@@ -505,7 +506,7 @@ 
    The
                             
    "ZTxIdOrcActMHash"
    T.4a.iii: orchard_actions_noncompact_digest
    -

    A BLAKE2b-256 hash of the remaining subset of OrchardZSA Action information not intended for inclusion in an updated version of the the ZIP 307 16 CompactBlock format, for all OrchardZSA Actions belonging to the Action Group. For each Action, the following elements are included in the hash:

    +

    A BLAKE2b-256 hash of the remaining subset of OrchardZSA Action information not intended for inclusion in an updated version of the the ZIP 307 17 CompactBlock format, for all OrchardZSA Actions belonging to the Action Group. For each Action, the following elements are included in the hash:

    T.4a.iii.1 : cv                    (field encoding bytes)
 T.4a.iii.2 : rk                    (field encoding bytes)
 T.4a.iii.3 : encCiphertext[596..]  (post-memo suffix of field encoding)  [UPDATED FOR ZSA]
@@ -535,15 +536,15 @@ 
    The

    T.5: issuance_digest

    -

    The details of the computation of this value are in ZIP 227 9.

    +

    The details of the computation of this value are in ZIP 227 10.

    Signature Digest

    -

    The details of the changes to this algorithm are in ZIP 227 10.

    +

    The details of the changes to this algorithm are in ZIP 227 11.

    Authorizing Data Commitment

    -

    The transaction digest algorithm defined in ZIP 244 15 which commits to the authorizing data of a transaction is modified by the OrchardZSA protocol to have the structure specified in this section. There is a new branch added for issuance information, along with modifications within the orchard_auth_digest to account for the presence of Action Groups.

    +

    The transaction digest algorithm defined in ZIP 244 16 which commits to the authorizing data of a transaction is modified by the OrchardZSA protocol to have the structure specified in this section. There is a new branch added for issuance information, along with modifications within the orchard_auth_digest to account for the presence of Action Groups.

    We highlight the changes for the OrchardZSA protocol via the [UPDATED FOR ZSA] or [ADDED FOR ZSA] text label, and we omit the descriptions of the sections that do not change for the OrchardZSA protocol:

    auth_digest
 ├── transparent_scripts_digest
@@ -575,7 +576,7 @@ 
    The

    A.4: issuance_auth_digest

    -

    The details of the computation of this value are in ZIP 227 11.

    +

    The details of the computation of this value are in ZIP 227 12.

    @@ -590,7 +591,7 @@

    The

    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 227 12.

    +

    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 13.

    Backward Compatibility

    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:

    @@ -685,10 +686,18 @@

    The

    3233 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1: Transaction Encoding and Consensus
    varies nActionGroupsOrchard compactSizeThe number of Action Group descriptions in vActionGroupsOrchard. This MUST have a value of either 0 or 1.The number of Action Group descriptions in vActionGroupsOrchard.
    varies4 nAGExpiryHeight uint32A block height (in the future) after which the Actions of the Action Group become invalid and should be rejected by consensus. This MUST have a value of 0.A block height (in the future) after which the Actions of the Action Group become invalid and should be rejected by consensus.
    64 * nActionsOrchard
    - +
    + + + +
    9ZIP 227: Issuance of Zcash Shielded Assets: Addition to the Note Commitment Tree
    + + + + @@ -696,7 +705,7 @@

    The

    10 ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance
    - + @@ -704,7 +713,7 @@

    The

    1011 ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest
    - + @@ -712,7 +721,7 @@

    The

    1112 ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment
    - + @@ -720,7 +729,7 @@

    The

    1213 ZIP 227: Issuance of Zcash Shielded Assets: OrchardZSA Fee Calculation
    - + @@ -728,7 +737,7 @@

    The

    1314 ZIP 230: Version 6 Transaction Format
    - + @@ -736,7 +745,7 @@

    The

    1415 ZIP 244: Transaction Identifier Non-Malleability
    - + @@ -744,7 +753,7 @@

    The

    1516 ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment
    - + @@ -752,7 +761,7 @@

    The

    1617 ZIP 307: Light Client Protocol for Payment Detection
    - + @@ -760,7 +769,7 @@

    The

    1718 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes
    - + @@ -768,7 +777,7 @@

    The

    1819 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.7: Action Transfers and their Descriptions
    - + @@ -776,7 +785,7 @@

    The

    1920 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.8: Commitment
    - + @@ -784,7 +793,7 @@

    The

    2021 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.8.3: Dummy Notes (Orchard)
    - + @@ -792,7 +801,7 @@

    The

    2122 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.14: Balance and Binding Signature (Orchard)
    - + @@ -800,7 +809,7 @@

    The

    2223 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.16: Computing ρ values and Nullifiers
    - + @@ -808,7 +817,7 @@

    The

    2324 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.18.4: Action Statement (Orchard)
    - + @@ -816,7 +825,7 @@

    The

    2425 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.1: Integers, Bit Sequences, and Endianness
    - + @@ -824,7 +833,7 @@

    The

    2526 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants
    - + @@ -832,7 +841,7 @@

    The

    2627 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.1.9: Sinsemilla hash function
    - + @@ -840,7 +849,7 @@

    The

    2728 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
    - + @@ -848,7 +857,7 @@

    The

    2829 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.4: Sinsemilla commitments
    - + @@ -856,7 +865,7 @@

    The

    2930 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.6: Pallas and Vesta
    - + @@ -864,7 +873,7 @@

    The

    3031 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.5: Encodings of Note Plaintexts and Memo Fields
    - + @@ -872,7 +881,7 @@

    The

    3132 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus
    - + @@ -880,7 +889,7 @@

    The

    3233 User-Defined Assets and Wrapped Assets
    - + @@ -888,7 +897,7 @@

    The

    3334 Comment on Generalized Value Commitments
    - + diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 9859e38a8..2bd1f57e5 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -474,7 +474,7 @@ \(\mathsf{IssueAuthSig}\) signature scheme. The signature is then added to the issuance bundle. -

    Note: that the commitment is not included in the IssuanceAction itself. As explained below, it is computed later by the validators and added to the note commitment tree.

    +

    Note: The note commitment is not included in the IssuanceAction itself. As explained below, it is computed later by the validators and added to the note commitment tree.

    Specification: Reference Notes and Global Issuance State

    @@ -676,10 +676,22 @@ . -
  • 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.
    • +

    Addition to the Note Commitment Tree

    +

    If the transaction is added to the block chain, the note commitments of all the OrchardZSA Notes and the Issue Notes in the transaction are added to the note commitment tree of the associated treestate. The order of addition to the tree is as specified below:

    +
      +
    • For each Action Group in the OrchardZSA Bundle: +
        +
      • For every Action in the Action Group, append the note commitment of every new OrchardZSA note in the Action to the note commitment tree.
        • +
      +
      • +
    • For each Issue Action in the Issue Bundle: +
        +
      • For every Issue Note in the Issue Action, append the note commitment of the Issue Note to the note commitment tree.
        • +
      +
      • +
    +

    Rationale

    The following is a list of rationale for different decisions made in the proposal:

    diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index e8fb30dd6..2ca10f5b1 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -139,6 +139,8 @@ It consists of .. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[\ell_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]}) +We make explicit the order of addition of the note commitments to the note commitment tree in ZIP 227 [#zip-0227-note-commitment-order]_. + Rationale for Note Commitment ````````````````````````````` @@ -600,6 +602,7 @@ References .. [#zip-0227-specification-global-issuance-state] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Global Issuance State `_ .. [#zip-0227-assetidentifier] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Asset Identifier `_ .. [#zip-0227-consensus] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Consensus Rule Changes `_ +.. [#zip-0227-note-commitment-order] `ZIP 227: Issuance of Zcash Shielded Assets: Addition to the Note Commitment Tree `_ .. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance `_ .. [#zip-0227-sigdigest] `ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest `_ .. [#zip-0227-authcommitment] `ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment `_ diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index fce930216..4df09182d 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -332,7 +332,7 @@ For the ``IssueBundle``: - sign the SIGHASH transaction hash with the issuance authorizing key, $\mathsf{isk}$, using the $\mathsf{IssueAuthSig}$ signature scheme. The signature is then added to the issuance bundle. -**Note:** that the commitment is not included in the ``IssuanceAction`` itself. As explained below, it is computed later by the validators and added to the note commitment tree. +**Note:** The note commitment is not included in the ``IssuanceAction`` itself. As explained below, it is computed later by the validators and added to the note commitment tree. Specification: Reference Notes and Global Issuance State ======================================================== @@ -415,8 +415,20 @@ For every transaction: - It MUST be the case that $\mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} + \mathsf{v} \leq \mathsf{MAX\_ISSUE}$, where $\mathsf{v}$ is the value of $\mathsf{note}_{\mathsf{j}}$. The node then MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} + \mathsf{v}$. - 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. +Addition to the Note Commitment Tree +------------------------------------ + +If the transaction is added to the block chain, the note commitments of all the OrchardZSA Notes and the Issue Notes in the transaction are added to the note commitment tree of the associated treestate. +The order of addition to the tree is as specified below: + +- For each Action Group in the OrchardZSA Bundle: + + - For every Action in the Action Group, append the note commitment of every new OrchardZSA note in the Action to the note commitment tree. + +- For each Issue Action in the Issue Bundle: + + - For every Issue Note in the Issue Action, append the note commitment of the Issue Note to the note commitment tree. Rationale ========= From 30125b92a1810633b04a1905b78f8106a50f8503 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 4 Feb 2025 23:44:20 +0530 Subject: [PATCH 6/6] update based on review --- rendered/zip-0226.html | 2 +- rendered/zip-0227.html | 6 +++--- zips/zip-0226.rst | 2 +- zips/zip-0227.rst | 5 ++--- 4 files changed, 7 insertions(+), 8 deletions(-) diff --git a/rendered/zip-0226.html b/rendered/zip-0226.html index eddcf989c..5a48dc80b 100644 --- a/rendered/zip-0226.html +++ b/rendered/zip-0226.html @@ -164,7 +164,7 @@

    The nullifier is generated in the same manner as in the Orchard protocol 23.

    The OrchardZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 31. It consists of

    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[\ell_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)
    -

    We make explicit the order of addition of the note commitments to the note commitment tree in ZIP 227 9.

    +

    The explicit order of addition of the note commitments to the note commitment tree is specified in ZIP 227 9.

    Rationale for Note Commitment

    In the OrchardZSA protocol, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\!\) diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 2bd1f57e5..d8171df05 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -410,9 +410,9 @@

    The \(\text{ρ}\) field of an Issue Note is computed as

    -
    \(\text{ρ} := \mathsf{DeriveIssuedRho}(\mathsf{nf}_{1,1}, \mathsf{index_{Action}}, \mathsf{index_{Note}}),\)
    +
    \(\text{ρ} := \mathsf{DeriveIssuedRho}(\mathsf{nf}_{0,0}, \mathsf{index_{Action}}, \mathsf{index_{Note}}),\)

    where - \(\mathsf{nf}_{1,1}\) + \(\mathsf{nf}_{0,0}\) is the nullifier of the first Note in the first Action in the first Action Group of the OrchardZSA Bundle of the transaction, \(\mathsf{index_{Action}}\) is the zero-based index of the Issuance Action in the Issuance Bundle, and @@ -947,7 +947,7 @@

    Security and Privacy Considerations

    Displaying Asset Identifier information to users

    -

    Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the Specification: Asset Identifier, Asset Digest, and Asset Base section. Wallets also need to

    +

    Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the Specification: Asset Identifier, Asset Digest, and Asset Base section.

    Issuance Key Compromise

    The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended:

    diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index 2ca10f5b1..99403c73a 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -139,7 +139,7 @@ It consists of .. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[\ell_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]}) -We make explicit the order of addition of the note commitments to the note commitment tree in ZIP 227 [#zip-0227-note-commitment-order]_. +The explicit order of addition of the note commitments to the note commitment tree is specified in ZIP 227 [#zip-0227-note-commitment-order]_. Rationale for Note Commitment ````````````````````````````` diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 4df09182d..1234ef77c 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -301,9 +301,9 @@ where $\mathsf{ToBase}^{\mathsf{Orchard}}$ is defined in §4.2.3 of the protocol The $\text{ρ}$ field of an Issue Note is computed as -.. math:: \text{ρ} := \mathsf{DeriveIssuedRho}(\mathsf{nf}_{1,1}, \mathsf{index_{Action}}, \mathsf{index_{Note}}), +.. math:: \text{ρ} := \mathsf{DeriveIssuedRho}(\mathsf{nf}_{0,0}, \mathsf{index_{Action}}, \mathsf{index_{Note}}), -where $\mathsf{nf}_{1,1}$ is the nullifier of the first Note in the first Action in the first Action Group of the OrchardZSA Bundle of the transaction, $\mathsf{index_{Action}}$ is the zero-based index of the Issuance Action in the Issuance Bundle, and $\mathsf{index_{Note}}$ is the zero-based index of the Issue Note in the Issuance Action. +where $\mathsf{nf}_{0,0}$ is the nullifier of the first Note in the first Action in the first Action Group of the OrchardZSA Bundle of the transaction, $\mathsf{index_{Action}}$ is the zero-based index of the Issuance Action in the Issuance Bundle, and $\mathsf{index_{Note}}$ is the zero-based index of the Issue Note in the Issuance Action. **NOTE:** This implicitly requires that there always is an Action Group in the OrchardZSA bundle of the transaction. This is enforced by the sixth consensus rule in the `Specification: Consensus Rule Changes`_ section. @@ -705,7 +705,6 @@ Displaying Asset Identifier information to users ------------------------------------------------ Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section. -Wallets also need to Issuance Key Compromise -----------------------
    3435 Modifications to the Orchard circuit for the OrchardZSA Protocol