Motivation 
None of the currently deployed Zcash transfer protocols support Custom Assets. Enabling multi-asset support on the Zcash chain will open the door for a host of applications, and enhance the ecosystem with application developers and Asset custody institutions for issuance and bridging purposes. This ZIP builds on the issuance mechanism introduced in ZIP 227 .
@@ -49,19 +49,19 @@
\(\mathsf{AssetId}\!\)
. This Asset Identifier maps to an Asset Base
\(\mathsf{AssetBase}\)
- that is stored in Orchard-based ZSA notes. These terms are formally defined in ZIP 227 .
- The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description is preserved across Assets (see the Orchard Binding Signature ), and by extension the balance of an Orchard transaction. That is, the sum of all the
+ that is stored in OrchardZSA notes. These terms are formally defined in ZIP 227 .
+ The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description is preserved across Assets (see the Orchard Binding Signature ), 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 , we propose to make this happen by changing the value base point,
+
As was initially proposed by Jack Grigg and Daira-Emma Hopwood , 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 , 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 , and as the base point in the value commitment . 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 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 , 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 , and as the base point in the value commitment . 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 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}\)
@@ -80,7 +80,7 @@
Specification
Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.
Asset Identifiers
- For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an Asset description,
+
For every new Asset, there MUST be a new and unique Asset Identifier. Every Asset is defined by an Asset description,
\(\mathsf{asset\_desc}\!\)
, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance validating key of the issuer, the specific Asset Identifier,
\(\mathsf{AssetId}\!\)
@@ -95,26 +95,30 @@
Note Structure & Commitment
- Let
- \(\mathsf{Note^{OrchardZSA}}\)
- be the type of a ZSA note, i.e.
- \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^*\!\)
- .
- An Orchard ZSA note differs from an Orchard note by additionally including the Asset Base,
+
An OrchardZSA note differs from an Orchard note by additionally including the Asset Base,
\(\mathsf{AssetBase}\!\)
- . So a ZSA note is a tuple
- \((\mathsf{g_d}, \mathsf{pk_d}, \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase})\!\)
+ . So an OrchardZSA note is a tuple
+ \((\mathsf{d}, \mathsf{pk_d}, \mathsf{v}, \mathsf{AssetBase}, \text{ρ}, \text{ψ}, \mathsf{rcm})\!\)
, where
-
\(\mathsf{AssetBase} : \mathbb{P}^*\)
- is the unique element of the Pallas group that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 , a valid group element that is not the identity and is not
+ is the unique element of the Pallas group that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 , 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 .
Note that the above assumes a canonical encoding, which is true for the Pallas group, but may not hold for future shielded protocols.
+ Let
+ \(\mathsf{Note^{OrchardZSA}}\)
+ be the type of a OrchardZSA note, i.e.
+ \(\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 .
+ 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}}\)
as follows:
@@ -131,9 +135,9 @@
where
\(\mathbb{P}, \ell_{\mathbb{P}}, q_{\mathbb{P}}\)
- are as defined for the Pallas curve , and where
+ are as defined for the Pallas curve , and where
\(\mathsf{NoteCommit^{Orchard}.\{Trapdoor, Output\}}\)
- are as defined in the Zcash protocol specification . This note commitment scheme is instantiated using the Sinsemilla Commitment as follows:
+ are as defined in the Zcash protocol specification . This note commitment scheme is instantiated using the Sinsemilla Commitment 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}} \\
@@ -152,27 +156,27 @@
\(\mathsf{repr}_{\mathbb{P}}\)
and
\(\mathsf{GroupHash}^{\mathbb{P}}\)
- are as defined for the Pallas curve ,
+ are as defined for the Pallas curve ,
\(\ell^{\mathsf{Orchard}}_{\mathsf{base}}\)
- is as defined in §5.3 , and
+ is as defined in §5.3 , and
\(\mathsf{I2LEBSP}\)
- is as defined in §5.1 of the Zcash protocol specification.
-
The nullifier is generated in the same manner as in the Orchard protocol .
-
The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext . It consists of
+ is as defined in §5.1 of the Zcash protocol specification.
+
The nullifier is generated in the same manner as in the Orchard protocol .
+
The OrchardZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext . 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]})\)
Rationale for Note Commitment
- In the ZSA protocol, the instance of the note commitment scheme,
+
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 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 . 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 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 . 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 ZSA notes.
+ 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.
Value Commitment
- In the case of the Orchard-based ZSA protocol, the value of different Asset Identifiers in a given transaction will be committed using a different value base point. The value commitment becomes:
+ In the case of the OrchardZSA protocol, the value of different Asset Identifiers in a given transaction will be committed using a different value base point. The value commitment becomes:
\(\mathsf{cv^{net}} := \mathsf{ValueCommit^{OrchardZSA}_{rcv}}(\mathsf{AssetBase_{AssetId}}, \mathsf{v^{net}_{AssetId}}) = [\mathsf{v^{net}_{AssetId}}]\,\mathsf{AssetBase_{AssetId}} + [\mathsf{rcv}]\,\mathcal{R}^{\mathsf{Orchard}}\)
where
\(\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId}} - \mathsf{v^{new}_{AssetId}}\)
@@ -187,20 +191,20 @@
respectively,
\(\mathsf{AssetBase_{AssetId}}\)
- is defined in ZIP 227 , and
+ is defined in ZIP 227 , 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 . As such
+ so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 . As such
\(\mathsf{ValueCommit^{Orchard}_{rcv}}(\mathsf{v})\)
- as defined in is used as
+ as defined in 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 to perform the value commitment, with fixed base points
+
The Orchard Protocol uses a Homomorphic Pedersen Commitment to perform the value commitment, with fixed base points
\(\mathcal{V}^{\mathsf{Orchard}}\)
and
\(\mathcal{R}^{\mathsf{Orchard}}\)
@@ -209,8 +213,8 @@
Burn Mechanism
- 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
+
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 the Native Asset (i.e. ZEC or TAZ).
+ In the OrchardZSA Transaction Structure, there is now an
\(\mathsf{assetBurn}\)
set. For every Custom Asset (represented by its
\(\mathsf{AssetBase}\!\)
@@ -226,41 +230,28 @@
\(\mathsf{assetBurn}\)
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
+ Additional Consensus Rules for the assetBurn set
- - Check that for every
+
- It MUST be the case 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.
- - Check that for every
+ . That is, the Native Asset is not allowed to be burnt by this mechanism.
+ - It MUST be that for every
\((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}, \mathsf{v} \neq 0\!\)
.
- - Check that there is no duplication of Custom Assets in the
+
- There MUST be no duplication of Custom Assets in the
\(\mathsf{assetBurn}\)
set. That is, every
\(\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 . 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.
+ The other consensus rule changes for the OrchardZSA protocol are specified in ZIP 227 .
+ 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 , 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 , 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
@@ -283,7 +274,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 . 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 . 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}}\!\)
@@ -332,21 +323,21 @@
\(\mathbb{F}_{q_{\mathbb{P}}}\!\)
,
\(\mathcal{K}^{\mathsf{Orchard}}\)
- is the Orchard Nullifier Base as defined in , and
+ is the Orchard Nullifier Base as defined in , 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 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
+
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 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}\)
boolean). This ensures that the value base points of all output notes of a transfer are actual outputs of a GroupHash, as they originate in the Issuance protocol which is publicly verified.
Note that the Orchard dummy note functionality remains in use for ZEC notes, and the Split Input technique is used in order to support Custom Assets.
Circuit Statement
- Every ZSA Action statement is closely similar to the Orchard Action statement , 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 .
+ Every OrchardZSA Action statement is closely similar to the Orchard Action statement , 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 .
Asset Base Equality
The following constraints must be added to ensure that the input and output note are of the same
\(\mathsf{AssetBase}\!\)
@@ -355,12 +346,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 ,
+ In the Old note commitment integrity constraint in the Orchard Action statement ,
\(\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 ,
+ In the New note commitment integrity constraint in the Orchard Action statement ,
\(\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}})\!\)
@@ -462,110 +453,158 @@ 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 . 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 (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 . If the note is an OrchardZSA 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 .
+ OrchardZSA Transaction Structure
+ The transaction format for v6 transactions is described in ZIP 230 .
TxId Digest
- The transaction digest algorithm defined in ZIP 244 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 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
+ A BLAKE2b-256 hash of the following values:
T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
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 .
+ The personalization field remains the same as in ZIP 244 .
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: 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 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)
-T.4a.iv : encCiphertext[..84] (First 84 bytes of field encoding) [UPDATED FOR ZSA]
- The personalization field of this hash is the same as in ZIP 244:
- "ZTxIdOrcActCHash"
-
- T.4b: orchard_actions_memos_digest
- A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
- T.4b.i: encCiphertext[84..596] (contents of the encrypted memo field) [UPDATED FOR ZSA]
- The personalization field of this hash remains identical to ZIP 244:
- "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 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]
-T.4d.iv : outCiphertext (field encoding bytes)
- The personalization field of this hash is defined identically to ZIP 244:
- "ZTxIdOrcActNHash"
+ 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
+ "ZTxIdOrchardHash"
+ In the case that the transaction has no OrchardZSA Action Groups, orchard_digest is
+ BLAKE2b-256("ZTxIdOrchardHash", [])
+ T.4a: orchard_action_groups_digest
+ A BLAKE2b-256 hash of the subset of OrchardZSA Action Groups information for all OrchardZSA Action Groups belonging to the transaction. For each Action Group, the following elements are included in the hash:
+ T.4a.i : orchard_actions_compact_digest (32-byte hash output)
+T.4a.ii : orchard_actions_memos_digest (32-byte hash output)
+T.4a.iii: orchard_actions_noncompact_digest (32-byte hash output)
+T.4a.iv : flagsOrchard (1 byte)
+T.4a.v : anchorOrchard (32 bytes)
+T.4a.vi : nAGExpiryHeight (4 bytes)
+ 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 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)
+T.4a.i.4 : encCiphertext[..84] (First 84 bytes of field encoding) [UPDATED FOR ZSA]
+ The personalization field of this hash is the same as in ZIP 244:
+ "ZTxIdOrcActCHash"
+
+ T.4a.ii: orchard_actions_memos_digest
+ A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all OrchardZSA Actions belonging to the Action Group. For each Action, the following elements are included in the hash:
+ T.4a.ii.1: encCiphertext[84..596] (contents of the encrypted memo field) [UPDATED FOR ZSA]
+ The personalization field of this hash remains identical to ZIP 244:
+ "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 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]
+T.4a.iii.4 : outCiphertext (field encoding bytes)
+ The personalization field of this hash is defined identically to ZIP 244:
+ "ZTxIdOrcActNHash"
+
- T.4d: orchard_zsa_burn_digest
+ T.4b: 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)
+ T.4b.i : assetBase (field encoding bytes)
+T.4b.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.5: issuance_digest
- The details of the computation of this value are in ZIP 227 .
+ The details of the computation of this value are in ZIP 227 .
- Signature Digest and Authorizing Data Commitment
- The details of the changes to these algorithms are in ZIP 227 .
+ Signature Digest
+ The details of the changes to this algorithm are in ZIP 227 .
+
+ Authorizing Data Commitment
+ The transaction digest algorithm defined in ZIP 244 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
+├── sapling_auth_digest
+├── orchard_auth_digest [UPDATED FOR ZSA]
+└── issuance_auth_digest [ADDED FOR ZSA]
+ The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.
+ auth_digest
+ A BLAKE2b-256 hash of the following values
+ A.1: transparent_scripts_digest (32-byte hash output)
+A.2: sapling_auth_digest (32-byte hash output)
+A.3: orchard_auth_digest (32-byte hash output) [UPDATED FOR ZSA]
+A.4: issuance_auth_digest (32-byte hash output) [ADDED FOR ZSA]
+ The personalization field of this hash remains the same as in ZIP 244.
+ A.3: orchard_auth_digest
+ In the case that OrchardZSA Action Groups are present, this is a BLAKE2b-256 hash of the following values:
+ A.3a: orchard_action_groups_auth_digest (32-byte hash output) [ADDED FOR ZSA]
+A.3b: bindingSigOrchard (field encoding bytes)
+ The personalization field of this hash is the same as in ZIP 244, that is:
+ "ZTxAuthOrchaHash"
+ In case that the transaction has no OrchardZSA Action Groups, orchard_auth_digest is:
+ BLAKE2b-256("ZTxAuthOrchaHash", [])
+ A.3a: orchard_action_groups_auth_digest
+ This is a BLAKE2b-256 hash of the proofsOrchard and spendAuthSigsOrchard fields of all OrchardZSA Action Groups belonging to the transaction:
+ A.3a.i: proofsOrchard (field encoding bytes)
+A.3a.ii: spendAuthSigsOrchard (field encoding bytes)
+ The personalization field of this hash is set to:
+ "ZTxAuthOrcAGHash"
+
+
+ A.4: issuance_auth_digest
+ The details of the computation of this value are in ZIP 227 .
+
+
Security and Privacy Considerations
- - After the protocol upgrade, the Orchard shielded pool will be shared by the Orchard protocol and the Orchard-ZSA protocol.
- - Deploying the Orchard-ZSA protocol does not necessitate disabling the Orchard protocol. Both can co-exist and be addressed via different transaction versions (V5 for Orchard and V6 for Orchard-ZSA). Due to this, Orchard note commitments can be distinguished from Orchard-ZSA note commitments. This holds whether or not the two protocols are active simultaneously.
- - Orchard-ZSA note commitments for the native asset (ZEC) are indistinguishable from Orchard-ZSA note commitments for non-native Assets.
+ - After the protocol upgrade, the Orchard shielded pool will be shared by the Orchard protocol and the OrchardZSA protocol.
+ - Deploying the OrchardZSA protocol does not necessitate disabling the Orchard protocol. Both can co-exist and be addressed via different transaction versions (V5 for Orchard and V6 for OrchardZSA). Due to this, Orchard note commitments can be distinguished from OrchardZSA note commitments. This holds whether or not the two protocols are active simultaneously.
+ - OrchardZSA note commitments for the native asset (ZEC) are indistinguishable from OrchardZSA note commitments for non-native Assets.
- When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design.
- We prevent a potential malleability attack on the Asset Identifier by ensuring the output notes receive an Asset Base that exists on the global state.
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 .
+ 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 .
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:
+ 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:
- Note commitments for ZEC notes will remain the same, while note commitments for Custom Assets will be computed taking into account the
\(\mathsf{AssetBase}\)
value as well.
- - The existing Orchard shielded pool will continue to be used for the new ZSA notes post the upgrade.
+ - The existing Orchard shielded pool will continue to be used for the new OrchardZSA notes post the upgrade.
- The value commitment is abstracted to allow for the value base-point as a variable private input to the proof.
- - The ZEC-based Actions will still include dummy input notes, whereas the ZSA-based Actions will include split input notes and will not include dummy input notes.
+ - The ZEC-based Actions will still include dummy input notes, whereas the OrchardZSA Actions will include split input notes and will not include dummy input notes.
Deployment
- The Zcash Shielded Assets protocol will be deployed in a subsequent Network Upgrade.
+ The Zcash Shielded Assets protocol is scheduled to be deployed in Network Upgrade 7 (NU7).
Test Vectors
@@ -634,14 +673,22 @@ 
- 
-