ZIP: 226
Title: Transfer and Burn of Zcash Shielded Assets
Owners: Pablo Kogan <pablo@qed-it.com>
        Vivek Arte <vivek@qed-it.com>
        Daira-Emma Hopwood <daira@electriccoin.co>
        Jack Grigg <str4d@electriccoin.co>
Credits: Daniel Benarroch
         Aurelien Nicolas
         Deirdre Connolly
         Teor
Status: Draft
Category: Consensus
Created: 2022-05-01
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/618>
Pull-Request: <https://github.com/zcash/zips/pull/680>

Terminology

The key word "MUST" in this document is to be interpreted as described in RFC 2119¹.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200².

The terms "Orchard" and "Action" in this document are to be interpreted as described in ZIP 224³.

The terms "Asset", "Custom Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 227⁴.

We define the following additional terms:

Split Input: an Action input used to ensure that the output note of that Action is of a validly issued AssetBase (see⁵) when there is no corresponding real input note, in situations where the number of outputs are larger than the number of inputs. See formal definition in Split Notes.
Split Action: an Action that contains a Split Input.

Abstract

This ZIP (ZIP 226) proposes the Zcash Shielded Assets (ZSA) protocol, in conjunction with ZIP 227⁶. The ZSA protocol is an extension of the Orchard protocol that enables the issuance, transfer and burn of custom Assets on the Zcash chain. The issuance of such Assets is defined in ZIP 227⁷, while the transfer and burn of such Assets is defined in this ZIP (ZIP 226). While the proposed ZSA protocol is a modification to the Orchard protocol, it has been designed with adaptation to possible future shielded protocols in mind.

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

Overview

In order to be able to represent different Assets, we need to define a data field that uniquely represents the Asset in question, which we call the Asset Identifier AssetId. This Asset Identifier maps to an Asset Base AssetBase^Orchard 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 value^net from each Action Description, computed as value^old − 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 Hopwood¹² ¹³, we propose to make this happen by changing the value base point, 𝒱^Orchard, in the Homomorphic Pedersen Commitment that derives the value commitment, 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 AssetBase^Orchard 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 AssetBase^Orchard is used in the old note commitment and the new note commitment¹⁵, and as the base point 𝒱^Orchard in the value commitment¹⁶. This ensures (1) that the input and output notes are of the same AssetBase^Orchard, 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 AssetBase^Orchard of the output note of that Split Action is the output of a valid ZSAValueBase^Orchard computation defined in ZIP 227¹⁸.

Finally, in this ZIP we also describe the burn mechanism, which is a direct extension of the transfer mechanism. The burn process uses a similar mechanism to what is used in Orchard to unshield ZEC, by using the valueBalance of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets.

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, asset_desc, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance key of the issuer, the specific Asset Identifier, AssetId, the Asset Digest, and the Asset Base (AssetBase^Orchard for the Orchard-based ZSA protocol) are derived as defined in ZIP 227¹⁹.

This AssetBase^Orchard will be the base point of the value commitment for the specific Custom Asset. Note that the AssetBase^Orchard of the ZEC Asset will be kept as the original value base point, 𝒱^Orchard.

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²⁰.

Note Structure & Commitment

Let Note^OrchardZSA be the type of a ZSA note, i.e. Note^OrchardZSA := Note^Orchard × ℙ*.

A ZSA note differs from an Orchard note²¹ by additionally including the Asset Base, AssetBase^Orchard. So a ZSA note is a tuple (g_d, pk_d, v, ρ, ψ, AssetBase^Orchard), where

AssetBase^Orchard : ℙ* 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 non-bottom group element that is not the identity. The byte representation of the Asset Base is defined as asset_base : 𝔹^[ℓ_ℙ] := repr_ℙ(AssetBase^Orchard).

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

We define the note commitment scheme NoteCommit_rcm^OrchardZSA as follows:

NoteCommit^OrchardZSA : NoteCommit^Orchard.Trapdoor × 𝔹^[ℓ_ℙ] × 𝔹^[ℓ_ℙ] × {0..2^ℓ_value − 1} × 𝔽_{q_ℙ} × 𝔽_{q_ℙ} × ℙ * → NoteCommit^Orchard.Output

where ℙ, ℓ_ℙ, q_ℙ are as defined for the Pallas curve²⁴, and NoteCommit^Orchard.Trapdoor, Orchard.Output are as defined in the Zcash protocol specification²⁵. This note commitment scheme is instantiated using the Sinsemilla Commitment²⁶ as follows:

$$\begin{aligned} \begin{align} \mathsf{NoteCommit^{OrchardZSA}_{rcm}(g_{d}*, pk_{d}*, v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} :=\begin{cases} \mathsf{NoteCommit^{Orchard}_{rcm}(g_{d}*, pk_{d}*, v, \rho, \psi)}, &\text{if } \mathsf{AssetBase}^{\mathsf{Orchard}} = \mathcal{V}^{\mathsf{Orchard}} \\ \mathsf{cm}_{\mathsf{ZSA}} &\text{otherwise} \end{cases} \end{align} \end{aligned}$$

where:

$$\begin{aligned} \begin{align} \mathsf{cm}_{\mathsf{ZSA}} :=&\ \mathsf{SinsemillaHashToPoint}( \texttt{"z.cash:ZSA-NoteCommit-M"}, \\\ &\ \ \ \mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{asset\_base}) \\\ &\ + [\mathsf{rcm}] \mathsf{GroupHash}^{\mathbb{P}}(\texttt{"z.cash:Orchard-NoteCommit-r"},\texttt{""}) \end{align} \end{aligned}$$

Note that repr_ℙ and GroupHash^ℙ are as defined for the Pallas curve²⁷, ℓ_base^Orchard is as defined in §5.3²⁸, and 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

(leadByte : 𝔹^𝕐, d : 𝔹^[ℓ_d], v : {0..2^ℓ_value − 1}, rseed : 𝔹^𝕐[32], asset_base : 𝔹^[ℓ_ℙ], memo : 𝔹^𝕐[512])

Rationale for Note Commitment

In the ZSA protocol, the instance of the note commitment scheme, NoteCommit_rcm^OrchardZSA, differs from the Orchard note commitment NoteCommit_rcm^Orchard 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:

NoteCommit_rcm^OrchardZSA(repr_ℙ(g_d), repr_ℙ(pk_d), v, ρ, ψ, AssetBase^Orchard) ∈ 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.

Value Commitment

In the case of the 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:

cv^net := ValueCommit_rcv^OrchardZSA(v_AssetId^net, AssetBase_AssetId^Orchard) := [v_AssetId^net]AssetBase_AssetId^Orchard + [rcv]ℛ^Orchard

where v_AssetId^net = v_AssetId^old − v_AssetId^new such that v_AssetId^old and v_AssetId^new are the values of the old and new notes of Asset Identifier AssetId respectively,

AssetBase_AssetId^Orchard is defined in ZIP 227³⁴, and

ℛ^Orchard := GroupHash^ℙ("z.cash:Orchard-cv", "r"), as in the Orchard protocol.

We define AssetBase_ZEC^Orchard := 𝒱^Orchard so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5³⁵. As such ValueCommit_rcv^Orchard(v) as defined in³⁶ is used as ValueCommit_rcv^OrchardZSA(v, 𝒱^Orchard) here.

Rationale for Value Commitment

The Orchard Protocol uses a Homomorphic Pedersen Commitment³⁷ to perform the value commitment, with fixed base points 𝒱^Orchard and ℛ^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.

Value Balance Verification

In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol³⁸.

For a total of n Actions in a transfer, the prover MUST still sign the SIGHASH transaction hash using the binding signature key $\mathsf{bsk} = \sum_{i=1}^{n} \mathsf{rcv}_{i}$.

The verifier MUST compute

$$\mathsf{bvk} =(\sum_{i=1}^{n} \mathsf{cv^{net}}_{i}) - \mathsf{ValueCommit_0^{OrchardZSA}(v^{balanceOrchard}, \mathcal{V}^{\mathsf{Orchard}})}$$

After computing bvk, the verifier MUST use it to verify the binding signature on the SIGHASH transaction hash.

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 assume m Actions related to ZEC and n − m Actions related to Custom Assets, where m ∈ [0, n]. Furthermore, we assume for simplicity that given a tuple of n Actions in a transfer, the m Actions related to ZEC are first (in practice Actions could be in whatever order).

The value balance verification is equivalent to:

$$\mathsf{bvk} = (\sum_{i=1}^{m} \mathsf{cv^{net}}_{i}) + (\sum_{j=m+1}^{n} \mathsf{cv^{net}}_j) - \mathsf{ValueCommit_0^{OrchardZSA}(v^{balanceOrchard}, \mathcal{V}^{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. As such, for a correctly constructed transaction, we MUST get $\mathsf{(\sum_{j=m+1}^{n} v_j^{net}) = 0}$, and thus be left with $\mathsf{\sum_{j=m+1}^{n} rcv_{j}^{net}}\mathcal{R}^{\mathsf{Orchard}}$ in the expression. If m = n (resp. m = 0), i.e. all Actions relate to ZEC (resp. Custom Assets), then m + 1 > n (resp. 1 > m), and thus the sum $\sum_{j=m+1}^{n}$ (resp. $\sum_{i=1}^{m}$) returns the identity element of the group.

Thus, the main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded within a regular transaction (as opposed to a burn, covered below in the burn mechanism). All Custom Assets are contained within the shielded pool. This means that the net balance of the input and output values is zero, with only one value balance published, which corresponds to the ZEC value balance v^{balanceOrchard}. No net amount of any other Asset will be revealed, and the number of Assets in the transaction is also hidden.

As in the Orchard protocol, the binding signature verification key, 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 only sum to zero per Asset Base, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

Split Notes

A Split Input is a copy of a previously issued input note (that is, a note that has previously been included in the Merkle tree), with the following changes:

A split_flag boolean is set to 1.
The value of the note is replaced with the value 0 during the computation of the value commitment.

Input notes are sometimes split in two (or more) output notes, as in most cases, not all the value in a single note is sent to a single output.

When the number of input notes of a particular Asset Base is smaller than the required number of output notes for the same Asset Base, the sender creates Split Inputs of the same Asset Base as padding for the input-less Actions. Note that we do not care about whether the previously issued note copied to create a Split Input is owned by the sender, or whether it was nullified before.

Wallets and other clients have to choose from the following to ensure the Asset Base is preserved for the output note of a Split Action:

The Split Input note could be another note containing the same Asset Base that is being spent by this transaction (but not by this Split Input).
The Split Input note could be a different unspent note containing the same Asset Base (note that the note will not actually be spent).
The Split Input note could be an already spent note containing the same Asset Base (note that by zeroing the value in the circuit, we prevent double spending).

For Split Notes, the nullifier is generated as follows

nf_old = Extract_ℙ([(PRF_nk^nfOrchard(ρ^old) + ψ′)mod q_ℙ]𝒦^Orchard + cm^old + ℒ^Orchard)

where ψ′ is sampled uniformly at random on 𝔽_{q_ℙ}, 𝒦^Orchard is the Orchard Nullifier Base as defined in⁴⁰, and ℒ^Orchard := GroupHash^ℙ("z.cash:Orchard", "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 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 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⁴³.

Asset Base Equality

The following constraints must be added to ensure that the input and output note are of the same AssetBase:

The Asset Base, AssetBase_AssetId^Orchard, for the note is witnessed once, as an auxiliary input.
In the Old note commitment integrity constraint in the Orchard Action statement⁴⁴, NoteCommit_rcm^old^Orchard(repr_ℙ(g_d^old), repr_ℙ(pk_d^old), v^old, ρ^old, ψ^old) is replaced with NoteCommit_rcm^old^OrchardZSA(repr_ℙ(g_d^old), repr_ℙ(pk_d^old), v^old, ρ^old, ψ^old, AssetBase_AssetId^Orchard).
In the New note commitment integrity constraint in the Orchard Action statement⁴⁵, NoteCommit_rcm^new^Orchard(repr_ℙ(g_d^new), repr_ℙ(pk_d^new), v^new, ρ^new, ψ^new) is replaced with NoteCommit_rcm^new^OrchardZSA(repr_ℙ(g_d^new), repr_ℙ(pk_d^new), v^new, ρ^new, ψ^new, AssetBase_AssetId^Orchard).

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

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 constraints between the value and the value base point of the value commitment, 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 AssetBase_AssetId^Orchard.

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, v′, as cv^net = ValueCommit_rcv^OrchardZSA(v’ − vⁿew, AssetBase_AssetId^Orchard)
Add a boolean split_flag variable as an auxiliary witness. This variable is to be activated split_flag = 1 if the Action in question has a Split Input and split_flag = 0 if the Action is actually spending an input note:
- If split_flag = 1 then constrain v′ = 0 otherwise constrain v′ = v^old from the auxiliary input.
- If split_flag = 1 then constrain 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 (path, pos) is a valid Merkle path of depth MerkleDepth^Orchard, from cm^old to the anchor 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 (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.

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.

The sender includes a v^AssetBase variable for every Asset Identifier that is being burnt. As we will show in the ZSA Transaction Structure, this is separate from the regular valueBalance^Orchard that is the default transparent value for the ZEC Asset.

For every Custom Asset that is burnt, we add to the assetBurn vector the tuple (AssetBase, v^AssetBase) 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.

assetBurn = {(AssetBase, v^AssetBase) | ∀ AssetBase s.t. v^AssetBase ≠ 0}

We denote by L the cardinality of the assetBurn set.

The value balances for each Asset Identifier in assetBurn represents the amount of that Asset that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing pools (eg: to Sapling or Transparent).

The validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective AssetBase as the value base point of the Pedersen Commitment.

This is done as follows:

$$\mathsf{bvk} = (\sum_{i=1}^{n} \mathsf{cv^{net}}_{i}) - \mathsf{ValueCommit_0^{OrchardZSA}}(\mathsf{v^{balanceOrchard}}, \mathcal{V}^{\mathsf{Orchard}}) - \sum_{k=1}^{L} \mathsf{ValueCommit_0^{OrchardZSA}}(\mathsf{v}_{k}, \mathsf{AssetBase}_{k})$$

After computing bvk, the verifier MUST use it to verify the binding signature on the SIGHASH transaction hash.

In the case that the balance of all the Action values related to a specific Asset will be zero, there will be no value added to the vector. This way, neither the number of Assets nor their Asset Identifiers will be revealed, except in the case that an Asset is burnt.

Burn Mechanism Consensus Rules

We require that ∀(AssetBase, v^AssetBase) ∈ assetBurn , AssetBase ≠ 𝒱^Orchard. That is, ZEC or TAZ is not allowed to be burnt.
We require that for every ∀(AssetBase, v^AssetBase) ∈ assetBurn , v^AssetBase ≠ 0.
We require that there be no duplication of Custom Assets in the assetBurn set. That is, every AssetBase has at most one entry in assetBurn.

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.

Rationale for Burn Mechanism

As for the value balance verification, we assume n Actions, m of which are related to ZEC and the remaining n − m Actions related to Custom Assets.

The burn mechanism verification is equivalent to:

$$\mathsf{bvk} = ((\sum_{i=1}^{m} \mathsf{cv^{net}}_{i}) + (\sum_{j=m+1}^{n} \mathsf{cv^{net}}_{j})) - ([\mathsf{v^{balanceOrchard}}]\mathcal{V}^{\mathsf{Orchard}} + [0]\mathcal{R}^{\mathsf{Orchard}}) - (\sum_{k=1}^{L} [\mathsf{v}_{k}]\mathsf{AssetBase}_{k} + [0]\mathcal{R}^{\mathsf{Orchard}})$$

The relationship between bvk and bsk will hold only if the sum of the net values of the Actions equals the sum of v^{balanceOrchard} and the v_k values, across base points (i.e. Asset Base).

ZSA Transaction Structure

The transaction format closely follows the version 5 transaction format described in the Zcash specification⁴⁷. The Common Transaction Fields, Transparent Transaction Fields, and Sapling Transaction Fields remain the same as in the version 5 transaction format. We make some modifications to the Orchard Transaction Fields and the Orchard Action Descriptions, which we detail in the first and second tables below respectively. We also add ZSA Burn Fields to the transaction format, which we detail in the first table below. For brevity, we omit the descriptions from the table below unless they differ from the descriptions in §7.1 of the Zcash specification⁴⁸.

Bytes	Name	Data Type	Description
*Orchard Transaction Fields
`varies`	`nActionsOrchard`	`compactSize`
`852 * nActionsOrchard`	`vActionsOrchard`	`ZSAOrchardAction[nActionsOrchard]`	A sequence of ZSA Orchard Action descriptions, encoded per the ZSA Orchard Action Description Encoding. [UPDATED FOR ZSA]
`1`	`flagsOrchard`	`byte`
`8`	`valueBalanceOrchard`	`int64`
`32`	`anchorOrchard`	`byte[32]`
`varies`	`sizeProofsOrchard`	`compactSize`
`sizeProofsOrchard`	`proofsOrchard`	`byte[sizeProofsOrchard]`
`64 * nActionsOrchard`	`vSpendAuthSigsOrchard`	`byte[64 * nActionsOrchard]`
`64`	`bindingSigOrchard`	`byte[64]`
ZSA Burn Fields
`varies`	`nAssetBurn`	`compactSize`	The number of Assets burnt.
`40 * nAssetBurn`	`vAssetBurn`	`AssetBurn[nAssetBurn]`	A sequence of Asset Burn descriptions, encoded per ZSA Asset Burn Description.

ZSA Orchard Action Description Encoding

The ZSA Orchard Action size differs from the Orchard Action size by 32 bytes. This means that the size goes from 820 bytes in the Orchard Action to 852 bytes in the ZSA Orchard Action. We omit the descriptions from the table below since they are identical to the descriptions in §7.5 of the Zcash specification⁴⁹. A ZSA Orchard Action description is encoded in a transaction as an instance of an ZSAOrchardAction type:

Bytes	Name	Data Type
32	`cv`	`byte[32]`
32	`nullifier`	`byte[32]`
32	`rk`	`byte[32]`
32	`cmx`	`byte[32]`
32	`ephemeralKey`	`byte[32]`
612	`encCiphertext`	`byte[612]`	[UPDATED FOR ZSA]
80	`outCiphertext`	`byte[32]`

ZSA Asset Burn Description

A ZSA Asset Burn description is encoded in a transaction as an instance of an AssetBurn type:

Bytes	Name	Data Type	Description
32	`AssetBase`	`byte[32]`	For the Orchard-based ZSA protocol, this is the encoding of the Asset Base AssetBase^Orchard.
8	`valueBurn`	{1..2⁶⁴ − 1}	The amount being burnt.

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.

txid_digest

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⁵¹.

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

T.5: issuance_digest

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⁵⁵ ⁵⁶.

Security and Privacy Considerations

The notes generated via the ZSA protocol are different from those generated via the Orchard protocol. As with any protocol upgrade, it will be possible to distinguish between notes generated by each protocol. However, all ZEC notes will be fully spendable with the ZSA protocol transaction structure due to the built-in backward compatibility.
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⁵⁷.

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:

Note commitments for ZEC notes will remain the same, while note commitments for Custom Assets will be computed taking into account the AssetBase value as well.
The existing Orchard shielded pool will continue to be used for the new ZSA 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.

Deployment

The Zcash Shielded Assets protocol will be deployed in a subsequent Network Upgrade.

Test Vectors

https://github.com/QED-it/zcash-test-vectors

Reference Implementation

https://github.com/QED-it/zcash (in zcashd)
https://github.com/QED-it/orchard (in orchard)
https://github.com/QED-it/librustzcash (in librustzcash)
https://github.com/QED-it/halo2 (in halo2)

References

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels ↩
ZIP 200: Network Upgrade Mechanism ↩
ZIP 224: Orchard ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 227: Issuance of Zcash Shielded Assets: Specification: Asset Identifier ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
Zcash Protocol Specification, Version 2022.3.8. Section 3.7: Action Transfers and their Descriptions ↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard)↩
User-Defined Assets and Wrapped Assets ↩
Comment on Generalized Value Commitments ↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.8.3: Dummy Notes (Orchard)↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances ↩
Zcash Protocol Specification, Version 2022.3.8. Section 3.2: Notes ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta ↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.1.8: Commitment ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.3: Constants ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.1: Integers, Bit Sequences, and Endianness ↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.5: Encodings of Note Plaintexts and Memo Fields ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.1.9: Sinsemilla hash function ↩
ZIP 227: Issuance of Zcash Shielded Assets ↩
ZIP 224: Orchard ↩
ZIP 224: Orchard ↩
Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers ↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.8.3: Dummy Notes (Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard)↩
Modifications to the Orchard circuit for the ZSA Protocol ↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard)↩
Zcash Protocol Specification, Version 2022.3.8. Section 4.1.8: Commitment ↩
Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)↩
Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)↩
Zcash Protocol Specification, Version 2022.3.8. Section 7.5: Action Description Encoding and Consensus ↩
ZIP 244: Transaction Identifier Non-Malleability ↩
ZIP 244: Transaction Identifier Non-Malleability ↩
ZIP 307: Light Client Protocol for Payment Detection ↩
ZIP 307: Light Client Protocol for Payment Detection ↩
ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance ↩
ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest ↩
ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment ↩
ZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs ↩

Files

zip-0226.rst

Latest commit

History