Issue Note 
+ The maximum total supply of any issued Custom Asset is denoted by the constant
+ \(\mathsf{MAX\_ISSUE} := 2^{64} - 1\!\)
+ .
+ An Issue Note represents that a value
+ \(\mathsf{v} : \{0 .. \mathsf{MAX\_ISSUE}\}\)
+ of a specific Custom Asset is issued to a recipient. An Issue Note is a tuple
+ \((\mathsf{d}, \mathsf{pk_d}, \mathsf{v}, \mathsf{AssetBase}, \text{ρ}, \mathsf{rseed})\!\)
+ , where:
+
+ -
+ \(\mathsf{d}: \mathbb{B}^{[\ell_{\mathsf{d}}]}\)
+ is the diversifier of the recipient's shielded payment address, as in §3.2 of the protocol specification .
+ -
+ \(\mathsf{pk_d}: \mathsf{KA}^{\mathsf{Orchard}}.\mathsf{Public}\)
+ is the recipient's diversified transmission key, as in §3.2 of the protocol specification .
+ -
+ \(\mathsf{v} : \{0 .. \mathsf{MAX\_ISSUE}\}\)
+ is the value of the note in terms of the number of Asset tokens.
+ -
+ \(\mathsf{AssetBase}: \mathbb{P}^*\)
+ is the Asset Base corresponding to the ZSA being issued in the Issue Note.
+ -
+ \(\text{ρ}: \mathbb{F}_{q_{\mathbb{P}}}\)
+ is used to derive the nullifier of the note, and is computed as in Computation of ρ.
+ -
+ \(\mathsf{rseed}: \mathbb{B}^{[\mathbb{Y}^{32}]}\)
+ MUST be sampled uniformly at random by the issuer.
+
+ The complete encoding of these fields into an IssueNote is defined in ZIP 230 .
+ Computation of ρ
+ TO BE FILLED
+
- Issuance Action Description
+ 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
@@ -349,7 +380,7 @@
The
\(\mathsf{finalize}\)
boolean is set by the Issuer to signal that there will be no further issuance of the specific Custom Asset. As we will see in Specification: Consensus Rule Changes, transactions that attempt to issue further amounts of a Custom Asset that has previously been finalized will be rejected.
- The complete encoding of these fields into an IssueAction is defined in ZIP 230 .
+ The complete encoding of these fields into an IssueAction is defined in ZIP 230 .
We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the note commitment tree as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers.
Issuance Bundle
@@ -367,7 +398,7 @@
\(\mathsf{isk}\!\)
, that validates the issuance.
- The issuance bundle is added within the transaction format as a new bundle. The detailed encoding of the issuance bundle as a part of the V6 transaction format is defined in ZIP 230 .
+ The issuance bundle is added within the transaction format as a new bundle. The detailed encoding of the issuance bundle as a part of the V6 transaction format is defined in ZIP 230 .
Issuance Protocol
The issuer program performs the following operations:
@@ -495,7 +526,7 @@
.
The
\(\mathsf{assetBurn}\)
- set MUST satisfy the consensus rules specified in ZIP 226 .
+ set MUST satisfy the consensus rules specified in ZIP 226 .
It MUST be the case that for all
\((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}\!\)
,
@@ -509,7 +540,7 @@
.
Let
\(\mathsf{SigHash}\)
- be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification with the modifications described in ZIP 226 , using
+ be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification with the modifications described in ZIP 226 , using
\(\mathsf{SIGHASH\_ALL}\!\)
.
The issuance authorization signature,
@@ -533,7 +564,7 @@
is a string of length
\(\mathtt{assetDescSize}\)
bytes.
- Elements of every issue note description in IssueAction MUST be valid encodings of the types given in Issue Note Description, and MUST encode the same
+ Elements of every issue note description in IssueAction MUST be valid encodings of the types given in Issue Note, and MUST encode the same
\(\mathsf{AssetBase}\!\)
.
This
@@ -557,7 +588,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 .
+ , as defined in the Note Structure and Commitment section of ZIP 226 .
If
@@ -594,7 +625,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 . 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 . 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.
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.
@@ -607,7 +638,7 @@
- By using the
\(\mathsf{finalize}\)
- boolean and the burning mechanism defined in , issuers can control the supply production of any Asset associated to their issuer keys. For example,
+ boolean and the burning mechanism defined in , issuers can control the supply production of any Asset associated to their issuer keys. For example,
- by setting
\(\mathsf{finalize} = 1\)
@@ -640,7 +671,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 . As in ZIP 244 , 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 . As in ZIP 244 , 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
@@ -676,7 +707,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 .
+ This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification .
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.
@@ -710,7 +741,7 @@
Signature Digest
- The per-input transaction digest algorithm to generate the signature digest in ZIP 244 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 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
@@ -725,14 +756,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 .
+ The personalization field remains the same as in ZIP 244 .
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 .
+ 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 .
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)
@@ -743,7 +774,7 @@
OrchardZSA Fee Calculation
- In addition to the parameters defined in the Fee calculation section of ZIP 317 , the OrchardZSA protocol upgrade defines the following additional parameters:
+ In addition to the parameters defined in the Fee calculation section of ZIP 317 , the OrchardZSA protocol upgrade defines the following additional parameters:
- The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification and the global state. They are defined in the Fee calculation section of ZIP 317 . Note that
+
The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification and the global state. They are defined in the Fee calculation section of ZIP 317 . Note that
\(nOrchardActions\!\)
, that is used in the computation of
\(logical\_actions\!\)
@@ -842,7 +873,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 . 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 . 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.
@@ -328,11 +328,42 @@