where \(\mathbb{P}, \ell_{\mathbb{P}}, q_{\mathbb{P}}\) - are as defined for the Pallas curve 26, and where + are as defined for the Pallas curve 27, and where \(\mathsf{NoteCommit^{Orchard}}.\!\mathsf{Trapdoor}\) and \(\mathsf{Orchard}.\!\mathsf{Output}\) - are as defined in the Zcash protocol specification 16. This note commitment scheme is instantiated using the Sinsemilla Commitment 25 as follows:
+ are as defined in the Zcash protocol specification 17. This note commitment scheme is instantiated using the Sinsemilla Commitment 26 as follows:The nullifier is generated in the same manner as in the Orchard protocol 19.
-The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 27. It consists of
+ is as defined in §5.1 22 of the Zcash protocol specification. +The nullifier is generated in the same manner as in the Orchard protocol 20.
+The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 28. It consists of
Rationale for Note Commitment 
In the ZSA 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 25 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 23. ZSA 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 26 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 24. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:
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.
Rationale for Value Commitment
- The Orchard Protocol uses a Homomorphic Pedersen Commitment 24 to perform the value commitment, with fixed base points +
The Orchard Protocol uses a Homomorphic Pedersen Commitment 25 to perform the value commitment, with fixed base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) @@ -191,44 +195,58 @@
Burn Mechanism
- The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Asset Identifier to be "destroyed". The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation at the consensus level. It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets. Burning makes it globally provable that a given amount of an Asset has been destroyed.
-The sender includes a - \(\mathsf{v_{AssetId}}\) - variable for every Asset Identifier that is being burnt, which represents the amount of that Asset being burnt. As described in the Orchard-ZSA Transaction Structure, this is separate from the regular - \(\mathsf{valueBalance^{Orchard}}\) - that is the default transparent value for the ZEC Asset, and represents either the transaction fee, or the amount of ZEC changing pools (e.g. to Sapling or Transparent).
-For every Custom Asset that is burnt, we add to the +
The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Custom Asset to be "destroyed" by the holder. The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation. It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets. Burning makes it globally provable that a given amount of a Custom Asset has been destroyed. Note that the OrchardZSA Protocol does not allow for the burning of ZEC (or TAZ).
+In the Orchard-ZSA Transaction Structure, there is now an \(\mathsf{assetBurn}\) - set the tuple - \((\mathsf{AssetBase_{AssetId}}, \mathsf{v_{AssetId}})\) - such that the validator of the transaction can compute the value commitment with the corresponding value base point of that Asset. This ensures that the values are all balanced out with respect to the Asset Identifiers in the transfer.
-We denote by + set. For every Custom Asset (represented by its + \(\mathsf{AssetBase}\!\) + ) that is burnt in the transaction, the sender adds to + \(\mathsf{assetBurn}\) + the tuple + \((\mathsf{AssetBase}, \mathsf{v})\) + , where + \(\mathsf{v}\) + is the amount of the Custom Asset the sender wants to burn. We denote by \(L\) the cardinality of the \(\mathsf{assetBurn}\) - set.
+ set in a transaction. +As described in Value Balance Verification, this provides the information for the validator of the transaction to compute the value commitment with the corresponding Asset Base. This ensures that the values are all balanced out on a per-Asset basis in the transaction.
Additional Consensus Rules
-
-
- We require that for every - \((\mathsf{AssetBase_{AssetId}}, \mathsf{v_{AssetId}}) \in \mathsf{assetBurn}, \mathsf{AssetBase_{AssetId}} \neq \mathcal{V}^{\mathsf{Orchard}}\!\) +
- Check that for every + \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}, \mathsf{AssetBase} \neq \mathcal{V}^{\mathsf{Orchard}}\!\) . That is, ZEC or TAZ is not allowed to be burnt by this mechanism. -
- We require that for every - \((\mathsf{AssetBase_{AssetId}}, \mathsf{v_{AssetId}}) \in \mathsf{assetBurn}, \mathsf{v_{AssetId}} \neq 0\!\) +
- Check that for every + \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}, \mathsf{v} \neq 0\!\) . -
- We require that there be no duplication of Custom Assets in the +
- Check that there is no duplication of Custom Assets in the \(\mathsf{assetBurn}\) set. That is, every - \(\mathsf{AssetBase_{AssetId}}\) + \(\mathsf{AssetBase}\) has at most one entry in \(\mathsf{assetBurn}\!\) . +
- Check that for every + \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}\!\) + , + \(\mathsf{v} \leq \mathsf{issued\_assets(AssetBase).balance}\!\) + , where the map + \(\mathsf{issued\_assets}\) + is defined in ZIP 227 6. That is, it is not possible to burn more of an Asset than is currently in circulation.
If all these checks pass, then for every + \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}\!\) + , reduce the value of + \(\mathsf{issued\_assets(AssetBase).balance}\) + in the global state by + \(\mathsf{v}\!\) + .
Note: Even if this mechanism allows having transparent ↔ shielded Asset transfers in theory, 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 18, 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 19, 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 @@ -251,7 +269,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:
This equation contains the balance check of the Orchard protocol 18. 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 19. 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}}\!\) @@ -293,18 +311,18 @@
For Split Notes, the nullifier is generated as follows:
-where - \(\text{ψ}'\) + \(\text{ψ}^{\mathsf{nf}}\) is sampled uniformly at random on \(\mathbb{F}_{q_{\mathbb{P}}}\!\) , \(\mathcal{K}^{\mathsf{Orchard}}\) - is the Orchard Nullifier Base as defined in 19, and + is the Orchard Nullifier Base as defined in 20, 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 17 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 18 to the Actions that have not been assigned input notes.
The Orchard technique requires modification for the ZSA 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 ZSA 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}\) @@ -313,8 +331,8 @@
Circuit Statement
- Every ZSA Action statement is closely similar to the Orchard Action statement 20, 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 31.
+Every ZSA Action statement is closely similar to the Orchard Action statement 21, 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 32.
Asset Base Equality
The following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetBase}\!\) @@ -323,12 +341,12 @@
The
Backwards Compatibility with ZEC Notes
- The input note in the old note commitment integrity check must either include an Asset Base (ZSA 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 16. If the note is a ZSA 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 (ZSA 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 17. If the note is a ZSA note, the note commitment is computed as defined in the Note Structure & Commitment section.
Orchard-ZSA Transaction Structure
- The transaction format for v6 transactions is described in ZIP 230 10.
+The transaction format for v6 transactions is described in ZIP 230 11.
TxId Digest
- The transaction digest algorithm defined in ZIP 244 11 is modified by the ZSA 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 ZSA protocol.
The transaction digest algorithm defined in ZIP 244 12 is modified by the ZSA 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 ZSA protocol.
txid_digest
A BLAKE2b-256 hash of the following values
T.1: header_digest (32-byte hash output) @@ -461,17 +479,18 @@-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 11.
+The personalization field remains the same as in ZIP 244 12.
T.4: orchard_digest
When Orchard Actions are present in the transaction, this digest is a BLAKE2b-256 hash of the following values
T.4a: orchard_actions_compact_digest (32-byte hash output) [UPDATED FOR ZSA] T.4b: orchard_actions_memos_digest (32-byte hash output) [UPDATED FOR ZSA] T.4c: orchard_actions_noncompact_digest (32-byte hash output) [UPDATED FOR ZSA] -T.4d: flagsOrchard (1 byte) -T.4e: valueBalanceOrchard (64-bit signed little-endian) -T.4f: anchorOrchard (32 bytes)+T.4d: orchard_zsa_burn_digest (32-byte hash output) [ADDED FOR ZSA] +T.4e: flagsOrchard (1 byte) +T.4f: valueBalanceOrchard (64-bit signed little-endian) +T.4g: anchorOrchard (32 bytes)
T.4a: orchard_actions_compact_digest
- A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 12 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 13 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
T.4a.i : nullifier (field encoding bytes) T.4a.ii : cmx (field encoding bytes) T.4a.iii: ephemeralKey (field encoding bytes) @@ -486,7 +505,7 @@The
"ZTxIdOrcActMHash"
T.4c: orchard_actions_noncompact_digest
- A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 12 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 13 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
T.4d.i : cv (field encoding bytes) T.4d.ii : rk (field encoding bytes) T.4d.iii: encCiphertext[596..] (post-memo suffix of field encoding) [UPDATED FOR ZSA] @@ -494,14 +513,33 @@The
The personalization field of this hash is defined identically to ZIP 244:
"ZTxIdOrcActNHash"
T.4d: orchard_zsa_burn_digest
+ A BLAKE2b-256 hash of the data from the burn fields of the transaction. For each tuple in the + \(\mathsf{assetBurn}\) + set, the following elements are included in the hash:
+T.4d.i : assetBase (field encoding bytes) +T.4d.ii: valueBurn (field encoding bytes)+
The personalization field of this hash is set to:
+"ZTxIdOrcBurnHash"+
In case the transaction does not perform the burning of any Assets (i.e. the + \(\mathsf{assetBurn}\) + set is empty), the ''orchard_zsa_burn_digest'' is:
+BLAKE2b-256("ZTxIdOrcBurnHash", [])
+ T.4d.i: assetBase
+ The Asset Base being burnt encoded as the 32-byte representation of a point on the Pallas curve.
+T.4d.ii: valueBurn
+ Value of the Asset Base being burnt encoded as little-endian 8-byte representation of 64-bit unsigned integer (e.g. u64 in Rust) raw value.
+T.5: issuance_digest
- The details of the computation of this value are in ZIP 227 7.
+The details of the computation of this value are in ZIP 227 8.
Signature Digest and Authorizing Data Commitment
- The details of the changes to these algorithms are in ZIP 227 8 9.
+The details of the changes to these algorithms are in ZIP 227 9 10.
Security and Privacy Considerations
-
@@ -514,7 +552,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 ZSA protocol upgrade 13.
+The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the ZSA protocol upgrade 14.
Backward Compatibility
In order to have backward compatibility with the ZEC notes, we have designed the circuit to support both ZEC and ZSA notes. As we specify above, there are three main reasons we can do this:
@@ -585,10 +623,18 @@The -
| 6 | +ZIP 227: Issuance of Zcash Shielded Assets: Specification: Global Issuance State | +
|---|
| 7 | ZIP 227: Issuance of Zcash Shielded Assets: Specification: Asset Identifier | |||||
|---|---|---|---|---|---|---|
| 7 | +8 | ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance | ||||
|---|---|---|---|---|---|---|
| 8 | +9 | ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest | ||||
|---|---|---|---|---|---|---|
| 9 | +10 | ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment | ||||
|---|---|---|---|---|---|---|
| 10 | -ZIP 230: Version 6 Transaction Format | +11 | +ZIP 230: Version 6 Transaction Format |
|---|
| 11 | +12 | ZIP 244: Transaction Identifier Non-Malleability | ||||
|---|---|---|---|---|---|---|
| 12 | +13 | ZIP 307: Light Client Protocol for Payment Detection | ||||
|---|---|---|---|---|---|---|
| 13 | +14 | ZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs | ||||
|---|---|---|---|---|---|---|
| 14 | -Zcash Protocol Specification, Version 2023.4.0. Section 3.2: Notes | +15 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes |
|---|
| 16 | -Zcash Protocol Specification, Version 2023.4.0. Section 4.1.8: Commitment | +17 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.8: Commitment |
|---|
| 17 | -Zcash Protocol Specification, Version 2023.4.0. Section 4.8.3: Dummy Notes (Orchard) | +18 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.8.3: Dummy Notes (Orchard) |
|---|
| 22 | -Zcash Protocol Specification, Version 2023.4.0. Section 5.3: Constants | +23 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants |
|---|
| 23 | -Zcash Protocol Specification, Version 2023.4.0. Section 5.4.1.9: Sinsemilla hash function | +24 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.1.9: Sinsemilla hash function |
|---|
| 25 | -Zcash Protocol Specification, Version 2023.4.0. Section 5.4.8.4: Sinsemilla commitments | +26 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.4: Sinsemilla commitments |
|---|
| 26 | -Zcash Protocol Specification, Version 2023.4.0. Section 5.4.9.6: Pallas and Vesta | +27 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.6: Pallas and Vesta |
|---|
| 29 | +30 | User-Defined Assets and Wrapped Assets | ||||
|---|---|---|---|---|---|---|
| 30 | +31 | Comment on Generalized Value Commitments | ||||
|---|---|---|---|---|---|---|
| 31 | +32 | Modifications to the Orchard circuit for the ZSA Protocol | ||||
|---|---|---|---|---|---|---|
@@ -312,17 +328,42 @@
| 3 | -ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation | +ZIP 32: Shielded Hierarchical Deterministic Wallets - Specification: Hardened-only key derivation |
|---|
| 8 | +ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances | +
|---|
| 9 | ZIP 224: Orchard | |||||
|---|---|---|---|---|---|---|
| 9 | +10 | ZIP 226: Transfer and Burn of Zcash Shielded Assets | ||||
|---|---|---|---|---|---|---|
| 10 | +11 | ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment | ||||
|---|---|---|---|---|---|---|
| 11 | +12 | ZIP 226: Transfer and Burn of Zcash Shielded Assets - TxId Digest | ||||
|---|---|---|---|---|---|---|
| 12 | +13 | ZIP 244: Transaction Identifier Non-Malleability | ||||
|---|---|---|---|---|---|---|
| 13 | +14 | ZIP 244: Transaction Identifier Non-Malleability: Signature Digest | |||
|---|---|---|---|---|---|
| 14 | +15 | ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment | |
|---|---|---|---|
| 15 | +16 | ZIP 317: Proportional Transfer Fee Mechanism | |
|---|---|---|---|
| 16 | -BIP 340: Schnorr Signatures for secp256k1 | +17 | +BIP 340: Schnorr Signatures for secp256k1 |
|---|
| 17 | -Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation | +18 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation |
|---|
| 18 | -Zcash Protocol Specification, Version 2023.4.0. Section 3.1: Payment Addresses and Keys | +19 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.1: Payment Addresses and Keys |
|---|
| 19 | -Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components | +20 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.2.3: Orchard Key Components |
|---|
| 20 | -Zcash Protocol Specification, Version 2023.4.0. Section 5.4.9.8: Group Hash into Pallas and Vesta | +21 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.8: Group Hash into Pallas and Vesta |
|---|
| 21 | -Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses | +22 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.6.4.2: Orchard Raw Payment Addresses |
|---|
| 22 | -Zcash Protocol Specification, Version 2023.4.0. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) | +23 | +Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1: Transaction Encoding and Consensus |
|---|
Terminology
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
-The character § is used when referring to sections of the Zcash Protocol Specification 2.
+The terms "Zcash Shielded Asset", "ZSA" and "Asset" in this document are to be interpreted as described in ZIP 226 7.
+The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 8.
+We define the following additional terms:
+-
+
- Issuance Fee: This is the specific fixed fee that has to be paid to the network for every given issuance action. +
The character § is used when referring to sections of the Zcash Protocol Specification 2.
Abstract
This proposal defines a new Zcash peer-to-peer transaction format, which includes data that supports the Orchard-ZSA protocol and all operations related to Zcash Shielded Assets (ZSAs). The new format adds and describes new fields containing ZSA-specific elements. Like the existing v5 transaction format, it keeps well-bounded regions of the serialized form to serve each pool of funds.
-This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 8.
+This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 9.
+This ZIP additionally defines the fee mechanism associated with the Orchard Zcash Shielded Assets (OrchardZSA) protocol as described in ZIP 226 7 and ZIP 227 8. The fee mechanism is defined in terms of modifications to the Proportionak Transfer Fee Mechanism 10.
Motivation
The Orchard-ZSA protocol requires serialized data elements that are distinct from any previous Zcash transaction. Since ZIP 244 was activated in NU5, the v5 and later serialized transaction formats are not consensus-critical. Thus, this ZIP defines format that can easily accommodate future extensions, where elements or a given pool are kept separate.
+The upgrade to the OrchardZSA protocol will also need to define a fee structure consistent with the objectives of ZIP 317 10. This involves adaptation for the transfer protocol 7, as well as additional considerations for the issuance protocol 8 such as fees for asset issuance. Specifically, the OrchardZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. When it comes to Issuance of ZSA, however, there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. In the case of Issuance, the computational power needed to verify the bundle is not large. The transaction size, however, can be an issue as the number of output notes can be large. Furthermore, as defined in ZIP 227 8, there is an additional data structure in the global state that needs to be maintained as part of the consensus. This motivates further the addition of an Issuance-specific fee.
Requirements
The new format must fully support the Orchard-ZSA protocol.
The new format should lend itself to future extension or pruning to add or remove value pools.
The computation of the non-malleable transaction identifier hash must include all newly incorporated elements except those that attest to transaction validity.
The computation of the commitment to authorizing data for a transaction must include all newly incorporated elements that attest to transaction validity.
+In addition to the requirements of ZIP 317 10, the fee mechanism for the OrchardZSA protocol should satisfy the following requirements:
+-
+
- The conventional fee should not leak private information used in constructing the transaction; that is, it should be computable from only the public data of the transaction. +
- Users should be discouraged from issuing new “garbage” custom Assets. The fee should reflect the cost of adding new data to the global state. +
Non-requirements
More general forms of extensibility, such as definining a key/value format that allows for parsers that are unaware of some components, are not required.
@@ -263,15 +276,6 @@byte[64 * nActionsOrchard]64bindingSigOrchardbyte[64]variesnAssetBurnAssetBurn[nAssetBurn]64bindingSigOrchardbyte[64]64issueAuthSigbyte[64]anchorSapling is present if and only if
\(\mathtt{nSpendsSapling} > 0\!\)
.vSpendProofsSapling and vSpendAuthSigsSapling have a 1:1 correspondence to the elements of vSpendsSapling and MUST be ordered such that the proof or signature at a given index corresponds to the SpendDescriptionV6 at the same index.vOutputProofsSapling have a 1:1 correspondence to the elements of vOutputsSapling and MUST be ordered such that the proof at a given index corresponds to the OutputDescriptionV6 at the same index.flagsOrchard, valueBalanceOrchard, anchorOrchard, sizeProofsOrchardZSA, proofsOrchardZSA, and bindingSigOrchard are present if and only if
\(\mathtt{nActionsOrchard} > 0\!\)
. If valueBalanceOrchard is not present, then
@@ -331,9 +343,10 @@
is defined to be
\(0\!\)
.vSpendProofsSapling and vSpendAuthSigsSapling have a 1:1 correspondence to the elements of vSpendsSapling and MUST be ordered such that the proof or signature at a given index corresponds to the SpendDescriptionV6 at the same index.vOutputProofsSapling have a 1:1 correspondence to the elements of vOutputsSapling and MUST be ordered such that the proof at a given index corresponds to the OutputDescriptionV6 at the same index.proofsOrchardZSA, and the elements of vSpendAuthSigsOrchard, each have a 1:1 correspondence to the elements of vActionsOrchard and MUST be ordered such that the proof or signature at a given index corresponds to the OrchardZsaAction at the same index.ik and issueAuthSig are present if and only if
+ \(\mathtt{nIssueActions} > 0\!\)
+ .enableSpendsOrchard and enableZSAs bits MUST be set to
\(0\!\)
.The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification 3.
+The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification 3.
Sapling Output Description (OutputDescriptionV6)
The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification 4.
+The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification 4.
Orchard-ZSA Action Description (OrchardZsaAction)
The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification 5.
+The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification 5.
Orchard-ZSA Asset Burn Description
An Orchard-ZSA Asset Burn description is encoded in a transaction as an instance of an AssetBurn type:
valueBurnuint64The encodings of each of these elements are defined in ZIP 226 6.
+The encodings of each of these elements are defined in ZIP 226 7.
Issuance Action Description (IssueAction)
An issuance action, IssueAction, is the instance of issuing a specific Custom Asset, and contains the following fields:
2variesassetDescSizebytecompactSizevariesnNotescompactSizenoteSize * nNotes147 * nNotesvNotesNote[nNotes]noteSize is the size, in bytes, of a Note.IssueNote[nNotes]1The encodings of each of these elements are defined in ZIP 227 7.
+The encoding of IssueNote is described below. Note that we allow the number of notes (represented by nNotes) to be zero. This allows for issuers to create Issuance Actions to only finalize an issued Asset, without needing them to simultaneously issue more of that Asset.
Issue Note Description (IssueNote)
+ An issuance note, IssueNote contains the following fields:
| Bytes | +Name | +Data Type | +Description | +
|---|---|---|---|
43 |
+ recipient |
+ byte[43] |
+ The encoding of a recipient's diversified payment address, as + \(\mathsf{LEBS2OSP}_{88}(\mathsf{d})\| +\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}} +(\mathsf{pk}_\mathsf{d}))\!\) + , where + \(\mathsf{d}\) + is the diversifier and + \(\mathsf{pk_d}\) + is the diversified transmission key. Non Normative Note: This is the same as the encoding of an Orchard Raw Payment Address, as defined in the protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’. | +
8 |
+ value |
+ uint64 |
+ The amount being issued in this note. | +
32 |
+ assetBase |
+ byte[32] |
+ The encoding of the Asset Base + \(\mathsf{AssetBase^{Orchard}}\!\) + , as defined in 'ZIP 227'. | +
32 |
+ rho |
+ byte[32] |
+ This is defined and encoded in the same manner as for Orchard notes in protocol §3.2.1 'Note Plaintexts and Memo Fields'. | +
32 |
+ rseed |
+ byte[32] |
+ The rseed field of the note, encoded as for Orchard notes in protocol §3.2.1 'Note Plaintexts and Memo Fields'. |
+
OrchardZSA Fee Calculation
+ In addition to the parameters defined in the Fee calculation section of ZIP 317 11, the OrchardZSA protocol upgrade defines the following additional parameters:
+| Parameter | +Value | +
|---|---|
| + \(issuance\_fee\) + | ++ \(100 \cdot marginal\_fee\) + per issuance action (as defined below) | +
Wallets implementing this specification SHOULD use a conventional fee, viz. + \(zsa\_conventional\_fee\) + , that is calculated in zatoshis. Additional definitions that are used in the formula for the calculation are in the table below:
+| Input | +Units | +Description | +
|---|---|---|
| + \(nOrchardActions\) + | +number | +the number of OrchardZSA transfer actions (including ZEC actions) | +
| + \(nTotalOutputsZsaIssuance\) + | +number | +the total number of OrchardZSA issuance outputs (added across issuance actions) | +
| + \(nCreateActions\) + | +number | +the number of OrchardZSA issuance actions that issue a Custom Asset that is not present in the Global Issuance State | +
The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 6 and the global state. They are defined in the Fee calculation section of ZIP 317 11. Note that + \(nOrchardActions\) + , that is used in the computation of + \(logical\_actions\) + , is redefined in the above table, and now combines the actions for native ZEC as well as OrchardZSA transfer actions for Custom Assets.
+The formula for the computation of the + \(zsa\_logical\_actions\) + (with the updated computation of + \(logical\_actions\) + as described above) is:
+The formula for the computation of the + \(zsa\_conventional\_fee\) + is:
+It is not a consensus requirement that fees follow this formula; however, wallets SHOULD create transactions that pay this fee, in order to reduce information leakage, unless overridden by the user.
+Rationale for OrchardZSA Fee calculation
+ The OrchardZSA fee calculation accounts for the additions to the Global Issuance State that are required for the OrchardZSA protocol. Every newly created Custom Asset adds a new row to the Global Issuance State. Subsequent issuance, finalization, or burn of existing Custom Assets only changes the values in the corresponding row.
+This explains the need for a higher fee for the creation of entirely new Custom Assets, in order to disincentivize the creation of "junk" assets.
+OrchardZSA Fee Considerations
+ We choose to maintain the native ZEC Asset as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.
+An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. In the context of transparent transactions, such a fee allows miners to “tap into” the ZSA value of the transactions, rather than the ZEC value of transactions. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.
Reference implementation
@@ -588,7 +737,7 @@
| 6 | +Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus | +
|---|
| 7 | ZIP 226: Transfer and Burn of Zcash Shielded Assets |
|---|
| 7 | +8 | ZIP 227: Issuance of Zcash Shielded Assets |
|---|
| 8 | +9 | ZIP 244: Transaction Identifier Non-Malleability |
|---|
| 10 | +ZIP 317: Proportional Transfer Fee Mechanism | +
|---|
| 11 | +ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation | +
|---|