Rationale for Asset Identifiers

In future network and protocol upgrades, the same Asset description string can be carried on, potentially mapping into a different shielded pool. In that case, nodes should know how to transform the Asset Identifier, the Asset Digest, and the Asset Base from one shielded pool to another, while ensuring there are no balance violations 3.

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.

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

Rationale for Value Commitment

The Orchard Protocol uses a Homomorphic Pedersen Commitment 38 to perform the value commitment, with fixed base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) as the values represent the amount of ZEC being transferred.

The use of different value base points for different Assets enables the final balance of the transaction to be securely computed, such that each Asset Identifier is balanced independently, which is required as different Assets are not meant to be mutually fungible.

Rationale for Action Groups

In the Zcash protocol deployed in NU5, the anchor is not included in the Action Description, and is only included once in the entire transaction. Action Groups are a generalization of the protocol that allows for Actions generated against different anchors to be combined in a single transaction. The Action Groups abstraction achieves the same function as including the tuple (Merkle Root ( \(\mathsf{rt}\!\) ), enableSpend, enableOutputs) in each Action - but more efficiently. It allows for the binding of multiple Actions, along with an expiry height, in an inseparable manner. It reduces information duplication within the transaction object, and thus is more bandwidth efficient.

One of the applications that takes advantage of this generalization is ZSA Swaps 13. In this application, components provided by two parties, with possible different blockchain states, can be combined in a single transaction.

Rationale for Expiry Height

The expiry height \(\mathsf{nAGExpiryHeight}\) allows for a time limit to be set for the inclusion of a particular Action Group in a mined block. This is useful for applications such as ZSA Swaps 13, where a party might want to limit how long the counterparty has an indefinite option on their trade intent.

Rationale for v1 Signature Digests and Spend Authorization Signature Changes

In the OrchardZSA protocol, each Action includes a Spend Authorization Signature 32 that binds a specific spend instruction to a specific transaction and prevents replay attacks.

However, in the generalization to multiple Action Groups, each of which might be generated by different parties, the mechanism needs updating. This is because the transaction SIGHASH represents a hash over a full consensus-compliant transaction object. The party creating the Action Group might not be able to construct the SIGHASH as the full transaction might not be known at that point. This is because various fields are set only when the full bundle transaction is formed and sent to the chain.

To make sure the time limit isn't malleable and replay attacks are precluded, the sender signs the information in the Action Group of the Order. The orchard_action_groups_digest contains all the information that the sender needs to authorize, which is why we use this for the v1 Signature Digest. The non-malleability of the expiry height and other fields of received orders during order matching is guaranteed by the unforgeability of the sender's Spend Authorization Signature.

Additional Consensus Rules for the assetBurn set

1. It MUST be the case that for every \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}, \mathsf{AssetBase} \neq \mathcal{V}^{\mathsf{Orchard}}\!\) . That is, the Native Asset is not allowed to be burnt by this mechanism.
2. It MUST be that for every \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}, \mathsf{v} > 0\) and \(\mathsf{v} \leq \mathsf{MAX\_BURN\_VALUE}\!\) .
3. There MUST be no duplication of Custom Assets in the \(\mathsf{assetBurn}_{\mathsf{AG}}\) set, for each Action Group \(\mathsf{AG}\!\) . That is, every \(\mathsf{AssetBase}\) has at most one entry in \(\mathsf{assetBurn}_{\mathsf{AG}}\) for each Action Group.

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.

Rationale for MAX_BURN_VALUE

The maximum amount of any Custom Asset allowed to be burnt in a transaction is set to \(\mathsf{MAX\_BURN\_VALUE}\) in order to prevent it from being incompatible with other valueBalance fields, which are signed 64-bit integers. It will also allow for compatibility with future Custom-asset-specific value balances in subsequent pools that support transferring ZSAs from the Orchard pool via a turnstile.

Rationale for Value Balance Verification

We assume \(n\) Actions in a transfer. Out of these \(n\) Actions, we further distinguish (for the sake of clarity) between Actions related to ZEC and Actions related to Custom Assets. We denote by \(S_{\mathsf{ZEC}} \subseteq \{1 .. n\}\) the set of indices of Actions that are related to ZEC, and by \(S_{\mathsf{CA}} = \{1 .. n\} \setminus S_{\mathsf{ZEC}}\) 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 31. 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}}\!\) .

When the Asset is not being burnt, the net balance of the input and output values is zero, and there will be no addition to the \(\mathsf{assetBurn}\) vector. Therefore, the relationship between \(\mathsf{bvk}\) and \(\mathsf{bsk}\) will hold if and only if, per Custom Asset, the sum of the net values of the relevant Actions equals the corresponding \(\mathsf{v}_k\) value (or equals \(0\) if that Asset is not in the \(\mathsf{assetBurn}\) set), and for ZEC, the sum of the net values of the relevant Actions equals the \(\mathsf{v^{balanceOrchard}}\) value.

As in the Orchard protocol, the binding signature verification key, \(\mathsf{bvk}\!\) , will only be valid (and hence verify the signature correctly), as long as the committed values sum to zero. In contrast, in this protocol, the committed values must sum to zero per Asset Base, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

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

Asset Base Equality

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

• The Asset Base, \(\mathsf{AssetBase}\!\) , for the note is witnessed once, as an auxiliary input.
• In the Old note commitment integrity constraint in the Orchard Action statement 34, \(\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})\!\) .
• In the New note commitment integrity constraint in the Orchard Action statement 34, \(\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})\!\) .

To make the evaluation of the note commitment easier, we add a boolean \(\mathsf{is\_native\_asset}\) as an auxiliary witness. We also add some constraints to verify that this variable is activated (i.e. \(\mathsf{is\_native\_asset} = 1\!\) ) if the Asset Base is equal to \(\mathcal{V}^{\mathsf{Orchard}}\) and this variable is not activated (i.e. \(\mathsf{is\_native\_asset} = 0\!\) ) if the Asset Base is not equal to \(\mathcal{V}^{\mathsf{Orchard}}\!\) .

The \(\mathsf{enableZSA}\) Flag

The following constraints must be added to disable transactions involving Custom Assets when the \(\mathsf{enableZSA}\) flag is set to false:

• if \(\mathsf{enableZSA}\) is not activated (i.e. \(\mathsf{enableZSA} = 0\!\) ), then constrain \(\mathsf{is\_native\_asset} = 1\!\) , since the \(\mathsf{AsssetBase}\) must be equal to the native asset.

Value Commitment Correctness

The following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base:

• The fixed-base multiplication constraint between the value and the value base point of the value commitment, \(\mathsf{cv}\!\) , is replaced with a variable-base multiplication between the two.
• The witness to the value base point (as defined in the asset base equation) is the auxiliary input \(\mathsf{AssetBase}\!\) .

Asset Identifier Consistency for Split Actions

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

• The Value Commitment Integrity should be changed:
  • Replace the input note value by a generic value, \(\mathsf{v}'\!\) , as \(\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}}(\mathsf{AssetBase}, \mathsf{v}' - \mathsf{v^{new}})\)
• Add a boolean \(\mathsf{split\_flag}\) variable as an auxiliary witness. This variable is to be activated \(\mathsf{split\_flag} = 1\) if the Action in question has a Split Input and \(\mathsf{split\_flag} = 0\) if the Action is actually spending an input note:
  • If \(\mathsf{split\_flag} = 1\) then constrain \(\mathsf{v}' = 0\) otherwise constrain \(\mathsf{v}' = \mathsf{v^{old}}\) from the auxiliary input.
  • If \(\mathsf{split\_flag} = 1\) then constrain \(\mathsf{is\_native\_asset} = 0\) because split notes are only available for Custom Assets.
• The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes):
  • Check for all notes except dummy notes that \((\mathsf{path}, \mathsf{pos})\) is a valid Merkle path of depth \(\mathsf{MerkleDepth^{Orchard}}\!\) , from \(\mathsf{cm^{old}}\) to the anchor \(\mathsf{rt^{Orchard}}\!\) .
  • The new constraint is \(\underbrace{(\mathsf{v^{old}} = 0 \land \mathsf{is\_native\_asset} = 1)}_\text{It is a dummy note} \lor \underbrace{(\mathsf{Valid\,Merkle\,Path})}_\text{The Merkle Path is valid}\!\) .
• The Nullifier Integrity will be changed to prevent the identification of notes as defined in the Split Notes section.

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 28. If the note is an OrchardZSA note, the note commitment is computed as defined in the Note Structure and Commitment section.

Implications for Wallets

The following requirements on wallets are specified and motivated in ZIP 230 19:

• All wallets should switch to sending only v6 transactions once NU7 has activated. The main consequence of not doing so relevant to ZSAs, is that users would not obtain the privacy benefit of indistinguishability between native and non-native assets in the Orchard shielded pool, because v5 transactions can only transact in the native ZEC asset. For other consequences see ZIP 230.
• All wallets should be ready to receive funds in outputs of v6 transactions as soon as ZSAs activate. The consequence of not doing so would be that funds sent to Orchard addresses of a wallet without this support could be temporarily inaccessible, until the wallet is upgraded to fully support v6 and to rescan outputs since v6 activation.