From dbce499baad84f4bd21f586ed06749a6ceaf90f3 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 13 Jul 2022 23:52:34 +0300 Subject: [PATCH 001/101] initial ZIP drafts for transfer and issuance --- draft-ZIP-0226.html | 523 ++++++++++++++++++++++++++++++++++++++++++++ draft-ZIP-0226.rst | 303 +++++++++++++++++++++++++ draft-ZIP-0227.html | 218 ++++++++++++++++++ draft-ZIP-0227.rst | 184 ++++++++++++++++ 4 files changed, 1228 insertions(+) create mode 100644 draft-ZIP-0226.html create mode 100644 draft-ZIP-0226.rst create mode 100644 draft-ZIP-0227.html create mode 100644 draft-ZIP-0227.rst diff --git a/draft-ZIP-0226.html b/draft-ZIP-0226.html new file mode 100644 index 000000000..aca617ec7 --- /dev/null +++ b/draft-ZIP-0226.html @@ -0,0 +1,523 @@ + + + + Draft ZIP-0226: Transfer and Burn of Zcash Shielded Assets + + + + +
+ 
ZIP: 226
+Title: Transfer and Burn of Zcash Shielded Assets
+Owners: Daniel Benarroch <daniel@qed-it.com>
+        Pablo Kogan <pablo@qed-it.com>
+        Aurelien Nicolas <aurel@qed-it.com>
+Credits: Daira Hopwood
+         Jack Grigg
+         Shahaf Nacshon
+         Vivek Arte
+Status: Draft
+Category: Consensus
+Created: 2022-05-01
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/618>
+

Terminology

+

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

+

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

+

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

+

We define the following additional terms:

+
    +
  • Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
    • +
  • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool.
    • +
  • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
    • +
+
+

Abstract

+

ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

+
+

Motivation

+

The current Orchard protocol does not support custom assets, which is an important aspect for the proper evolution of the Zcash ecosystem. 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.

+
+

Overview

+

In order to be able to represent different asset types in Orchard, one needs to define a new data field that uniquely represents the type of the asset in question, which we call + \(\mathsf{type}\) + .

+

The type will be used to enforce the balance of an action description 6 is preserved across assets (see the Orchard Binding Signature 7 , and by extension of an Orchard transaction. Mainly, the sum of all the + \(\mathsf{value^{net}}\) + , as + \(\mathsf{value^{old}-value^{new}}\) + , derived from each action description, must be balanced only with respect to the same asset type. This is specially important since we will allow different action descriptions to transfer notes of different asset types, where the overall balance is checked without revealing which assets (or how many different types) are being transferred.

+

As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, + \(\mathcal{V}^{\mathsf{Orchard}}\) + , in the Homomorphic Pedersen Commitment that generates 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 types in the transaction. We propose to make the + \(\mathsf{type}\) + identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same + \(\mathsf{type}\) + is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature.

+

In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF.

+

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 than what is used in Orchard to unshield ZEC, by using the + \(\mathsf{valueBalance}\) + of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets.

+
+

Orchard Protocol Changes

+

Most of the protocol is kept the same as the Orchard protocol released with NU5, except the following that will be deployed to mainnet in subsequent network upgrades.

+

Asset Types

+

In the OSA protocol, we include a new variable, the asset type identifier, + \(\mathsf{type}\) + , which is generated as a 32-byte string during issuance (as described in the Issuance ZIP 5). The + \(\mathsf{type}\) + will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the + \(\mathsf{GroupHash}\) + function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see.

+

We denote the string as + \(\mathsf{type}\) + and we denote the equivalent group representation as + \(\mathsf{type}_{\mathbb{G}}\) + when mapped into a specific group, + \(\mathbb{G}\) + . Note that the type of the ZEC asset will be kept as the original value base-point, + \(\mathcal{V}^\mathsf{Orchard}\) +

+

In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one.

+
+

Note Structure & Commitment

+

First, we need to adapt the components that define the assets, i.e.: notes. A ZSA note differs from an Orchard note by including the type of asset, + \(\mathsf{type}_\mathbb{P}\) + . So an ZSA note looks like:

+

+ \((\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})\) +

+

Where + \(\mathsf{type}_\mathbb{P}\) + is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

+

In this case, the note commitment, + \(\mathsf{NoteCommit^{ZSA}_{rcm}}\) + , will differ from + \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) + in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification.

+

Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have

+

+ \(\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}\) +

+

The nullifier is generated in the same manner as in the Orchard protocol.

+
+

Value Commitment

+

The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

+

+ \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) +

+

Where + \(\mathsf{v^{net} = v^{old} - v^{new}}\) + and

+

+ \(\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}\) +

+

+ \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}\) +

+

In the case of the Orchard protocol, we see that the base points + \(\mathcal{V}^{\mathsf{Orchard}}\) + and + \(\mathcal{R}^{\mathsf{Orchard}}\) + are fixed for every value commitment, as the values represent the amount of ZEC being transferred.

+

In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a different value base point. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes

+

+ \(\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) +

+

where + \(\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}\) + such that + \(\mathsf{v^*_{type}}\) + is the value of the note of type + \(\mathsf{type}\) + , and

+

+ \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",type\_params)}\) +

+

+ \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) +

+

Where + \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}\) + .

+
+

Value Balance Verification

+

In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, + \(\mathsf{v^{balanceOrchard}}\) + , so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below.

+

For a total of + \(m\) + actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

+

+ \(\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,m\}}} \mathsf{rcv_{i}}\) +

+

Then we have that the verifier computes

+

+ \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) +

+

And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

+

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 all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out per asset type, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

+
+

Split Notes

+

One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a dummy spend note 12. Basically, the input note is “faked” inside of the proof in order to hide which action contains the real spend note.

+

This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions cannot be of any asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

+

In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

+

Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification:

+
    +
  1. The split input note could be the same note as the original (non-split) Action,
    2. +
  2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent)
    3. +
  3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending)
    4. +
+

The specific circuit changes are presented below.

+
+
+

Circuit Statement

+

The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset type system.

+

Asset Type Equality: the following constraints must be added to ensure that the input and output note are of the same type:

+
    +
  • The asset type, + \(\mathsf{type_\mathbb{P}}\) + , for the note is witnessed once, as an auxiliary input.
    • +
  • The witnessed asset type, + \(\mathsf{type_\mathbb{P}}\) + , is added to the old note commitment input.
    • +
  • The witnessed asset type, + \(\mathsf{type_\mathbb{P}}\) + , is added to the new note commitment input.
    • +
+

Correct Value Commitment Type: the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes

+
    +
  • The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:mathsf{cv}, is replaced with a variable-base multiplication between the two
    • +
  • The witness to the value base-point is the auxiliary input + \(\mathsf{type}_\mathbb{P}\) + .
    • +
+

Enforce Secure Type for Split Actions: the following constraints must be added to prevent senders from malling with the asset type for the output note in the consequent actions of the split:

+
    +
  • +
    +
    The Value Commitment Integrity should be changed
    +
    +
      +
    • Replace the input note value by a generic value, v', as + \(\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})\) +
      • +
    +
    +
    +
    • +
  • +
    +
    Add a boolean “split” variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
    +
    +
      +
    • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input
      • +
    +
    +
    +
    • +
  • +
    +
    The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes):
    +
    +
      +
    • Check that (path, pos) is a valid Merkle path of depth + \(\mathsf{MerkleDepth^Orchard}\) + , from + \(\mathsf{cm^old}\) + to the anchor + \(\mathsf{rt^Orchard}\) + .
      • +
    +
    +
    +
    • +
  • +
    +
    The Nullifier Integrity will be changed to prevent the identification of notes
    +
    +
      +
    • Replace the + \(\psi_{old}\) + value with a generic + \(\psi'\) + as + \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\) +
      • +
    • if split = 1 set + \(\psi' = \mathsf{randomSample}\) + , otherwise set + \(\psi' = \psi^{old}\) +
      • +
    +
    +
    +
    • +
+

Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes.

+

The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

+
    +
  • +
    +
    The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note)
    +
    +
      +
    • +
      +
      If the type auxiliary input is set + \(\mathsf{type}_\mathbb{P}\) + = + \(\mathcal{V}^\mathsf{Orchard}\) +
      +
      +
        +
      • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type)
        • +
      • This path also uses the original domain separator for ZEC note commitment
        • +
      +
      +
      +
      • +
    • +
      +
      Else,
      +
      +
        +
      • The NoteCommitment adds the type, + \(\mathsf{type}_\mathbb{P}\) + , as a final “chunk” of the Sinsemilla commitment
        • +
      • The NoteCommitment uses a different domain separator for ZSA note commitment
        • +
      +
      +
      +
      • +
    +
    +
    +
    • +
+

Backward Compatibility

+

In order to have a "clean" backwards 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: - The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree - 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

+
+
+

Burn Mechanism

+

The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

+

In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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.

+

First, contrary to the strict transfer transaction, we allow the sender to include a + \(\mathsf{valueBalvalueBalance_{type}}\) + variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular + \(\mathsf{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 + \((\mathsf{valueBalance_{type}, type}_\mathbb{P})\) + 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 types in the transfer.

+

+ \(\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]\) +

+

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

+

Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows

+

+ \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) +

+

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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt.

+

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, the unshielding is not not be possible for custom assets.

+
+

ZSA Transaction Structure

+

Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in 14:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BytesNameData TypeDescription
newActionSize * nActionsZSAvActionsZSAActionDescription[nActionOrchard]
variesnAssetBurncompactSizenumber of assets burnt
40*nAssetBurnvAssetBurnbytes[40][nAssetBurn]32 bytes asset type_t, 8 bytes of valueBalance
+
+

Other Considerations

+

Transaction Fees

+

In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on fees market on Zcash 15

+
+

Security and Privacy

+
    +
  • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • +
  • When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design
    • +
  • We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state
    • +
+
+
+

Test Vectors

+
    +
  • LINK TBD
    • +
+
+

Reference Implementation

+
    +
  • LINK TBD
    • +
  • LINK TBD
    • +
+
+

Deployment

+

This ZIP is proposed to activate with Network Upgrade 6.

+
+

References

+ + + + + + + +
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
3ZIP 224: Orchard
+ + + + + + + +
4ZIP 226: Transfer and Burn of Zcash Shielded Assets
+ + + + + + + +
5ZIP 227: Issuance of Zcash Shielded Assets
+ + + + + + + +
6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
+ + + + + + + +
7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)
+ + + + + + + +
8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
+ + + + + + + +
9Pallas/Vesta supporting evidence
+ + + + + + + +
10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
+ + + + + + + +
11Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
+ + + + + + + +
12Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard)
+ + + + + + + +
13Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
+ + + + + + + +
14Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
+ + + + + + + +
15A Study of Decentralized Markets on the Zcash Blockchain
+
+
+
+

Docutils System Messages

+
+

System Message: ERROR/3 (draft-ZIP-0226.rst line 52)

+

Too many autonumbered footnote references: only 0 corresponding footnotes available.

+
+
+

System Message: ERROR/3 (draft-ZIP-0226.rst line 52) id8

+

Unknown target name: "initial-zsa-issue".

+
+
+ + \ No newline at end of file diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst new file mode 100644 index 000000000..d2c46cc73 --- /dev/null +++ b/draft-ZIP-0226.rst @@ -0,0 +1,303 @@ +:: + + ZIP: 226 + Title: Transfer and Burn of Zcash Shielded Assets + Owners: Daniel Benarroch + Pablo Kogan + Aurelien Nicolas + Credits: Daira Hopwood + Jack Grigg + Shahaf Nacshon + Vivek Arte + Status: Draft + Category: Consensus + Created: 2022-05-01 + License: MIT + Discussions-To: + + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as described in RFC 2119 [#RFC2119]_. + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. + +The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. + +We define the following additional terms: + +- Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. +- Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool. +- Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. + +Abstract +======== + +ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the +Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined +in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. + +Motivation +========== + +The current Orchard protocol does not support custom assets, which is an important aspect for the proper evolution of the Zcash ecosystem. 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. + +Overview +======== +In order to be able to represent different asset types in Orchard, one needs to define a new data field that uniquely represents the *type* of the asset in question, which we call :math:`\mathsf{type}`. + +The type will be used to enforce the balance of an action description [#protocol-actions]_ is preserved across assets (see the Orchard Binding Signature [#protocol-binding]_ , and by extension of an Orchard transaction. Mainly, the sum of all the :math:`\mathsf{value^{net}}`, as :math:`\mathsf{value^{old}-value^{new}}`, derived from each action description, must be balanced only **with respect to the same asset type**. This is specially important since we will allow different action descriptions to transfer notes of different asset types, where the overall balance is checked without revealing which assets (or how many different types) are being transferred. + +As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature. + +In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF. + +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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. + +Orchard Protocol Changes +======================== + +Most of the protocol is kept the same as the Orchard protocol released with NU5, except the following that will be deployed to mainnet in subsequent network upgrades. + +Asset Types +----------- + +In the OSA protocol, we include a new variable, the asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the :math:`\mathsf{GroupHash}` +function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see. + +We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}` + +In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one. + +Note Structure & Commitment +--------------------------- + +First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: + + +:math:`(\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})` + + +Where :math:`\mathsf{type}_\mathbb{P}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. + +In this case, the note commitment, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification. + +Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have + + +:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}` + + +The nullifier is generated in the same manner as in the Orchard protocol. + +Value Commitment +---------------- + +The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ which is instantiated as + +:math:`\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` + +Where :math:`\mathsf{v^{net} = v^{old} - v^{new}}` and + +:math:`\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}` + +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}` + +In the case of the Orchard protocol, we see that the base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and +:math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC +being transferred. + +In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes + + +:math:`\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` + + +where :math:`\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}` such that :math:`\mathsf{v^*_{type}}` is the value of the note of type :math:`\mathsf{type}`, and + + +:math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",type\_params)}` + +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` + +Where :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}`. + +Value Balance Verification +-------------------------- + +In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below. + +For a total of :math:`m` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key + +:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,m\}}} \mathsf{rcv_{i}}` + +Then we have that the verifier computes + +:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` + + +And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. + +As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, will only be valid (and hence verify the signature correctly, as long as all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out **per asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. + +Split Notes +----------- + +One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a *dummy spend note* [#protocol-dummynotes]_. Basically, the input note is “faked” inside of the proof in order to hide which action contains the *real* spend note. + +This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. + +In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. + +Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification: + +1. The split input note could be the same note as the original (non-split) Action, +2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent) +3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending) + +The specific circuit changes are presented below. + +Circuit Statement +================= + +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset type system. + +**Asset Type Equality:** the following constraints must be added to ensure that the input and output note are of the +same type: + +- The asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. +- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. +- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. + +**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes + +- The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two +- The witness to the value base-point is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. + +**Enforce Secure Type for Split Actions:** the following constraints must be added to prevent senders from malling with the asset type for the output note in the consequent actions of the split: + +- The Value Commitment Integrity should be changed + - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})` +- Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: + - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input +- The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): + - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. +- The Nullifier Integrity will be changed to prevent the identification of notes + - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` + - if `split = 1` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` + +**Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. + +The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. + +- The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note) + - If the type auxiliary input is set :math:`\mathsf{type}_\mathbb{P}` = :math:`\mathcal{V}^\mathsf{Orchard}` + - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type) + - This path also uses the original domain separator for ZEC note commitment + - Else, + - The NoteCommitment adds the type, :math:`\mathsf{type}_\mathbb{P}`, as a final “chunk” of the Sinsemilla commitment + - The NoteCommitment uses a different domain separator for ZSA note commitment + + +Backward Compatibility +---------------------- + +In order to have a "clean" backwards 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: +- The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree +- 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 + +Burn Mechanism +============== +The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. + +In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. + +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{type}}` variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{type}, type}_\mathbb{P})` 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 types in the transfer. + + +:math:`\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]` + +The value balances for each asset type in `assetBurn` represents the amount of that asset type that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). + +Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows + +:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` + +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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt. + +**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, the unshielding is not not be possible for custom assets. + +ZSA Transaction Structure +========================= +Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in [#protocol-transactionstructure]_: + ++-----------------+-------------+-----------------------------------+-------------------------+ +| Bytes | Name | Data Type | Description | ++=================+=============+===================================+=========================+ +| newActionSize * | vActionsZSA | ActionDescription[nActionOrchard] | | +| nActionsZSA | | | | ++-----------------+-------------+-----------------------------------+-------------------------+ +| varies | nAssetBurn | compactSize | number of assets burnt | ++-----------------+-------------+-----------------------------------+-------------------------+ +| 40*nAssetBurn | vAssetBurn | bytes[40][nAssetBurn] | 32 bytes asset type_t, | +| | | | 8 bytes of valueBalance | ++-----------------+-------------+-----------------------------------+-------------------------+ + +Other Considerations +==================== + +Transaction Fees +---------------- + +In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as +the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on +fees market on Zcash [#fees-study-GMU]_ + +Security and Privacy +-------------------- + +- Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. +- When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design +- We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state + +Test Vectors +============ + +- LINK TBD + +Reference Implementation +======================== + +- LINK TBD +- LINK TBD + +Deployment +========== + +This ZIP is proposed to activate with Network Upgrade 6. + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0224] `ZIP 224: Orchard `_ +.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ +.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ +.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments `_ +.. [#protocol-concretevaluecommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ +.. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) `_ +.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ +.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ +.. [#fees-study-GMU] `A Study of Decentralized Markets on the Zcash Blockchain `_ diff --git a/draft-ZIP-0227.html b/draft-ZIP-0227.html new file mode 100644 index 000000000..8acd51d27 --- /dev/null +++ b/draft-ZIP-0227.html @@ -0,0 +1,218 @@ + + + + Draft ZIP-0227: Issuance of Zcash Shielded Assets + + + + +
+ 
ZIP: 227
+Title: Issuance of Zcash Shielded Assets
+Owners: Daniel Benarroch <daniel@qed-it.com>
+        Pablo Kogan <pablo@qed-it.com>
+        Aurelien Nicolas <aurel@qed-it.com>
+Credits: Daira Hopwood
+         Jack Grigg
+         Shahaf Nacshon
+         Vivek Arte
+Status: Draft
+Category: Consensus
+Created: 2022-05-01
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/618>
+

Terminology

+

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

+

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

+

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

+

We define the following additional terms:

+
    +
  • Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
    • +
  • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool.
    • +
  • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
    • +
+
+

Abstract

+

ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

+
+

Motivation

+

The current Orchard protocol does not support custom assets, which is an important aspect for the proper evolution of the Zcash ecosystem. 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.

+
+

Overview & Rationale

+

This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work conjunction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

+

In short, we are going to enable only transparent issuance, since we believe that as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

+

We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple asset types (and allocate all of those too). Finally, a key component of our design is the finiteIssuance boolean that defines whether a specific asset type can have more tokens issued or not.

+

The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications:

+
    +
  • By setting the finiteIssuance = 1 from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
    • +
  • When the finiteIssuance = 0, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to 1 either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached.
    • +
  • Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset.
    • +
+
+

Asset Identifier Generation

+

For every new asset, there must be a new and unique identifier of the asset. Our design decision is not to have a chosen name for the asset type, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. From this asset identifier, which is a global byte string (valid across all Zcash protocols), we derive the specific type used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve)

+

The main requirement for the asset identifier is for it to be collision-free, as two different issuers should not be able to issue the same asset type. As such we need the asset identifier to be:

+
    +
  • pseudorandom
    • +
  • deterministic
    • +
  • dependent on the issuer ID
    • +
+

We define the asset identifier assetID (represented as a string) as

+

+ \(\mathsf{assetID := GroupHash^{\mathbb{P}}}\mathsf{(issuerID || assetDesc)}\) +

+

where

+
    +
  • assetDesc is the asset description, which includes any information pertaining to the issuance.
    • +
  • issuerID is the public key of the issuer, used to verify the signature on the transaction and is defined as ik (issuer key or issuer verification key):
    • +
+

+ \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\) +

+

which uses the same signature as the spend authorization signature, where isk is the issuer secret key. The verification key is derived from isk. In order to differentiate the isk and ik keys from the actual spend authorization key, we derive another branch of keys from the main spending key sk as such:

+

+ \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}\) +

+

This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys in the wallet safe.

+

Then we let issuanceInfo := (assetID, finiteSupply), where

+
    +
  • assetID is as defined above.
    • +
  • +
    +
    finiteSupply is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once finiteSupply is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism:
    +
    +
      +
    • Provides assetID revocation in case of compromise (issue last issuance with 0 token value)
      • +
    • Supports NFT issuance (where the first issuance with value of 1 is also the last)
      • +
    +
    +
    +
    • +
+
+

Issuance Protocol

+

The issuance protocol allows for a single issuance to be sent to many receivers, as the issuerID does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets.

+
    +
  • The issuer knows in advance the receivers of the issued asset.
    • +
  • The asset is of non-fungible type, where each asset type can be made part of a single “series”
    • +
  • The supply of the asset is limited or not
    • +
  • The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it)
    • +
+

The protocol is as follows:

+
    +
  • +
    +
    For each asset type issued, generate a sequence of output notes, each with the following fields:
    +
    +
      +
    • ZSA output note + \(\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}\) + , where + \(\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}\) +
      • +
    +
    +
    +
    • +
  • Generate commitment of the note. cm as
    • +
+

+ \(cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})\) +

+
    +
  • Sign the issuance note with the issuerID as the signing key, using RedPallas as its signature scheme, on the SIGHASH of the transaction. Note that the SIGHASH will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain.
    • +
+

Consensus Changes

+

Issuance requires the following additions to the global state:

+

First, Zcash clients must keep a mapping issuanceSupplyInfos from assetID to issuanceSupplyInfo := (totalSupply, finiteSupply).

+

Consensus rules

+

For each issuance instance,

+
    +
  • Check that assetID is properly constructed,
    • +
  • Check that each commitment cm is properly constructed from each “output” note,
    • +
  • Check that the issuance instance has a valid signature based on the issuerID,
    • +
  • Check that + \(\mathsf{type}_\mathbb{P}\) + is properly projected into the correct curve from assetID. That is, that + \(\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}\) +
    • +
  • If issuanceSupplyInfo[assetID].finiteSupply`is true, reject. Otherwise, set `issuanceSupplyInfo[assetID].finiteSupply = finiteSupply .
    • +
  • Add the sum of all the values in all output notes per assetID to issuanceSupplyInfo[assetID].totalSupply
    • +
  • After verification, add note commitment to the merkle tree.
    • +
+
+
+

Other Considerations

+

Fee Structures

+

The fee mechanism described in this ZIP may be replaced by a future “Fee Mechanism” ZIP proposal. However, we do need to have some basic fees for the Issuance protocol, as it differs from the usual transfer mechanism in that it adds a whole new structure to the transaction bundle, it adds a new global structure for validators to keep in memory and in turn it adds new consensus rules that are independent of previous structures.

+

There are two main factors that will affect the fee mechanism:

+
    +
  • The transaction size, which may take a big part of the block
    • +
  • The computational power needed to verify and mine the transaction
    • +
+

There is a single parameter that defines both, as there is no privacy or ZKP involved at this stage - the number of output notes in the issuance bundle:

+
    +
  • it trivially defines the bundle size
    • +
  • it defines the computational power as the validator must compute as many note commitments as there are output notes
    • +
+
+
+

Test Vectors

+
    +
  • LINK TBD
    • +
+
+

Reference Implementation

+
    +
  • LINK TBD
    • +
  • LINK TBD
    • +
+
+

Deployment

+

This ZIP is proposed to activate with Network Upgrade 6.

+
+

References

+ + + + + + + +
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
3ZIP 224: Orchard
+ + + + + + + +
4ZIP 226: Transfer and Burn of Zcash Shielded Assets
+ + + + + + + +
5ZIP 227: Issuance of Zcash Shielded Assets
+
+
+ + \ No newline at end of file diff --git a/draft-ZIP-0227.rst b/draft-ZIP-0227.rst new file mode 100644 index 000000000..559d1ee8d --- /dev/null +++ b/draft-ZIP-0227.rst @@ -0,0 +1,184 @@ +:: + + ZIP: 227 + Title: Issuance of Zcash Shielded Assets + Owners: Daniel Benarroch + Pablo Kogan + Aurelien Nicolas + Credits: Daira Hopwood + Jack Grigg + Shahaf Nacshon + Vivek Arte + Status: Draft + Category: Consensus + Created: 2022-05-01 + License: MIT + Discussions-To: + + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as described in RFC 2119 [#RFC2119]_. + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. + +The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. + +We define the following additional terms: + +- Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. +- Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool. +- Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. + +Abstract +======== + +ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the +Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined +in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. + +Motivation +========== + +The current Orchard protocol does not support custom assets, which is an important aspect for the proper +evolution of the Zcash ecosystem. 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. + +Overview & Rationale +==================== + +This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work conjunction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. + +In short, we are going to enable only *transparent* issuance, since we believe that as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. + +We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple asset types (and allocate all of those too). Finally, a key component of our design is the `finiteIssuance` boolean that defines whether a specific asset type can have more tokens issued or not. + +The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications: + +- By setting the `finiteIssuance = 1` from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. +- When the `finiteIssuance = 0`, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to `1` either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached. +- Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset. + + +Asset Identifier Generation +=========================== + +For every new asset, there must be a new and unique identifier of the asset. Our design decision is not to have a chosen name for the asset type, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. From this asset identifier, which is a global byte string (valid across all Zcash protocols), we derive the specific type used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve) + +The main requirement for the asset identifier is for it to be collision-free, as two different issuers should not be able to issue the same asset type. As such we need the asset identifier to be: + +- pseudorandom +- deterministic +- dependent on the issuer ID + +We define the asset identifier `assetID` (represented as a string) as + +:math:`\mathsf{assetID := GroupHash^{\mathbb{P}}}\mathsf{(issuerID || assetDesc)}` + +where + +- `assetDesc` is the asset description, which includes any information pertaining to the issuance. +- `issuerID` is the public key of the issuer, used to verify the signature on the transaction and is defined as `ik` (issuer key or issuer verification key): + + +:math:`\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}` + + +which uses the same signature as the spend authorization signature, where `isk` is the issuer secret key. The verification key is derived from `isk`. In order to differentiate the `isk` and `ik` keys from the actual spend authorization key, we derive another branch of keys from the main spending key `sk` as such: + +:math:`\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}` + +This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys in the wallet safe. + +Then we let `issuanceInfo := (assetID, finiteSupply)`, where + +- `assetID` is as defined above. +- `finiteSupply` is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once `finiteSupply` is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism: + - Provides `assetID` revocation in case of compromise (issue last issuance with 0 token value) + - Supports NFT issuance (where the first issuance with value of 1 is also the last) + + +Issuance Protocol +================= + +The issuance protocol allows for a single issuance to be sent to many receivers, as the issuerID does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets. + +- The issuer knows in advance the receivers of the issued asset. +- The asset is of non-fungible type, where each asset type can be made part of a single “series” +- The supply of the asset is limited or not +- The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) + +The protocol is as follows: + +- For each asset type issued, generate a sequence of output notes, each with the following fields: + - ZSA output note :math:`\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}`, where :math:`\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}` +- Generate commitment of the note. `cm` as + +:math:`cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})` + +- Sign the issuance note with the `issuerID` as the signing key, using RedPallas as its signature scheme, on the `SIGHASH` of the transaction. Note that the `SIGHASH` will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain. + +Consensus Changes +----------------- + +Issuance requires the following additions to the global state: + +First, Zcash clients must keep a mapping `issuanceSupplyInfos` from `assetID` to `issuanceSupplyInfo := (totalSupply, finiteSupply)`. + +**Consensus rules** + +For each issuance instance, + +- Check that `assetID` is properly constructed, +- Check that each commitment `cm` is properly constructed from each “output” note, +- Check that the issuance instance has a valid signature based on the `issuerID`, +- Check that :math:`\mathsf{type}_\mathbb{P}` is properly projected into the correct curve from `assetID`. That is, that :math:`\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}` +- If `issuanceSupplyInfo[assetID].finiteSupply`is true, reject. Otherwise, set `issuanceSupplyInfo[assetID].finiteSupply = finiteSupply` . +- Add the sum of all the values in all output notes per `assetID` to `issuanceSupplyInfo[assetID].totalSupply` +- After verification, add note commitment to the merkle tree. + +Other Considerations +==================== + +Fee Structures +-------------- + +The fee mechanism described in this ZIP may be replaced by a future “Fee Mechanism” ZIP proposal. However, we do need to have some basic fees for the Issuance protocol, as it differs from the usual transfer mechanism in that it adds a whole new structure to the transaction bundle, it adds a new global structure for validators to keep in memory and in turn it adds new consensus rules that are independent of previous structures. + +There are two main factors that will affect the fee mechanism: + +- The transaction size, which may take a big part of the block +- The computational power needed to verify and mine the transaction + +There is a single parameter that defines both, as there is no privacy or ZKP involved at this stage - the number of output notes in the issuance bundle: + +- it trivially defines the bundle size +- it defines the computational power as the validator must compute as many note commitments as there are output notes + + +Test Vectors +============ + +- LINK TBD + +Reference Implementation +======================== + +- LINK TBD +- LINK TBD + +Deployment +========== + +This ZIP is proposed to activate with Network Upgrade 6. + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0224] `ZIP 224: Orchard `_ +.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ \ No newline at end of file From 5e8583588e75bef483de9028c158e1a9827a50e2 Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:00:12 +0200 Subject: [PATCH 002/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index d2c46cc73..ea8350974 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -27,7 +27,10 @@ The term "Orchard" in this document is to be interpreted as described in ZIP 224 We define the following additional terms: -- Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. +- Asset: A type of note that can be transferred on the Zcash block chain. + + - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. + - Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool. - Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. From f68d5037cc3802a0a8260654877739dea5e794c6 Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:02:58 +0200 Subject: [PATCH 003/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index ea8350974..d0913ffca 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -31,7 +31,7 @@ We define the following additional terms: - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. -- Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool. +- Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. Abstract From 10188a42480a2f64d87d827752c014bb361b51ee Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:03:20 +0200 Subject: [PATCH 004/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index d0913ffca..9ef73c504 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -32,7 +32,7 @@ We define the following additional terms: - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. -- Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. +- Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. Abstract ======== From 1fcd4e09b135a72c7cbff04608936985b6c10c4a Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:04:32 +0200 Subject: [PATCH 005/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index 9ef73c504..a68a12c2d 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -38,7 +38,7 @@ Abstract ======== ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the -Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined +Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. Motivation From 879741dc024432b380ba1b21737cc8df1f322786 Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:04:53 +0200 Subject: [PATCH 006/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index a68a12c2d..b04024535 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -44,7 +44,7 @@ in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP Motivation ========== -The current Orchard protocol does not support custom assets, which is an important aspect for the proper evolution of the Zcash ecosystem. 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. +The current Orchard protocol does not 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. Overview ======== From c95d801fc97cc31bafbad2bd8eedbdec28df16b8 Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:05:22 +0200 Subject: [PATCH 007/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index b04024535..abe7e916e 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -48,7 +48,7 @@ The current Orchard protocol does not support custom assets. Enabling multi-asse Overview ======== -In order to be able to represent different asset types in Orchard, one needs to define a new data field that uniquely represents the *type* of the asset in question, which we call :math:`\mathsf{type}`. +In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the *type* of the Asset in question, which we call :math:`\mathsf{type}`. The type will be used to enforce the balance of an action description [#protocol-actions]_ is preserved across assets (see the Orchard Binding Signature [#protocol-binding]_ , and by extension of an Orchard transaction. Mainly, the sum of all the :math:`\mathsf{value^{net}}`, as :math:`\mathsf{value^{old}-value^{new}}`, derived from each action description, must be balanced only **with respect to the same asset type**. This is specially important since we will allow different action descriptions to transfer notes of different asset types, where the overall balance is checked without revealing which assets (or how many different types) are being transferred. From 31f931c03c7a99620dc8fb68294bde95ee9414ce Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 11:06:25 +0200 Subject: [PATCH 008/101] Update draft-ZIP-0226.rst Co-authored-by: Deirdre Connolly --- draft-ZIP-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index abe7e916e..270869cdb 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -50,7 +50,7 @@ Overview ======== In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the *type* of the Asset in question, which we call :math:`\mathsf{type}`. -The type will be used to enforce the balance of an action description [#protocol-actions]_ is preserved across assets (see the Orchard Binding Signature [#protocol-binding]_ , and by extension of an Orchard transaction. Mainly, the sum of all the :math:`\mathsf{value^{net}}`, as :math:`\mathsf{value^{old}-value^{new}}`, derived from each action description, must be balanced only **with respect to the same asset type**. This is specially important since we will allow different action descriptions to transfer notes of different asset types, where the overall balance is checked without revealing which assets (or how many different types) are being transferred. +The type will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset type**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset types, where the overall balance is checked without revealing which Assets (or how many different types) are being transferred. As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\mathsf{cv^{net}}`, of the *net value* in an Orchard Action. From c9267958904793ef90c6a05a7c82f4f6fcd0f0cf Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 12:19:07 +0200 Subject: [PATCH 009/101] Apply suggestions from code review of transfer and burn zip Co-authored-by: Deirdre Connolly Co-authored-by: Daira Hopwood --- draft-ZIP-0226.rst | 73 +++++++++++++++++++++++----------------------- 1 file changed, 37 insertions(+), 36 deletions(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index 270869cdb..b8ba7b4aa 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -54,44 +54,44 @@ The type will be used to enforce the balance of an Action Description [#protocol As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof for each Action, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment. This ensures (1) that the input and output notes are of the same type, and (2) that only Actions with the same Asset type identifier will balance out in the binding and balance signatures. -In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF. +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 type of the output note of that split Action is the output of a PRF. -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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. +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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Native Assets. Orchard Protocol Changes ======================== -Most of the protocol is kept the same as the Orchard protocol released with NU5, except the following that will be deployed to mainnet in subsequent network upgrades. +Most of the protocol is kept the same as the Orchard protocol released with NU5, except the following, that will be deployed to Mainnet in subsequent network upgrades. Asset Types ----------- -In the OSA protocol, we include a new variable, the asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the :math:`\mathsf{GroupHash}` -function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see. +In the ZSA protocol, we include a new variable, the Asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the group of points defined on the Pallas curve, by using the :math:`\mathsf{GroupHash}` +function. In fact, every ZSA note will contain the group element representation of the Asset type identifier. This will enable a more elegant and simple version of the circuit, as we will see. -We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}` +We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}` -In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one. +In future network and protocol upgrades, the same Asset type string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset type from one shielded protocol to another. Note Structure & Commitment --------------------------- -First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: +First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of Asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})` -Where :math:`\mathsf{type}_\mathbb{P}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. +Where :math:`\mathsf{type}_\mathbb{P}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_, that identifies each Asset in the Orchard protocol. -In this case, the note commitment, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification. +In this case, the note commitment scheme, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the type will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. -Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have +The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have -:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}` +:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \mathsf{NoteCommit^{Orchard}.Output} \union \{\bot\}` The nullifier is generated in the same manner as in the Orchard protocol. @@ -113,7 +113,7 @@ In the case of the Orchard protocol, we see that the base points :math:`\mathcal :math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC being transferred. -In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes +In the case of the ZSA protocol, the value of different Asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each Asset type is balanced independently, as Assets of different types are not meant to be mutually fungible. The value commitment then becomes :math:`\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` @@ -131,29 +131,29 @@ Where :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orc Value Balance Verification -------------------------- -In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below. +In order to verify the balance of the different Assets, the verifier MUST perform exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason why no changes are needed is that no custom Assets can be unshielded, so 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 type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. Therefore no net amount of any type will be revealed, and neither will the number of types in the transaction. The only exception to this is in the case that an Asset is *burnt*, as we will see below. -For a total of :math:`m` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key +For a total of :math:`m` Actions in a transfer, the prover MUST still sign the `SIGHASH` of the transaction using the binding signature key :math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,m\}}} \mathsf{rcv_{i}}` -Then we have that the verifier computes +Then the verifier MUST compute :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. -As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, will only be valid (and hence verify the signature correctly, as long as all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out **per asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. +As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. Split Notes ----------- -One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a *dummy spend note* [#protocol-dummynotes]_. Basically, the input note is “faked” inside of the proof in order to hide which action contains the *real* spend note. +One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. -This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. +This, however, brings some issues when it comes to adding multiple Asset types, as the output note of the split Actions *cannot* be of *any* Asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. -In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle Tree. We then enforce this real note to be “unspendable” in the sense that its value +In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification: @@ -167,35 +167,36 @@ The specific circuit changes are presented below. Circuit Statement ================= -The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset type system. +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset type system. -**Asset Type Equality:** the following constraints must be added to ensure that the input and output note are of the -same type: +**Asset Type Equality:** the following constraints must be added to ensure that +the input and output note are of the same Asset type: -- The asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. -- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. -- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. +- The Asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. +- The witnessed Asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. +- The witnessed Asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. -**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes +**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes: - The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two - The witness to the value base-point is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. -**Enforce Secure Type for Split Actions:** the following constraints must be added to prevent senders from malling with the asset type for the output note in the consequent actions of the split: +**Enforce Secure Type for Split Actions:** the following constraints MUST be added to prevent senders from malling with the Asset type for the output note in the consequent actions of the split: - The Value Commitment Integrity should be changed - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})` - Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: - - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input -- The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): + - If :math:`split = 1` then constrain :math:`v' = 0` otherwise constrain :math:`v'=v^old` from the auxiliary input. + - If :math:`split = 1` then constrain :math:`v^{old} \neq 0`. +- The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes): - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. - The Nullifier Integrity will be changed to prevent the identification of notes - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - - if `split = 1` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` + - If :math:`split = 0` then constrain :math:`\psi' = \psi^\mathsf{old}`. (Otherwise :math:`\psi'` should be sampled randomly.) **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. -The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. +The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. - The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note) - If the type auxiliary input is set :math:`\mathsf{type}_\mathbb{P}` = :math:`\mathcal{V}^\mathsf{Orchard}` @@ -218,9 +219,9 @@ Burn Mechanism ============== The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. -In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. +In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset type to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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. -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{type}}` variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC asset. +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{type}}` variable for every Asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{type}, type}_\mathbb{P})` 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 types in the transfer. @@ -235,7 +236,7 @@ Finally, the validator needs to verify the Balance and Binding Signature by addi 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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt. -**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, the unshielding is not not be possible for custom assets. +**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. ZSA Transaction Structure ========================= From 4da0b83a3bfa954ac65a5dd416fdcca192bd62b9 Mon Sep 17 00:00:00 2001 From: Daniel Benarroch Date: Tue, 18 Oct 2022 12:25:24 +0200 Subject: [PATCH 010/101] adds comments from initial review - split note definition - 'n' actions as per the specification (not 'm') - internal references --- draft-ZIP-0226.rst | 96 ++++++++++++++++++++++++---------------------- 1 file changed, 50 insertions(+), 46 deletions(-) diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst index b8ba7b4aa..f3b01838e 100644 --- a/draft-ZIP-0226.rst +++ b/draft-ZIP-0226.rst @@ -33,6 +33,9 @@ We define the following additional terms: - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. +- Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. +- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific type. The Split Note is not spent in the transaction. +- Split Action: a Zcash Shielded Asset Action that contains a Split Note. Abstract ======== @@ -54,44 +57,44 @@ The type will be used to enforce the balance of an Action Description [#protocol As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof for each Action, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment. This ensures (1) that the input and output notes are of the same type, and (2) that only Actions with the same Asset type identifier will balance out in the binding and balance signatures. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are asset types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance 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 type of the output note of that split Action is the output of a PRF. +In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF. -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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Native Assets. +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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. -Orchard Protocol Changes -======================== +Specification +============= -Most of the protocol is kept the same as the Orchard protocol released with NU5, except the following, that will be deployed to Mainnet in subsequent network upgrades. +Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following. Asset Types ----------- -In the ZSA protocol, we include a new variable, the Asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the group of points defined on the Pallas curve, by using the :math:`\mathsf{GroupHash}` -function. In fact, every ZSA note will contain the group element representation of the Asset type identifier. This will enable a more elegant and simple version of the circuit, as we will see. +In the OSA protocol, we include a new variable, the asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the :math:`\mathsf{GroupHash}` +function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see. -We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}` +We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}` -In future network and protocol upgrades, the same Asset type string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset type from one shielded protocol to another. +In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one. Note Structure & Commitment --------------------------- -First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of Asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: +First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})` -Where :math:`\mathsf{type}_\mathbb{P}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_, that identifies each Asset in the Orchard protocol. +Where :math:`\mathsf{type}_\mathbb{P}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. -In this case, the note commitment scheme, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the type will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. +In this case, the note commitment, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification. -The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have +Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have -:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \mathsf{NoteCommit^{Orchard}.Output} \union \{\bot\}` +:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}` The nullifier is generated in the same manner as in the Orchard protocol. @@ -113,7 +116,7 @@ In the case of the Orchard protocol, we see that the base points :math:`\mathcal :math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC being transferred. -In the case of the ZSA protocol, the value of different Asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each Asset type is balanced independently, as Assets of different types are not meant to be mutually fungible. The value commitment then becomes +In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes :math:`\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` @@ -121,6 +124,7 @@ In the case of the ZSA protocol, the value of different Asset types in a given t where :math:`\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}` such that :math:`\mathsf{v^*_{type}}` is the value of the note of type :math:`\mathsf{type}`, and +.. _valuebase: :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",type\_params)}` @@ -131,29 +135,29 @@ Where :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orc Value Balance Verification -------------------------- -In order to verify the balance of the different Assets, the verifier MUST perform exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason why no changes are needed is that no custom Assets can be unshielded, so 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 type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. Therefore no net amount of any type will be revealed, and neither will the number of types in the transaction. The only exception to this is in the case that an Asset is *burnt*, as we will see below. +In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in burnmechanism_. -For a total of :math:`m` Actions in a transfer, the prover MUST still sign the `SIGHASH` of the transaction using the binding signature key +For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key -:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,m\}}} \mathsf{rcv_{i}}` +:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}` -Then the verifier MUST compute +Then we have that the verifier computes :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. -As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. +As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, will only be valid (and hence verify the signature correctly, as long as all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out **per asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. Split Notes ----------- -One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. +One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a *dummy spend note* [#protocol-dummynotes]_. Basically, the input note is “faked” inside of the proof in order to hide which action contains the *real* spend note. -This, however, brings some issues when it comes to adding multiple Asset types, as the output note of the split Actions *cannot* be of *any* Asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. +This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. -In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 +In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification: @@ -167,36 +171,35 @@ The specific circuit changes are presented below. Circuit Statement ================= -The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset type system. +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset type system. -**Asset Type Equality:** the following constraints must be added to ensure that -the input and output note are of the same Asset type: +**Asset Type Equality:** the following constraints must be added to ensure that the input and output note are of the +same type: -- The Asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. -- The witnessed Asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. -- The witnessed Asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. +- The asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. +- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. +- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. -**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes: +**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes - The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two -- The witness to the value base-point is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. +- The witness to the value base-point, as defined in valuebase_ is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. -**Enforce Secure Type for Split Actions:** the following constraints MUST be added to prevent senders from malling with the Asset type for the output note in the consequent actions of the split: +**Enforce Secure Type for Split Actions:** the following constraints must be added to prevent senders from changing the asset type for the output note in the Split Actions: - The Value Commitment Integrity should be changed - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})` - Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: - - If :math:`split = 1` then constrain :math:`v' = 0` otherwise constrain :math:`v'=v^old` from the auxiliary input. - - If :math:`split = 1` then constrain :math:`v^{old} \neq 0`. -- The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes): + - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input +- The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. - The Nullifier Integrity will be changed to prevent the identification of notes - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - - If :math:`split = 0` then constrain :math:`\psi' = \psi^\mathsf{old}`. (Otherwise :math:`\psi'` should be sampled randomly.) + - if `split = 1` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. -The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. +The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. - The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note) - If the type auxiliary input is set :math:`\mathsf{type}_\mathbb{P}` = :math:`\mathcal{V}^\mathsf{Orchard}` @@ -215,13 +218,15 @@ In order to have a "clean" backwards compatibility with the ZEC notes, we have d - 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 +.. _burnmechanism: + Burn Mechanism ============== The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. -In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset type to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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. +In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{type}}` variable for every Asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC Asset. +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{type}}` variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{type}, type}_\mathbb{P})` 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 types in the transfer. @@ -236,7 +241,7 @@ Finally, the validator needs to verify the Balance and Binding Signature by addi 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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt. -**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. +**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, the unshielding is not not be possible for custom assets. ZSA Transaction Structure ========================= @@ -271,6 +276,10 @@ Security and Privacy - When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design - We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state +Deplopyment +----------- +The Zcash Shielded Assets protocol should be deployed by replacing the Orchard protocol in a subsequent Network Upgrade. The design of this protocol ensures that there is no need to use any turnstile mechanism, being that Orchard-based ZEC notes can be used directly within the ZSA Actions. + Test Vectors ============ @@ -282,11 +291,6 @@ Reference Implementation - LINK TBD - LINK TBD -Deployment -========== - -This ZIP is proposed to activate with Network Upgrade 6. - References ========== From 01feec42d5b9abce6d4fe0ddce5b294ef649a58e Mon Sep 17 00:00:00 2001 From: daniben31 Date: Mon, 28 Nov 2022 12:48:02 +0100 Subject: [PATCH 011/101] fixes issuance zip and removes draft- prefix --- draft-ZIP-0226.html | 523 -------------------------------------------- draft-ZIP-0226.rst | 311 -------------------------- draft-ZIP-0227.html | 218 ------------------ draft-ZIP-0227.rst | 184 ---------------- zip-0226.html | 519 ++++++++++++++++++++++++++++++++++++++++++- zip-0226.rst | 310 +++++++++++++++++++++++++- zip-0227.html | 239 +++++++++++++++++++- zip-0227.rst | 214 +++++++++++++++++- 8 files changed, 1266 insertions(+), 1252 deletions(-) delete mode 100644 draft-ZIP-0226.html delete mode 100644 draft-ZIP-0226.rst delete mode 100644 draft-ZIP-0227.html delete mode 100644 draft-ZIP-0227.rst diff --git a/draft-ZIP-0226.html b/draft-ZIP-0226.html deleted file mode 100644 index aca617ec7..000000000 --- a/draft-ZIP-0226.html +++ /dev/null @@ -1,523 +0,0 @@ - - - - Draft ZIP-0226: Transfer and Burn of Zcash Shielded Assets - - - - -
- 
ZIP: 226
-Title: Transfer and Burn of Zcash Shielded Assets
-Owners: Daniel Benarroch <daniel@qed-it.com>
-        Pablo Kogan <pablo@qed-it.com>
-        Aurelien Nicolas <aurel@qed-it.com>
-Credits: Daira Hopwood
-         Jack Grigg
-         Shahaf Nacshon
-         Vivek Arte
-Status: Draft
-Category: Consensus
-Created: 2022-05-01
-License: MIT
-Discussions-To: <https://github.com/zcash/zips/issues/618>
-

Terminology

-

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

-

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

-

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

-

We define the following additional terms:

-
    -
  • Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
    • -
  • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool.
    • -
  • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
    • -
-
-

Abstract

-

ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

-
-

Motivation

-

The current Orchard protocol does not support custom assets, which is an important aspect for the proper evolution of the Zcash ecosystem. 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.

-
-

Overview

-

In order to be able to represent different asset types in Orchard, one needs to define a new data field that uniquely represents the type of the asset in question, which we call - \(\mathsf{type}\) - .

-

The type will be used to enforce the balance of an action description 6 is preserved across assets (see the Orchard Binding Signature 7 , and by extension of an Orchard transaction. Mainly, the sum of all the - \(\mathsf{value^{net}}\) - , as - \(\mathsf{value^{old}-value^{new}}\) - , derived from each action description, must be balanced only with respect to the same asset type. This is specially important since we will allow different action descriptions to transfer notes of different asset types, where the overall balance is checked without revealing which assets (or how many different types) are being transferred.

-

As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, - \(\mathcal{V}^{\mathsf{Orchard}}\) - , in the Homomorphic Pedersen Commitment that generates 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 types in the transaction. We propose to make the - \(\mathsf{type}\) - identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same - \(\mathsf{type}\) - is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature.

-

In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF.

-

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 than what is used in Orchard to unshield ZEC, by using the - \(\mathsf{valueBalance}\) - of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets.

-
-

Orchard Protocol Changes

-

Most of the protocol is kept the same as the Orchard protocol released with NU5, except the following that will be deployed to mainnet in subsequent network upgrades.

-

Asset Types

-

In the OSA protocol, we include a new variable, the asset type identifier, - \(\mathsf{type}\) - , which is generated as a 32-byte string during issuance (as described in the Issuance ZIP 5). The - \(\mathsf{type}\) - will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the - \(\mathsf{GroupHash}\) - function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see.

-

We denote the string as - \(\mathsf{type}\) - and we denote the equivalent group representation as - \(\mathsf{type}_{\mathbb{G}}\) - when mapped into a specific group, - \(\mathbb{G}\) - . Note that the type of the ZEC asset will be kept as the original value base-point, - \(\mathcal{V}^\mathsf{Orchard}\) -

-

In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one.

-
-

Note Structure & Commitment

-

First, we need to adapt the components that define the assets, i.e.: notes. A ZSA note differs from an Orchard note by including the type of asset, - \(\mathsf{type}_\mathbb{P}\) - . So an ZSA note looks like:

-

- \((\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})\) -

-

Where - \(\mathsf{type}_\mathbb{P}\) - is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

-

In this case, the note commitment, - \(\mathsf{NoteCommit^{ZSA}_{rcm}}\) - , will differ from - \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification.

-

Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have

-

- \(\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}\) -

-

The nullifier is generated in the same manner as in the Orchard protocol.

-
-

Value Commitment

-

The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

-

- \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) -

-

Where - \(\mathsf{v^{net} = v^{old} - v^{new}}\) - and

-

- \(\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}\) -

-

- \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}\) -

-

In the case of the Orchard protocol, we see that the base points - \(\mathcal{V}^{\mathsf{Orchard}}\) - and - \(\mathcal{R}^{\mathsf{Orchard}}\) - are fixed for every value commitment, as the values represent the amount of ZEC being transferred.

-

In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a different value base point. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes

-

- \(\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) -

-

where - \(\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}\) - such that - \(\mathsf{v^*_{type}}\) - is the value of the note of type - \(\mathsf{type}\) - , and

-

- \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",type\_params)}\) -

-

- \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) -

-

Where - \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}\) - .

-
-

Value Balance Verification

-

In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, - \(\mathsf{v^{balanceOrchard}}\) - , so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below.

-

For a total of - \(m\) - actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

-

- \(\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,m\}}} \mathsf{rcv_{i}}\) -

-

Then we have that the verifier computes

-

- \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) -

-

And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

-

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 all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out per asset type, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

-
-

Split Notes

-

One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a dummy spend note 12. Basically, the input note is “faked” inside of the proof in order to hide which action contains the real spend note.

-

This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions cannot be of any asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

-

In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

-

Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification:

-
    -
  1. The split input note could be the same note as the original (non-split) Action,
    2. -
  2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent)
    3. -
  3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending)
    4. -
-

The specific circuit changes are presented below.

-
-
-

Circuit Statement

-

The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset type system.

-

Asset Type Equality: the following constraints must be added to ensure that the input and output note are of the same type:

-
    -
  • The asset type, - \(\mathsf{type_\mathbb{P}}\) - , for the note is witnessed once, as an auxiliary input.
    • -
  • The witnessed asset type, - \(\mathsf{type_\mathbb{P}}\) - , is added to the old note commitment input.
    • -
  • The witnessed asset type, - \(\mathsf{type_\mathbb{P}}\) - , is added to the new note commitment input.
    • -
-

Correct Value Commitment Type: the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes

-
    -
  • The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:mathsf{cv}, is replaced with a variable-base multiplication between the two
    • -
  • The witness to the value base-point is the auxiliary input - \(\mathsf{type}_\mathbb{P}\) - .
    • -
-

Enforce Secure Type for Split Actions: the following constraints must be added to prevent senders from malling with the asset type for the output note in the consequent actions of the split:

-
    -
  • -
    -
    The Value Commitment Integrity should be changed
    -
    -
      -
    • Replace the input note value by a generic value, v', as - \(\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})\) -
      • -
    -
    -
    -
    • -
  • -
    -
    Add a boolean “split” variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
    -
    -
      -
    • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input
      • -
    -
    -
    -
    • -
  • -
    -
    The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes):
    -
    -
      -
    • Check that (path, pos) is a valid Merkle path of depth - \(\mathsf{MerkleDepth^Orchard}\) - , from - \(\mathsf{cm^old}\) - to the anchor - \(\mathsf{rt^Orchard}\) - .
      • -
    -
    -
    -
    • -
  • -
    -
    The Nullifier Integrity will be changed to prevent the identification of notes
    -
    -
      -
    • Replace the - \(\psi_{old}\) - value with a generic - \(\psi'\) - as - \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\) -
      • -
    • if split = 1 set - \(\psi' = \mathsf{randomSample}\) - , otherwise set - \(\psi' = \psi^{old}\) -
      • -
    -
    -
    -
    • -
-

Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes.

-

The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

-
    -
  • -
    -
    The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note)
    -
    -
      -
    • -
      -
      If the type auxiliary input is set - \(\mathsf{type}_\mathbb{P}\) - = - \(\mathcal{V}^\mathsf{Orchard}\) -
      -
      -
        -
      • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type)
        • -
      • This path also uses the original domain separator for ZEC note commitment
        • -
      -
      -
      -
      • -
    • -
      -
      Else,
      -
      -
        -
      • The NoteCommitment adds the type, - \(\mathsf{type}_\mathbb{P}\) - , as a final “chunk” of the Sinsemilla commitment
        • -
      • The NoteCommitment uses a different domain separator for ZSA note commitment
        • -
      -
      -
      -
      • -
    -
    -
    -
    • -
-

Backward Compatibility

-

In order to have a "clean" backwards 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: - The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree - 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

-
-
-

Burn Mechanism

-

The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

-

In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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.

-

First, contrary to the strict transfer transaction, we allow the sender to include a - \(\mathsf{valueBalvalueBalance_{type}}\) - variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular - \(\mathsf{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 - \((\mathsf{valueBalance_{type}, type}_\mathbb{P})\) - 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 types in the transfer.

-

- \(\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]\) -

-

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

-

Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows

-

- \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) -

-

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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt.

-

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, the unshielding is not not be possible for custom assets.

-
-

ZSA Transaction Structure

-

Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in 14:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BytesNameData TypeDescription
newActionSize * nActionsZSAvActionsZSAActionDescription[nActionOrchard]
variesnAssetBurncompactSizenumber of assets burnt
40*nAssetBurnvAssetBurnbytes[40][nAssetBurn]32 bytes asset type_t, 8 bytes of valueBalance
-
-

Other Considerations

-

Transaction Fees

-

In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on fees market on Zcash 15

-
-

Security and Privacy

-
    -
  • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • -
  • When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design
    • -
  • We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state
    • -
-
-
-

Test Vectors

-
    -
  • LINK TBD
    • -
-
-

Reference Implementation

-
    -
  • LINK TBD
    • -
  • LINK TBD
    • -
-
-

Deployment

-

This ZIP is proposed to activate with Network Upgrade 6.

-
-

References

- - - - - - - -
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
- - - - - - - -
2ZIP 200: Network Upgrade Mechanism
- - - - - - - -
3ZIP 224: Orchard
- - - - - - - -
4ZIP 226: Transfer and Burn of Zcash Shielded Assets
- - - - - - - -
5ZIP 227: Issuance of Zcash Shielded Assets
- - - - - - - -
6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
- - - - - - - -
7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)
- - - - - - - -
8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
- - - - - - - -
9Pallas/Vesta supporting evidence
- - - - - - - -
10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
- - - - - - - -
11Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
- - - - - - - -
12Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard)
- - - - - - - -
13Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
- - - - - - - -
14Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
- - - - - - - -
15A Study of Decentralized Markets on the Zcash Blockchain
-
-
-
-

Docutils System Messages

-
-

System Message: ERROR/3 (draft-ZIP-0226.rst line 52)

-

Too many autonumbered footnote references: only 0 corresponding footnotes available.

-
-
-

System Message: ERROR/3 (draft-ZIP-0226.rst line 52) id8

-

Unknown target name: "initial-zsa-issue".

-
-
- - \ No newline at end of file diff --git a/draft-ZIP-0226.rst b/draft-ZIP-0226.rst deleted file mode 100644 index f3b01838e..000000000 --- a/draft-ZIP-0226.rst +++ /dev/null @@ -1,311 +0,0 @@ -:: - - ZIP: 226 - Title: Transfer and Burn of Zcash Shielded Assets - Owners: Daniel Benarroch - Pablo Kogan - Aurelien Nicolas - Credits: Daira Hopwood - Jack Grigg - Shahaf Nacshon - Vivek Arte - Status: Draft - Category: Consensus - Created: 2022-05-01 - License: MIT - Discussions-To: - - -Terminology -=========== - -The key word "MUST" in this document is to be interpreted as described in RFC 2119 [#RFC2119]_. - -The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. - -The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. - -We define the following additional terms: - -- Asset: A type of note that can be transferred on the Zcash block chain. - - - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. - -- Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. -- Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. -- Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. -- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific type. The Split Note is not spent in the transaction. -- Split Action: a Zcash Shielded Asset Action that contains a Split Note. - -Abstract -======== - -ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the -Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined -in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. - -Motivation -========== - -The current Orchard protocol does not 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. - -Overview -======== -In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the *type* of the Asset in question, which we call :math:`\mathsf{type}`. - -The type will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset type**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset types, where the overall balance is checked without revealing which Assets (or how many different types) are being transferred. - -As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature. - -In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF. - -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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. - -Specification -============= - -Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following. - -Asset Types ------------ - -In the OSA protocol, we include a new variable, the asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the :math:`\mathsf{GroupHash}` -function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see. - -We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}` - -In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one. - -Note Structure & Commitment ---------------------------- - -First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: - - -:math:`(\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})` - - -Where :math:`\mathsf{type}_\mathbb{P}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. - -In this case, the note commitment, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification. - -Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have - - -:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}` - - -The nullifier is generated in the same manner as in the Orchard protocol. - -Value Commitment ----------------- - -The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ which is instantiated as - -:math:`\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` - -Where :math:`\mathsf{v^{net} = v^{old} - v^{new}}` and - -:math:`\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}` - -:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}` - -In the case of the Orchard protocol, we see that the base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and -:math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC -being transferred. - -In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes - - -:math:`\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` - - -where :math:`\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}` such that :math:`\mathsf{v^*_{type}}` is the value of the note of type :math:`\mathsf{type}`, and - -.. _valuebase: - -:math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",type\_params)}` - -:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` - -Where :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}`. - -Value Balance Verification --------------------------- - -In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in burnmechanism_. - -For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key - -:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}` - -Then we have that the verifier computes - -:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` - - -And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. - -As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, will only be valid (and hence verify the signature correctly, as long as all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out **per asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. - -Split Notes ------------ - -One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a *dummy spend note* [#protocol-dummynotes]_. Basically, the input note is “faked” inside of the proof in order to hide which action contains the *real* spend note. - -This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. - -In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. - -Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification: - -1. The split input note could be the same note as the original (non-split) Action, -2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent) -3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending) - -The specific circuit changes are presented below. - -Circuit Statement -================= - -The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset type system. - -**Asset Type Equality:** the following constraints must be added to ensure that the input and output note are of the -same type: - -- The asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. -- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. -- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. - -**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes - -- The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two -- The witness to the value base-point, as defined in valuebase_ is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. - -**Enforce Secure Type for Split Actions:** the following constraints must be added to prevent senders from changing the asset type for the output note in the Split Actions: - -- The Value Commitment Integrity should be changed - - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})` -- Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: - - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input -- The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): - - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. -- The Nullifier Integrity will be changed to prevent the identification of notes - - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - - if `split = 1` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` - -**Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. - -The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. - -- The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note) - - If the type auxiliary input is set :math:`\mathsf{type}_\mathbb{P}` = :math:`\mathcal{V}^\mathsf{Orchard}` - - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type) - - This path also uses the original domain separator for ZEC note commitment - - Else, - - The NoteCommitment adds the type, :math:`\mathsf{type}_\mathbb{P}`, as a final “chunk” of the Sinsemilla commitment - - The NoteCommitment uses a different domain separator for ZSA note commitment - - -Backward Compatibility ----------------------- - -In order to have a "clean" backwards 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: -- The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree -- 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 - -.. _burnmechanism: - -Burn Mechanism -============== -The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. - -In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. - -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{type}}` variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{type}, type}_\mathbb{P})` 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 types in the transfer. - - -:math:`\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]` - -The value balances for each asset type in `assetBurn` represents the amount of that asset type that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). - -Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows - -:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` - -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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt. - -**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, the unshielding is not not be possible for custom assets. - -ZSA Transaction Structure -========================= -Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in [#protocol-transactionstructure]_: - -+-----------------+-------------+-----------------------------------+-------------------------+ -| Bytes | Name | Data Type | Description | -+=================+=============+===================================+=========================+ -| newActionSize * | vActionsZSA | ActionDescription[nActionOrchard] | | -| nActionsZSA | | | | -+-----------------+-------------+-----------------------------------+-------------------------+ -| varies | nAssetBurn | compactSize | number of assets burnt | -+-----------------+-------------+-----------------------------------+-------------------------+ -| 40*nAssetBurn | vAssetBurn | bytes[40][nAssetBurn] | 32 bytes asset type_t, | -| | | | 8 bytes of valueBalance | -+-----------------+-------------+-----------------------------------+-------------------------+ - -Other Considerations -==================== - -Transaction Fees ----------------- - -In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as -the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on -fees market on Zcash [#fees-study-GMU]_ - -Security and Privacy --------------------- - -- Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. -- When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design -- We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state - -Deplopyment ------------ -The Zcash Shielded Assets protocol should be deployed by replacing the Orchard protocol in a subsequent Network Upgrade. The design of this protocol ensures that there is no need to use any turnstile mechanism, being that Orchard-based ZEC notes can be used directly within the ZSA Actions. - -Test Vectors -============ - -- LINK TBD - -Reference Implementation -======================== - -- LINK TBD -- LINK TBD - -References -========== - -.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ -.. [#zip-0224] `ZIP 224: Orchard `_ -.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ -.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ -.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ -.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ -.. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ -.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments `_ -.. [#protocol-concretevaluecommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ -.. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) `_ -.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ -.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ -.. [#fees-study-GMU] `A Study of Decentralized Markets on the Zcash Blockchain `_ diff --git a/draft-ZIP-0227.html b/draft-ZIP-0227.html deleted file mode 100644 index 8acd51d27..000000000 --- a/draft-ZIP-0227.html +++ /dev/null @@ -1,218 +0,0 @@ - - - - Draft ZIP-0227: Issuance of Zcash Shielded Assets - - - - -
- 
ZIP: 227
-Title: Issuance of Zcash Shielded Assets
-Owners: Daniel Benarroch <daniel@qed-it.com>
-        Pablo Kogan <pablo@qed-it.com>
-        Aurelien Nicolas <aurel@qed-it.com>
-Credits: Daira Hopwood
-         Jack Grigg
-         Shahaf Nacshon
-         Vivek Arte
-Status: Draft
-Category: Consensus
-Created: 2022-05-01
-License: MIT
-Discussions-To: <https://github.com/zcash/zips/issues/618>
-

Terminology

-

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

-

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

-

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

-

We define the following additional terms:

-
    -
  • Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
    • -
  • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool.
    • -
  • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
    • -
-
-

Abstract

-

ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

-
-

Motivation

-

The current Orchard protocol does not support custom assets, which is an important aspect for the proper evolution of the Zcash ecosystem. 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.

-
-

Overview & Rationale

-

This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work conjunction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

-

In short, we are going to enable only transparent issuance, since we believe that as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

-

We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple asset types (and allocate all of those too). Finally, a key component of our design is the finiteIssuance boolean that defines whether a specific asset type can have more tokens issued or not.

-

The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications:

-
    -
  • By setting the finiteIssuance = 1 from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
    • -
  • When the finiteIssuance = 0, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to 1 either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached.
    • -
  • Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset.
    • -
-
-

Asset Identifier Generation

-

For every new asset, there must be a new and unique identifier of the asset. Our design decision is not to have a chosen name for the asset type, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. From this asset identifier, which is a global byte string (valid across all Zcash protocols), we derive the specific type used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve)

-

The main requirement for the asset identifier is for it to be collision-free, as two different issuers should not be able to issue the same asset type. As such we need the asset identifier to be:

-
    -
  • pseudorandom
    • -
  • deterministic
    • -
  • dependent on the issuer ID
    • -
-

We define the asset identifier assetID (represented as a string) as

-

- \(\mathsf{assetID := GroupHash^{\mathbb{P}}}\mathsf{(issuerID || assetDesc)}\) -

-

where

-
    -
  • assetDesc is the asset description, which includes any information pertaining to the issuance.
    • -
  • issuerID is the public key of the issuer, used to verify the signature on the transaction and is defined as ik (issuer key or issuer verification key):
    • -
-

- \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\) -

-

which uses the same signature as the spend authorization signature, where isk is the issuer secret key. The verification key is derived from isk. In order to differentiate the isk and ik keys from the actual spend authorization key, we derive another branch of keys from the main spending key sk as such:

-

- \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}\) -

-

This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys in the wallet safe.

-

Then we let issuanceInfo := (assetID, finiteSupply), where

-
    -
  • assetID is as defined above.
    • -
  • -
    -
    finiteSupply is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once finiteSupply is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism:
    -
    -
      -
    • Provides assetID revocation in case of compromise (issue last issuance with 0 token value)
      • -
    • Supports NFT issuance (where the first issuance with value of 1 is also the last)
      • -
    -
    -
    -
    • -
-
-

Issuance Protocol

-

The issuance protocol allows for a single issuance to be sent to many receivers, as the issuerID does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets.

-
    -
  • The issuer knows in advance the receivers of the issued asset.
    • -
  • The asset is of non-fungible type, where each asset type can be made part of a single “series”
    • -
  • The supply of the asset is limited or not
    • -
  • The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it)
    • -
-

The protocol is as follows:

-
    -
  • -
    -
    For each asset type issued, generate a sequence of output notes, each with the following fields:
    -
    -
      -
    • ZSA output note - \(\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}\) - , where - \(\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}\) -
      • -
    -
    -
    -
    • -
  • Generate commitment of the note. cm as
    • -
-

- \(cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})\) -

-
    -
  • Sign the issuance note with the issuerID as the signing key, using RedPallas as its signature scheme, on the SIGHASH of the transaction. Note that the SIGHASH will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain.
    • -
-

Consensus Changes

-

Issuance requires the following additions to the global state:

-

First, Zcash clients must keep a mapping issuanceSupplyInfos from assetID to issuanceSupplyInfo := (totalSupply, finiteSupply).

-

Consensus rules

-

For each issuance instance,

-
    -
  • Check that assetID is properly constructed,
    • -
  • Check that each commitment cm is properly constructed from each “output” note,
    • -
  • Check that the issuance instance has a valid signature based on the issuerID,
    • -
  • Check that - \(\mathsf{type}_\mathbb{P}\) - is properly projected into the correct curve from assetID. That is, that - \(\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}\) -
    • -
  • If issuanceSupplyInfo[assetID].finiteSupply`is true, reject. Otherwise, set `issuanceSupplyInfo[assetID].finiteSupply = finiteSupply .
    • -
  • Add the sum of all the values in all output notes per assetID to issuanceSupplyInfo[assetID].totalSupply
    • -
  • After verification, add note commitment to the merkle tree.
    • -
-
-
-

Other Considerations

-

Fee Structures

-

The fee mechanism described in this ZIP may be replaced by a future “Fee Mechanism” ZIP proposal. However, we do need to have some basic fees for the Issuance protocol, as it differs from the usual transfer mechanism in that it adds a whole new structure to the transaction bundle, it adds a new global structure for validators to keep in memory and in turn it adds new consensus rules that are independent of previous structures.

-

There are two main factors that will affect the fee mechanism:

-
    -
  • The transaction size, which may take a big part of the block
    • -
  • The computational power needed to verify and mine the transaction
    • -
-

There is a single parameter that defines both, as there is no privacy or ZKP involved at this stage - the number of output notes in the issuance bundle:

-
    -
  • it trivially defines the bundle size
    • -
  • it defines the computational power as the validator must compute as many note commitments as there are output notes
    • -
-
-
-

Test Vectors

-
    -
  • LINK TBD
    • -
-
-

Reference Implementation

-
    -
  • LINK TBD
    • -
  • LINK TBD
    • -
-
-

Deployment

-

This ZIP is proposed to activate with Network Upgrade 6.

-
-

References

- - - - - - - -
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
- - - - - - - -
2ZIP 200: Network Upgrade Mechanism
- - - - - - - -
3ZIP 224: Orchard
- - - - - - - -
4ZIP 226: Transfer and Burn of Zcash Shielded Assets
- - - - - - - -
5ZIP 227: Issuance of Zcash Shielded Assets
-
-
- - \ No newline at end of file diff --git a/draft-ZIP-0227.rst b/draft-ZIP-0227.rst deleted file mode 100644 index 559d1ee8d..000000000 --- a/draft-ZIP-0227.rst +++ /dev/null @@ -1,184 +0,0 @@ -:: - - ZIP: 227 - Title: Issuance of Zcash Shielded Assets - Owners: Daniel Benarroch - Pablo Kogan - Aurelien Nicolas - Credits: Daira Hopwood - Jack Grigg - Shahaf Nacshon - Vivek Arte - Status: Draft - Category: Consensus - Created: 2022-05-01 - License: MIT - Discussions-To: - - -Terminology -=========== - -The key word "MUST" in this document is to be interpreted as described in RFC 2119 [#RFC2119]_. - -The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. - -The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. - -We define the following additional terms: - -- Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. -- Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard anonymity pool. -- Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. - -Abstract -======== - -ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the -Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined -in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. - -Motivation -========== - -The current Orchard protocol does not support custom assets, which is an important aspect for the proper -evolution of the Zcash ecosystem. 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. - -Overview & Rationale -==================== - -This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work conjunction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. - -In short, we are going to enable only *transparent* issuance, since we believe that as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. - -We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple asset types (and allocate all of those too). Finally, a key component of our design is the `finiteIssuance` boolean that defines whether a specific asset type can have more tokens issued or not. - -The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications: - -- By setting the `finiteIssuance = 1` from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. -- When the `finiteIssuance = 0`, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to `1` either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached. -- Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset. - - -Asset Identifier Generation -=========================== - -For every new asset, there must be a new and unique identifier of the asset. Our design decision is not to have a chosen name for the asset type, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. From this asset identifier, which is a global byte string (valid across all Zcash protocols), we derive the specific type used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve) - -The main requirement for the asset identifier is for it to be collision-free, as two different issuers should not be able to issue the same asset type. As such we need the asset identifier to be: - -- pseudorandom -- deterministic -- dependent on the issuer ID - -We define the asset identifier `assetID` (represented as a string) as - -:math:`\mathsf{assetID := GroupHash^{\mathbb{P}}}\mathsf{(issuerID || assetDesc)}` - -where - -- `assetDesc` is the asset description, which includes any information pertaining to the issuance. -- `issuerID` is the public key of the issuer, used to verify the signature on the transaction and is defined as `ik` (issuer key or issuer verification key): - - -:math:`\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}` - - -which uses the same signature as the spend authorization signature, where `isk` is the issuer secret key. The verification key is derived from `isk`. In order to differentiate the `isk` and `ik` keys from the actual spend authorization key, we derive another branch of keys from the main spending key `sk` as such: - -:math:`\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}` - -This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys in the wallet safe. - -Then we let `issuanceInfo := (assetID, finiteSupply)`, where - -- `assetID` is as defined above. -- `finiteSupply` is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once `finiteSupply` is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism: - - Provides `assetID` revocation in case of compromise (issue last issuance with 0 token value) - - Supports NFT issuance (where the first issuance with value of 1 is also the last) - - -Issuance Protocol -================= - -The issuance protocol allows for a single issuance to be sent to many receivers, as the issuerID does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets. - -- The issuer knows in advance the receivers of the issued asset. -- The asset is of non-fungible type, where each asset type can be made part of a single “series” -- The supply of the asset is limited or not -- The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) - -The protocol is as follows: - -- For each asset type issued, generate a sequence of output notes, each with the following fields: - - ZSA output note :math:`\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}`, where :math:`\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}` -- Generate commitment of the note. `cm` as - -:math:`cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})` - -- Sign the issuance note with the `issuerID` as the signing key, using RedPallas as its signature scheme, on the `SIGHASH` of the transaction. Note that the `SIGHASH` will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain. - -Consensus Changes ------------------ - -Issuance requires the following additions to the global state: - -First, Zcash clients must keep a mapping `issuanceSupplyInfos` from `assetID` to `issuanceSupplyInfo := (totalSupply, finiteSupply)`. - -**Consensus rules** - -For each issuance instance, - -- Check that `assetID` is properly constructed, -- Check that each commitment `cm` is properly constructed from each “output” note, -- Check that the issuance instance has a valid signature based on the `issuerID`, -- Check that :math:`\mathsf{type}_\mathbb{P}` is properly projected into the correct curve from `assetID`. That is, that :math:`\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}` -- If `issuanceSupplyInfo[assetID].finiteSupply`is true, reject. Otherwise, set `issuanceSupplyInfo[assetID].finiteSupply = finiteSupply` . -- Add the sum of all the values in all output notes per `assetID` to `issuanceSupplyInfo[assetID].totalSupply` -- After verification, add note commitment to the merkle tree. - -Other Considerations -==================== - -Fee Structures --------------- - -The fee mechanism described in this ZIP may be replaced by a future “Fee Mechanism” ZIP proposal. However, we do need to have some basic fees for the Issuance protocol, as it differs from the usual transfer mechanism in that it adds a whole new structure to the transaction bundle, it adds a new global structure for validators to keep in memory and in turn it adds new consensus rules that are independent of previous structures. - -There are two main factors that will affect the fee mechanism: - -- The transaction size, which may take a big part of the block -- The computational power needed to verify and mine the transaction - -There is a single parameter that defines both, as there is no privacy or ZKP involved at this stage - the number of output notes in the issuance bundle: - -- it trivially defines the bundle size -- it defines the computational power as the validator must compute as many note commitments as there are output notes - - -Test Vectors -============ - -- LINK TBD - -Reference Implementation -======================== - -- LINK TBD -- LINK TBD - -Deployment -========== - -This ZIP is proposed to activate with Network Upgrade 6. - -References -========== - -.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ -.. [#zip-0224] `ZIP 224: Orchard `_ -.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ -.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ \ No newline at end of file diff --git a/zip-0226.html b/zip-0226.html index ba83a8095..a8b569eab 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -1,17 +1,528 @@ - ZIP 226: Zcash Shielded Assets - Transfers and Burns + ZIP 226: Transfer and Burn of Zcash Shielded Assets + 
ZIP: 226
-Title: Zcash Shielded Assets - Transfers and Burns
-Owners: Daniel Bennaroch
-Status: Reserved
+Title: Transfer and Burn of Zcash Shielded Assets
+Owners: Daniel Benarroch <daniel@qed-it.com>
+        Pablo Kogan <pablo@qed-it.com>
+        Aurelien Nicolas <aurel@qed-it.com>
+Credits: Daira Hopwood
+         Jack Grigg
+         Shahaf Nacshon
+         Vivek Arte
+Status: Draft
 Category: Consensus
+Created: 2022-05-01
+License: MIT
 Discussions-To: <https://github.com/zcash/zips/issues/618>
+

Terminology

+

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

+

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

+

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

+

We define the following additional terms:

+
    +
  • Asset: A type of note that can be transferred on the Zcash block chain. +
      +
    • ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
      • +
    +
    • +
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
    • +
  • Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain.
    • +
  • Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain.
    • +
  • Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific type. The Split Note is not spent in the transaction.
    • +
  • Split Action: a Zcash Shielded Asset Action that contains a Split Note.
    • +
+
+

Abstract

+

ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

+
+

Motivation

+

The current Orchard protocol does not 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.

+
+

Overview

+

In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the type of the Asset in question, which we call + \(\mathsf{type}\) + .

+

The type will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), 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}-value^{new}}\) + , must be balanced only with respect to the same Asset type. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset types, where the overall balance is checked without revealing which Assets (or how many different types) are being transferred.

+

As was initially proposed by Jack Grigg and Daira Hopwood 16, we propose to make this happen by changing the value base point, + \(\mathcal{V}^{\mathsf{Orchard}}\) + , in the Homomorphic Pedersen Commitment that generates 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 types in the transaction. We propose to make the + \(\mathsf{type}\) + identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same + \(\mathsf{type}\) + is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature.

+

In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF.

+

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 than what is used in Orchard to unshield ZEC, by using the + \(\mathsf{valueBalance}\) + of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets.

+
+

Specification

+

Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.

+

Asset Types

+

In the OSA protocol, we include a new variable, the asset type identifier, + \(\mathsf{type}\) + , which is generated as a 32-byte string during issuance (as described in the Issuance ZIP 5). The + \(\mathsf{type}\) + will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the + \(\mathsf{GroupHash}\) + function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see.

+

We denote the string as + \(\mathsf{type}\) + and we denote the equivalent group representation as + \(\mathsf{type}_{\mathbb{G}}\) + when mapped into a specific group, + \(\mathbb{G}\) + . Note that the type of the ZEC asset will be kept as the original value base-point, + \(\mathcal{V}^\mathsf{Orchard}\) +

+

In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one.

+
+

Note Structure & Commitment

+

First, we need to adapt the components that define the assets, i.e.: notes. A ZSA note differs from an Orchard note by including the type of asset, + \(\mathsf{type}_\mathbb{P}\) + . So an ZSA note looks like:

+

+ \((\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})\) +

+

Where + \(\mathsf{type}_\mathbb{P}\) + is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

+

In this case, the note commitment, + \(\mathsf{NoteCommit^{ZSA}_{rcm}}\) + , will differ from + \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) + in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification.

+

Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have

+

+ \(\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}\) +

+

The nullifier is generated in the same manner as in the Orchard protocol.

+
+

Value Commitment

+

The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

+

+ \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) +

+

Where + \(\mathsf{v^{net} = v^{old} - v^{new}}\) + and

+

+ \(\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}\) +

+

+ \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}\) +

+

In the case of the Orchard protocol, we see that the base points + \(\mathcal{V}^{\mathsf{Orchard}}\) + and + \(\mathcal{R}^{\mathsf{Orchard}}\) + are fixed for every value commitment, as the values represent the amount of ZEC being transferred.

+

In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a different value base point. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes

+

+ \(\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) +

+

where + \(\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}\) + such that + \(\mathsf{v^*_{type}}\) + is the value of the note of type + \(\mathsf{type}\) + , and

+

+ \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || type\_params)}\) +

+

+ \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) +

+

Where + \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}\) + .

+
+

Value Balance Verification

+

In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, + \(\mathsf{v^{balanceOrchard}}\) + , so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in burnmechanism.

+

For a total of + \(n\) + actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

+

+ \(\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}\) +

+

Then we have that the verifier computes

+

+ \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) +

+

And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

+

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 all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out per asset type, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

+
+

Split Notes

+

One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a dummy spend note 12. Basically, the input note is “faked” inside of the proof in order to hide which action contains the real spend note.

+

This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions cannot be of any asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

+

In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

+

Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification:

+
    +
  1. The split input note could be the same note as the original (non-split) Action,
    2. +
  2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent)
    3. +
  3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending)
    4. +
+

The specific circuit changes are presented below.

+
+
+

Circuit Statement

+

The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset type system.

+

Asset Type Equality: the following constraints must be added to ensure that the input and output note are of the same type:

+
    +
  • The asset type, + \(\mathsf{type_\mathbb{P}}\) + , for the note is witnessed once, as an auxiliary input.
    • +
  • The witnessed asset type, + \(\mathsf{type_\mathbb{P}}\) + , is added to the old note commitment input.
    • +
  • The witnessed asset type, + \(\mathsf{type_\mathbb{P}}\) + , is added to the new note commitment input.
    • +
+

Correct Value Commitment Type: the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes

+
    +
  • The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:mathsf{cv}, is replaced with a variable-base multiplication between the two
    • +
  • The witness to the value base-point, as defined in valuebase is the auxiliary input + \(\mathsf{type}_\mathbb{P}\) + .
    • +
+

Enforce Secure Type for Split Actions: the following constraints must be added to prevent senders from changing the asset type for the output note in the Split Actions:

+
    +
  • +
    +
    The Value Commitment Integrity should be changed
    +
    +
      +
    • Replace the input note value by a generic value, v', as + \(\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})\) +
      • +
    +
    +
    +
    • +
  • +
    +
    Add a boolean “split” variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
    +
    +
      +
    • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input
      • +
    +
    +
    +
    • +
  • +
    +
    The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes):
    +
    +
      +
    • Check that (path, pos) is a valid Merkle path of depth + \(\mathsf{MerkleDepth^Orchard}\) + , from + \(\mathsf{cm^old}\) + to the anchor + \(\mathsf{rt^Orchard}\) + .
      • +
    +
    +
    +
    • +
  • +
    +
    The Nullifier Integrity will be changed to prevent the identification of notes
    +
    +
      +
    • Replace the + \(\psi_{old}\) + value with a generic + \(\psi'\) + as + \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\) +
      • +
    • if split = 1 set + \(\psi' = \mathsf{randomSample}\) + , otherwise set + \(\psi' = \psi^{old}\) +
      • +
    +
    +
    +
    • +
+

Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes.

+

The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

+
    +
  • +
    +
    The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note)
    +
    +
      +
    • +
      +
      If the type auxiliary input is set + \(\mathsf{type}_\mathbb{P}\) + = + \(\mathcal{V}^\mathsf{Orchard}\) +
      +
      +
        +
      • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type)
        • +
      • This path also uses the original domain separator for ZEC note commitment
        • +
      +
      +
      +
      • +
    • +
      +
      Else,
      +
      +
        +
      • The NoteCommitment adds the type, + \(\mathsf{type}_\mathbb{P}\) + , as a final “chunk” of the Sinsemilla commitment
        • +
      • The NoteCommitment uses a different domain separator for ZSA note commitment
        • +
      +
      +
      +
      • +
    +
    +
    +
    • +
+

Backward Compatibility

+

In order to have a "clean" backwards 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: - The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree - 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

+
+
+ +

Burn Mechanism

+

The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

+

In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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.

+

First, contrary to the strict transfer transaction, we allow the sender to include a + \(\mathsf{valueBalvalueBalance_{type}}\) + variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular + \(\mathsf{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 + \((\mathsf{valueBalance_{type}, type}_\mathbb{P})\) + 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 types in the transfer.

+

+ \(\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]\) +

+

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

+

Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows

+

+ \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) +

+

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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt.

+

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, the unshielding is not not be possible for custom assets.

+
+

ZSA Transaction Structure

+

Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in 14:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BytesNameData TypeDescription
newActionSize * nActionsZSAvActionsZSAActionDescription[nActionOrchard]
variesnAssetBurncompactSizenumber of assets burnt
40*nAssetBurnvAssetBurnbytes[40][nAssetBurn]32 bytes asset type_t, 8 bytes of valueBalance
+
+

Other Considerations

+

Transaction Fees

+

In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on fees market on Zcash 15

+
+

Security and Privacy

+
    +
  • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • +
  • When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design
    • +
  • We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state
    • +
+
+

Deplopyment

+

The Zcash Shielded Assets protocol should be deployed by replacing the Orchard protocol in a subsequent Network Upgrade. The design of this protocol ensures that there is no need to use any turnstile mechanism, being that Orchard-based ZEC notes can be used directly within the ZSA Actions.

+
+
+

Test Vectors

+
    +
  • LINK TBD
    • +
+
+

Reference Implementation

+
    +
  • LINK TBD
    • +
  • LINK TBD
    • +
+
+

References

+ + + + + + + +
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
3ZIP 224: Orchard
+ + + + + + + +
4ZIP 226: Transfer and Burn of Zcash Shielded Assets
+ + + + + + + +
5ZIP 227: Issuance of Zcash Shielded Assets
+ + + + + + + +
6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
+ + + + + + + +
7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)
+ + + + + + + +
8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
+ + + + + + + +
9Pallas/Vesta supporting evidence
+ + + + + + + +
10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
+ + + + + + + +
11Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
+ + + + + + + +
12Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard)
+ + + + + + + +
13Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
+ + + + + + + +
14Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
+ + + + + + + +
15A Study of Decentralized Markets on the Zcash Blockchain
+ + + + + + + +
16User-Defined Assets and Wrapped Assets
+
\ No newline at end of file diff --git a/zip-0226.rst b/zip-0226.rst index 685191a53..f5e8e2320 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -1,8 +1,312 @@ :: ZIP: 226 - Title: Zcash Shielded Assets - Transfers and Burns - Owners: Daniel Bennaroch - Status: Reserved + Title: Transfer and Burn of Zcash Shielded Assets + Owners: Daniel Benarroch + Pablo Kogan + Aurelien Nicolas + Credits: Daira Hopwood + Jack Grigg + Shahaf Nacshon + Vivek Arte + Status: Draft Category: Consensus + Created: 2022-05-01 + License: MIT Discussions-To: + + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as described in RFC 2119 [#RFC2119]_. + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. + +The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. + +We define the following additional terms: + +- Asset: A type of note that can be transferred on the Zcash block chain. + + - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. + +- Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. +- Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. +- Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. +- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific type. The Split Note is not spent in the transaction. +- Split Action: a Zcash Shielded Asset Action that contains a Split Note. + +Abstract +======== + +ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the +Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined +in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. + +Motivation +========== + +The current Orchard protocol does not 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. + +Overview +======== +In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the *type* of the Asset in question, which we call :math:`\mathsf{type}`. + +The type will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset type**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset types, where the overall balance is checked without revealing which Assets (or how many different types) are being transferred. + +As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature. + +In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF. + +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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. + +Specification +============= + +Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following. + +Asset Types +----------- + +In the OSA protocol, we include a new variable, the asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the :math:`\mathsf{GroupHash}` +function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see. + +We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}` + +In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one. + +Note Structure & Commitment +--------------------------- + +First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: + + +:math:`(\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})` + + +Where :math:`\mathsf{type}_\mathbb{P}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. + +In this case, the note commitment, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification. + +Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have + + +:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}` + + +The nullifier is generated in the same manner as in the Orchard protocol. + +Value Commitment +---------------- + +The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ which is instantiated as + +:math:`\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` + +Where :math:`\mathsf{v^{net} = v^{old} - v^{new}}` and + +:math:`\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}` + +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}` + +In the case of the Orchard protocol, we see that the base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and +:math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC +being transferred. + +In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes + + +:math:`\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` + + +where :math:`\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}` such that :math:`\mathsf{v^*_{type}}` is the value of the note of type :math:`\mathsf{type}`, and + +.. _valuebase: + +:math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || type\_params)}` + +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` + +Where :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}`. + +Value Balance Verification +-------------------------- + +In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in burnmechanism_. + +For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key + +:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}` + +Then we have that the verifier computes + +:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` + + +And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. + +As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, will only be valid (and hence verify the signature correctly, as long as all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out **per asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. + +Split Notes +----------- + +One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a *dummy spend note* [#protocol-dummynotes]_. Basically, the input note is “faked” inside of the proof in order to hide which action contains the *real* spend note. + +This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. + +In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. + +Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification: + +1. The split input note could be the same note as the original (non-split) Action, +2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent) +3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending) + +The specific circuit changes are presented below. + +Circuit Statement +================= + +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset type system. + +**Asset Type Equality:** the following constraints must be added to ensure that the input and output note are of the +same type: + +- The asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. +- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. +- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. + +**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes + +- The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two +- The witness to the value base-point, as defined in valuebase_ is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. + +**Enforce Secure Type for Split Actions:** the following constraints must be added to prevent senders from changing the asset type for the output note in the Split Actions: + +- The Value Commitment Integrity should be changed + - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})` +- Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: + - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input +- The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): + - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. +- The Nullifier Integrity will be changed to prevent the identification of notes + - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` + - if `split = 1` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` + +**Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. + +The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. + +- The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note) + - If the type auxiliary input is set :math:`\mathsf{type}_\mathbb{P}` = :math:`\mathcal{V}^\mathsf{Orchard}` + - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type) + - This path also uses the original domain separator for ZEC note commitment + - Else, + - The NoteCommitment adds the type, :math:`\mathsf{type}_\mathbb{P}`, as a final “chunk” of the Sinsemilla commitment + - The NoteCommitment uses a different domain separator for ZSA note commitment + + +Backward Compatibility +---------------------- + +In order to have a "clean" backwards 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: +- The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree +- 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 + +.. _burnmechanism: + +Burn Mechanism +============== +The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. + +In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. + +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{type}}` variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{type}, type}_\mathbb{P})` 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 types in the transfer. + + +:math:`\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]` + +The value balances for each asset type in `assetBurn` represents the amount of that asset type that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). + +Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows + +:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` + +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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt. + +**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, the unshielding is not not be possible for custom assets. + +ZSA Transaction Structure +========================= +Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in [#protocol-transactionstructure]_: + ++-----------------+-------------+-----------------------------------+-------------------------+ +| Bytes | Name | Data Type | Description | ++=================+=============+===================================+=========================+ +| newActionSize * | vActionsZSA | ActionDescription[nActionOrchard] | | +| nActionsZSA | | | | ++-----------------+-------------+-----------------------------------+-------------------------+ +| varies | nAssetBurn | compactSize | number of assets burnt | ++-----------------+-------------+-----------------------------------+-------------------------+ +| 40*nAssetBurn | vAssetBurn | bytes[40][nAssetBurn] | 32 bytes asset type_t, | +| | | | 8 bytes of valueBalance | ++-----------------+-------------+-----------------------------------+-------------------------+ + +Other Considerations +==================== + +Transaction Fees +---------------- + +In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as +the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on +fees market on Zcash [#fees-study-GMU]_ + +Security and Privacy +-------------------- + +- Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. +- When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design +- We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state + +Deplopyment +----------- +The Zcash Shielded Assets protocol should be deployed by replacing the Orchard protocol in a subsequent Network Upgrade. The design of this protocol ensures that there is no need to use any turnstile mechanism, being that Orchard-based ZEC notes can be used directly within the ZSA Actions. + +Test Vectors +============ + +- LINK TBD + +Reference Implementation +======================== + +- LINK TBD +- LINK TBD + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0224] `ZIP 224: Orchard `_ +.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ +.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ +.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments `_ +.. [#protocol-concretevaluecommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ +.. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) `_ +.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ +.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ +.. [#fees-study-GMU] `A Study of Decentralized Markets on the Zcash Blockchain `_ +.. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ diff --git a/zip-0227.html b/zip-0227.html index 0fb3b24e0..990b12deb 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -1,17 +1,246 @@ - ZIP 227: Zcash Shielded Assets - Issuance + ZIP 227: Issuance of Zcash Shielded Assets +
- 
ZIP: 226
-Title: Zcash Shielded Assets - Issuance
-Owners: Daniel Bennaroch
-Status: Reserved
+        
ZIP: 227
+Title: Issuance of Zcash Shielded Assets
+Owners: Daniel Benarroch <daniel@qed-it.com>
+        Pablo Kogan <pablo@qed-it.com>
+        Aurelien Nicolas <aurel@qed-it.com>
+Credits: Daira Hopwood
+         Jack Grigg
+         Shahaf Nacshon
+         Vivek Arte
+Status: Draft
 Category: Consensus
+Created: 2022-05-01
+License: MIT
 Discussions-To: <https://github.com/zcash/zips/issues/618>

+        
TODO 

+            
    
+                
  • [x] change all issuerID to issuanceValidatingKey
    • 
+                
  • [x] add definition of IssuanceAction & IssuanceBundle
    • 
+                
  • [ ] Add a section on the security model of the shielded assets
    • 
+                
  • [ ] review definitions of assets / zsa
    • 
+                
  • [ ] finish going through math derivation of assets
    • 
+            

+        

+        
Terminology 

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

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

+            
The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

+            
We define the following additional terms:

+            
    
+                
  • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (asset_id).
    • 
+                
  • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool.
    • 
+                
  • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
    • 
+                
  • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier.
    • 
+                
  • Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.
    • 
+            

+        

+        
Abstract 

+            
ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

+        

+        
Motivation 

+            
The current Orchard protocol does not 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.

+        

+        
Overview & Rationale 

+            
This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work in conjunction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

+            
In short, this ZIP enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

+            
We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple custom assets. Finally, a key component of our design is the finiteIssuance boolean that defines whether a specific custom asset can have further tokens issued or not.

+            
The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

+        

+        
Issuance keys 

+            
There are two keys relevant to the Issuer:

+            
    
+                
  1. The issuanceAuthorizingKey, denoted as isk, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer.
    2. 
+                
  2. The issuanceValidatingKey, denoted as ik, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners) to associate the asset in question with the issuer.
    3. 
+            

+            
The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, as described in ZIP 32 7. Specifically, we derive

+            
    
+                
  • The issuanceAuthorizingKey is derived directly from the spendingKey, sk, as a private signature key:
    • 
+            

+            

+                \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}\)
+            

+            
    
+                
  • The issuanceValidatingKey is derived from the issuanceAuthorizingKey, isk, as a public verification key:
    • 
+            

+            

+                \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
+            

+            
This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while keeping the rest of the keys in the wallet safe.

+        

+        
Asset Identifier Generation 

+            
For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols), of 256 bytes in size. From this asset descritpion, we derive the specific asset identifier, AssetId, used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

+            
The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, asset_id as follows:

+            

+                \(\mathsf{asset_id := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}\)
+            

+            
where

+            
    
+                
  • asset_desc is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. the asset description
    • 
+                
  • issuanceValidatingKey is the public key of the issuer, used to verify the signature on the transaction and is defined as ik (issuer key or issuer verification key):
    • 
+            

+            
Then we let issuanceInfo := (assetID, finiteSupply), where

+            
    
+                
  • assetID is as defined above.
    • 
+                
  • 
+                    
    
+                        
    finiteSupply is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once finiteSupply is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism:
    
+                        
    
+                            
      
+                                
    • Provides assetID revocation in case of compromise (issue last issuance with 0 token value)
      • 
+                                
    • Supports NFT issuance (where the first issuance with value of 1 is also the last)
      • 
+                            
    
+                        
    
+                    
    
+                
    • 
+            

+        

+        
Issuance Protocol 

+            
The issuance protocol allows for a single issuance to be sent to many receivers, as the issuanceValidatingKey does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets.

+            
    
+                
  • The issuer knows in advance the receivers of the issued asset.
    • 
+                
  • The asset is of non-fungible type, where each asset type can be made part of a single “series”
    • 
+                
  • The supply of the asset is limited or not
    • 
+                
  • The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it)
    • 
+            

+            
TODO: define IssueBundle as - ik - actions: - authorization: signature of the SIGHASH using the IssuanceSignatureKey

+            
TODO: define IssueAction as - asset_desc - notes - finalize boolean

+            
The protocol is as follows:

+            
    
+                
  • 
+                    
    
+                        
    For each asset type issued, generate a sequence of output notes, each with the following fields:
    
+                        
    
+                            
      
+                                
    • ZSA output note
+                                    \(\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}\)
+                                , where
+                                    \(\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}\)
+                                
      • 
+                            
    
+                        
    
+                    
    
+                
    • 
+                
  • Generate commitment of the note. cm as
    • 
+            

+            
NOTE that the commitment is not included in the IssuanceAction, but a computation done by the validators of the chain.

+            

+                \(cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})\)
+            

+            
    
+                
  • Sign the issuance note with the issuanceValidatingKey as the signing key, using RedPallas as its signature scheme, on the SIGHASH of the transaction. Note that the SIGHASH will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain.
    • 
+            

+            
Consensus Changes 

+                
Issuance requires the following additions to the global state: - previously_finalized, a set of asset_id that have been finalized (i.e.: the finalize flag has been set to 1).

+                
Consensus rules

+                
For the IssueBudnele, - Verify the signature on SIGHASH is valid, based on VerifySig.IssueAuthorization(ik, SIGHASH)

+                
For each IssueAction in a loop,

+                
    
+                    
  • check that asset_desc is properly constructed (not too short and not exceeding 512 bytes)
    • 
+                    
  • retrieve asset_id from first note and check that asset_id is properly constructed from asset_desc and ik, by checking the GroupHash of (ik, asset_desc)
    • 
+                    
  • check that the asset_id does not exist in the previously_finalized set
    • 
+                    
  • check that every note in the`IssueAction`` contains the same asset_id, and also that every note is properly constructed as note = (recipient, value, note(asset, rho, rseed)
    • 
+                    
  • If all of the above checks pass, do the following
    • 
+                    
  • For each note, compute the noteCommitment and
    • 
+                    
  • add noteCommitment to the Merkle tree of note commitments.
    • 
+                

+            

+            
Example applications 

+                
    
+                    
  • By setting the finiteIssuance = 1 from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
    • 
+                    
  • When the finiteIssuance = 0, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to 1 either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached.
    • 
+                    
  • Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset.
    • 
+                

+            

+        

+        
Other Considerations 

+            
Implementing Zcash clients 

+                
It is recommended that Zcash clients keep a mapping issuanceSupplyInfos from asset_id to issuanceSupplyInfo := (totalSupply, finalize) in order to properly keep track of the total supply for different asset types. This will be implemented in the Zcashd client.

+            

+            
Fee Structures 

+                
The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

+            

+        

+        
Test Vectors 

+            
    
+                
  • LINK TBD
    • 
+            

+        

+        
Reference Implementation 

+            
    
+                
  • LINK TBD
    • 
+                
  • LINK TBD
    • 
+            

+        

+        
Deployment 

+            
This ZIP is proposed to activate with Network Upgrade 6.

+        

+        
References 

+            
+                
+                    
+                        
+                        
+                    
+                
+            
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

+            
+                
+                    
+                        
+                        
+                    
+                
+            
2ZIP 200: Network Upgrade Mechanism

+            
+                
+                    
+                        
+                        
+                    
+                
+            
3ZIP 224: Orchard

+            
+                
+                    
+                        
+                        
+                    
+                
+            
4ZIP 226: Transfer and Burn of Zcash Shielded Assets

+            
+                
+                    
+                        
+                        
+                    
+                
+            
5ZIP 227: Issuance of Zcash Shielded Assets

+            
+                
+                    
+                        
+                        
+                    
+                
+            
6ZIP 317b: ZSA Extension Proportional Fee Mechanism

+            
+                
+                    
+                        
+                        
+                    
+                
+            
7ZIP 32: Shielded Hierarchical Deterministic Wallets

+
\ No newline at end of file diff --git a/zip-0227.rst b/zip-0227.rst index 0640d7039..dc29264c1 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -1,8 +1,214 @@ :: - ZIP: 226 - Title: Zcash Shielded Assets - Issuance - Owners: Daniel Bennaroch - Status: Reserved + ZIP: 227 + Title: Issuance of Zcash Shielded Assets + Owners: Daniel Benarroch + Pablo Kogan + Aurelien Nicolas + Credits: Daira Hopwood + Jack Grigg + Shahaf Nacshon + Vivek Arte + Status: Draft Category: Consensus + Created: 2022-05-01 + License: MIT Discussions-To: + + + +TODO +===== +- [x] change all issuerID to issuanceValidatingKey +- [x] add definition of IssuanceAction & IssuanceBundle +- [ ] Add a section on the security model of the shielded assets +- [ ] review definitions of assets / zsa +- [ ] finish going through math derivation of assets + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as described in RFC 2119 [#RFC2119]_. + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. + +The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. + +We define the following additional terms: + +- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (`asset_id`). +- Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool. +- Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. +- Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier. +- Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction. + +Abstract +======== + +ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. + +Motivation +========== + +The current Orchard protocol does not 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. + +Overview & Rationale +==================== + +This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work in conjunction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. + +In short, this ZIP enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. + +We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple custom assets. Finally, a key component of our design is the `finiteIssuance` boolean that defines whether a specific custom asset can have further tokens issued or not. + +The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. + + +Issuance keys +============= + +There are two keys relevant to the Issuer: + +1. The `issuanceAuthorizingKey`, denoted as `isk`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. + +2. The `issuanceValidatingKey`, denoted as `ik`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners) to associate the asset in question with the issuer. + +The two keys are derived in an analogous manner to the `spendAuthorizingKey` and `spendValidatingKey` keys, as described in ZIP 32 [#zip-0032]_. Specifically, we derive + +- The `issuanceAuthorizingKey` is derived directly from the `spendingKey`, `sk`, as a private signature key: + +:math:`\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}` + +- The `issuanceValidatingKey` is derived from the `issuanceAuthorizingKey`, `isk`, as a public verification key: + +:math:`\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}` + +This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while keeping the rest of the keys in the wallet safe. + +Asset Identifier Generation +=========================== + +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols), of 256 bytes in size. From this asset descritpion, we derive the specific asset identifier, `AssetId`, used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). + +The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, `asset_id` as follows: + +:math:`\mathsf{asset_id := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}` + +where + +- `asset_desc` is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. the asset description +- `issuanceValidatingKey` is the public key of the issuer, used to verify the signature on the transaction and is defined as `ik` (issuer key or issuer verification key): + + +Then we let `issuanceInfo := (assetID, finiteSupply)`, where + +- `assetID` is as defined above. +- `finiteSupply` is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once `finiteSupply` is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism: + - Provides `assetID` revocation in case of compromise (issue last issuance with 0 token value) + - Supports NFT issuance (where the first issuance with value of 1 is also the last) + + +Issuance Protocol +================= + +The issuance protocol allows for a single issuance to be sent to many receivers, as the issuanceValidatingKey does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets. + +- The issuer knows in advance the receivers of the issued asset. +- The asset is of non-fungible type, where each asset type can be made part of a single “series” +- The supply of the asset is limited or not +- The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) + +TODO: define IssueBundle as +- ik +- actions: +- authorization: signature of the SIGHASH using the IssuanceSignatureKey + +TODO: define IssueAction as +- asset_desc +- notes +- finalize boolean + + +The protocol is as follows: + +- For each asset type issued, generate a sequence of output notes, each with the following fields: + - ZSA output note :math:`\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}`, where :math:`\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}` +- Generate commitment of the note. `cm` as + +NOTE that the commitment is not included in the IssuanceAction, but a computation done by the validators of the chain. + +:math:`cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})` + +- Sign the issuance note with the `issuanceValidatingKey` as the signing key, using RedPallas as its signature scheme, on the `SIGHASH` of the transaction. Note that the `SIGHASH` will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain. + + +Consensus Changes +----------------- + +Issuance requires the following additions to the global state: +- `previously_finalized`, a set of `asset_id` that have been finalized (i.e.: the `finalize` flag has been set to `1`). + +**Consensus rules** + +For the IssueBudnele, +- Verify the signature on SIGHASH is valid, based on VerifySig.IssueAuthorization(ik, SIGHASH) + +For each IssueAction in a loop, + +- check that asset_desc is properly constructed (not too short and not exceeding 512 bytes) +- retrieve asset_id from first note and check that `asset_id` is properly constructed from asset_desc and ik, by checking the GroupHash of (ik, asset_desc) +- check that the `asset_id` does not exist in the `previously_finalized` set +- check that every note in the`IssueAction`` contains the same asset_id, and also that every note is properly constructed as `note = (recipient, value, note(asset, rho, rseed)` +- If all of the above checks pass, do the following + +- For each note, compute the `noteCommitment` and +- add `noteCommitment` to the Merkle tree of note commitments. + + +Example applications +-------------------- + +- By setting the `finiteIssuance = 1` from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. +- When the `finiteIssuance = 0`, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to `1` either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached. +- Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset. + +Other Considerations +==================== + +Implementing Zcash clients +-------------------------- + +It is recommended that Zcash clients keep a mapping `issuanceSupplyInfos` from `asset_id` to `issuanceSupplyInfo := (totalSupply, finalize)` in order to properly keep track of the total supply for different asset types. This will be implemented in the Zcashd client. + +Fee Structures +-------------- + +The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b [#zip-0317b]_. + +Test Vectors +============ + +- LINK TBD + +Reference Implementation +======================== + +- LINK TBD +- LINK TBD + +Deployment +========== + +This ZIP is proposed to activate with Network Upgrade 6. + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0224] `ZIP 224: Orchard `_ +.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ +.. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ +.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ \ No newline at end of file From 93a881f98978eb1d846cb807fef6c1ab2397d4e7 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 14:29:48 +0100 Subject: [PATCH 012/101] commits to create new branch --- zip-0226.rst | 8 +-- zip-0227.rst | 190 +++++++++++++++++++++++++++++++++++---------------- 2 files changed, 133 insertions(+), 65 deletions(-) diff --git a/zip-0226.rst b/zip-0226.rst index f5e8e2320..bc4ab4d1c 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -7,7 +7,6 @@ Aurelien Nicolas Credits: Daira Hopwood Jack Grigg - Shahaf Nacshon Vivek Arte Status: Draft Category: Consensus @@ -245,20 +244,19 @@ In the case that the balance of all the action values related to a specific asse ZSA Transaction Structure ========================= -Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in [#protocol-transactionstructure]_: +Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in [#protocol-transactionstructure]_: +-----------------+-------------+-----------------------------------+-------------------------+ | Bytes | Name | Data Type | Description | +=================+=============+===================================+=========================+ -| newActionSize * | vActionsZSA | ActionDescription[nActionOrchard] | | -| nActionsZSA | | | | -+-----------------+-------------+-----------------------------------+-------------------------+ | varies | nAssetBurn | compactSize | number of assets burnt | +-----------------+-------------+-----------------------------------+-------------------------+ | 40*nAssetBurn | vAssetBurn | bytes[40][nAssetBurn] | 32 bytes asset type_t, | | | | | 8 bytes of valueBalance | +-----------------+-------------+-----------------------------------+-------------------------+ +And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the `AssetId`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action. + Other Considerations ==================== diff --git a/zip-0227.rst b/zip-0227.rst index dc29264c1..4d9551f42 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -7,7 +7,6 @@ Aurelien Nicolas Credits: Daira Hopwood Jack Grigg - Shahaf Nacshon Vivek Arte Status: Draft Category: Consensus @@ -22,9 +21,11 @@ TODO - [x] change all issuerID to issuanceValidatingKey - [x] add definition of IssuanceAction & IssuanceBundle - [ ] Add a section on the security model of the shielded assets -- [ ] review definitions of assets / zsa -- [ ] finish going through math derivation of assets - +- [x] review definitions of assets / zsa +- [x] finish going through math derivation of assets +- [ ] add requirement: If you don't know the private key of the issuer of the asset type you should not be able to issue more notes of an asset type or change its finite issuance flag +- [ ] + Terminology =========== @@ -36,7 +37,7 @@ The term "Orchard" in this document is to be interpreted as described in ZIP 224 We define the following additional terms: -- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (`asset_id`). +- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (`AssetId`). - Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool. - Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. - Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier. @@ -53,32 +54,50 @@ Motivation The current Orchard protocol does not 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. -Overview & Rationale -==================== +Use Cases +========= + +The design presented in this ZIP enables several use cases for issuance of shielded assets. + +- The issuer knows in advance the receivers of the issued asset. +- The asset is of non-fungible type, where each asset type can be made part of a single “series” +- The supply of the asset is limited or not +- The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) + +Specification +============= + +As explained, the issuance protocol allows for a single issuance action to be sent to many receivers by mean of generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions. Thus we divide the protocol spec in two sections. + +Overview +-------- This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work in conjunction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. -In short, this ZIP enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. +In short, this ZIP enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. -We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple custom assets. Finally, a key component of our design is the `finiteIssuance` boolean that defines whether a specific custom asset can have further tokens issued or not. +The protocol was designed with three main properties in mind: +- at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private +- in a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets +- every issuance action contains the `finiteIssuance` boolean that defines whether that specific custom asset can have further tokens issued or not The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. -Issuance keys -============= +Issuance Keys +------------- There are two keys relevant to the Issuer: 1. The `issuanceAuthorizingKey`, denoted as `isk`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. -2. The `issuanceValidatingKey`, denoted as `ik`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners) to associate the asset in question with the issuer. +2. The `issuanceValidatingKey`, denoted as `ik`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners) to associate the asset in question with the issuer. We loosely call this key the "Issuer ID" -The two keys are derived in an analogous manner to the `spendAuthorizingKey` and `spendValidatingKey` keys, as described in ZIP 32 [#zip-0032]_. Specifically, we derive +The two keys are derived in an analogous manner to the `spendAuthorizingKey` and `spendValidatingKey` keys, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. Specifically, - The `issuanceAuthorizingKey` is derived directly from the `spendingKey`, `sk`, as a private signature key: -:math:`\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}` +:math:`\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])}` - The `issuanceValidatingKey` is derived from the `issuanceAuthorizingKey`, `isk`, as a public verification key: @@ -86,55 +105,81 @@ The two keys are derived in an analogous manner to the `spendAuthorizingKey` and This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while keeping the rest of the keys in the wallet safe. -Asset Identifier Generation -=========================== +Asset Identifier +---------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols), of 256 bytes in size. From this asset descritpion, we derive the specific asset identifier, `AssetId`, used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, `AssetId`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). -The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, `asset_id` as follows: +The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, `AssetId` as follows: -:math:`\mathsf{asset_id := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}` +:math:`\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}` where -- `asset_desc` is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. the asset description -- `issuanceValidatingKey` is the public key of the issuer, used to verify the signature on the transaction and is defined as `ik` (issuer key or issuer verification key): +- `asset_desc` is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance +- `issuanceValidatingKey` is the public key of the issuer, used to verify the signature on the transaction SIGHASH and is defined as `ik` +Global Issuance State +--------------------- -Then we let `issuanceInfo := (assetID, finiteSupply)`, where +Issuance requires the following additions to the global state: +- `previously_finalized`, a set of `AssetId` that have been finalized (i.e.: the `finalize` flag has been set to `1`). -- `assetID` is as defined above. -- `finiteSupply` is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once `finiteSupply` is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism: - - Provides `assetID` revocation in case of compromise (issue last issuance with 0 token value) - - Supports NFT issuance (where the first issuance with value of 1 is also the last) +Issuance Action Description +--------------------------- +An issuance action, `IssueAction`, is the instance of issuing a specific custom asset, and contains the following fields: +- `asset_desc`: the asset description, a UTF-8 encoded string of up to 512 bytes +- `notes`: an array containing the unencrypted output notes of the recipients of the asset, of type `Note` +- `finalize`: a boolean that defines whether the issuance of that specific custom asset is finalized or not -Issuance Protocol -================= +For assets whose `finalize = 1`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose `finalize = 0`, new issuance actions can be issued in future transactions. These must use the same asset description, `asset_desc`, and can either maintain `finalize = 0` or change it to `1`, denoting the last transaction containing issuance of such custom asset. + +================= ================== ========================== ======================================================================== +Size Name Data Type Description +================= ================== ========================== ======================================================================== +Varies asset_desc byte Uni-code encoded string of varied size, up to 512 bytes +Varies nNotes compactSize The number of notes in the issuance action +noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action +1 bit finalize boolean The boolean that determines the finality of the issuance of that asset +================= ================== ========================== ======================================================================== -The issuance protocol allows for a single issuance to be sent to many receivers, as the issuanceValidatingKey does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets. +We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the `NoteCommitmentTree` as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers. -- The issuer knows in advance the receivers of the issued asset. -- The asset is of non-fungible type, where each asset type can be made part of a single “series” -- The supply of the asset is limited or not -- The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) -TODO: define IssueBundle as -- ik -- actions: -- authorization: signature of the SIGHASH using the IssuanceSignatureKey -TODO: define IssueAction as -- asset_desc -- notes -- finalize boolean +Issuance Bundle +--------------- +An issuance bundle, `IssueBundle`, is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields: -The protocol is as follows: +- `ik`: the `issuanceValidatingKey`, that allows the validators to verify that the `AssetId` is properly associated with the issuer +- `actions`: an array of issuance actions, of type `IssueAction` +- `authorization`: the signature of the transaction SIGHASH, signed by the `issuanceAuthorizingKey`, `isk`, that validates the issuance + +The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format. + +======= ================== ========================== ======================================================================== +Bytes Name Data Type Description +======= ================== ========================== ======================================================================== +Varies nIssueActions compactSize The number of issuance actions in the bundle +Varies vIssueActions IssueAction[nIssueActions] A sequence of issuance actions descriptions +32 ik byte[32] The public key of the issuer +64 authorization byte[64] The signature of the transaction SIGHASH, signed by the issuer +======= ================== ========================== ======================================================================== + + + +Issuance Protocol +----------------- +The issuer program performs the following operations + +For all actions `IssueAction`: +- encode `asset_desc` as 512 byte-string +- compute `AssetId` as :math:`GroupHash^{\mathbb{P}}(ik || asset_desc)` +- For each recipient `i`: + - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, pkd_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` -- For each asset type issued, generate a sequence of output notes, each with the following fields: - - ZSA output note :math:`\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}`, where :math:`\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}` -- Generate commitment of the note. `cm` as NOTE that the commitment is not included in the IssuanceAction, but a computation done by the validators of the chain. @@ -142,21 +187,30 @@ NOTE that the commitment is not included in the IssuanceAction, but a computatio - Sign the issuance note with the `issuanceValidatingKey` as the signing key, using RedPallas as its signature scheme, on the `SIGHASH` of the transaction. Note that the `SIGHASH` will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain. +Concrete applications +--------------------- -Consensus Changes ------------------ +**Bridging Assets** +Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): +- First, the issuance and burn mechanism can be used in conjunction to determine the -Issuance requires the following additions to the global state: -- `previously_finalized`, a set of `asset_id` that have been finalized (i.e.: the `finalize` flag has been set to `1`). +Once `finiteSupply` is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism: + - Provides `AssetId` revocation in case of compromise (issue last issuance with a single output note of `value = 0`) + - Supports NFT issuance (where the first issuance with value of 1 is also the last) -**Consensus rules** +Here are some examples for how to use this protocol within an application: +- By setting the `finiteIssuance = 1` from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. +- When the `finiteIssuance = 0`, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to `1` either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached. +- Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset. -For the IssueBudnele, -- Verify the signature on SIGHASH is valid, based on VerifySig.IssueAuthorization(ik, SIGHASH) +Consensus Rule Changes +---------------------- -For each IssueAction in a loop, +For the IssueBundle, +- Verify the signature on SIGHASH is valid, based on `VerifySig.IssueAuthorization(ik, SIGHASH)` -- check that asset_desc is properly constructed (not too short and not exceeding 512 bytes) +For each `IssueAction` in `IssueBundle`: +- check that `asset_desc` is properly constructed: byte size > 0 exceeding 512 bytes) - retrieve asset_id from first note and check that `asset_id` is properly constructed from asset_desc and ik, by checking the GroupHash of (ik, asset_desc) - check that the `asset_id` does not exist in the `previously_finalized` set - check that every note in the`IssueAction`` contains the same asset_id, and also that every note is properly constructed as `note = (recipient, value, note(asset, rho, rseed)` @@ -165,17 +219,32 @@ For each IssueAction in a loop, - For each note, compute the `noteCommitment` and - add `noteCommitment` to the Merkle tree of note commitments. +Rationale +========= +The following is a list of rationale for different decisions made in the proposal: -Example applications --------------------- +- The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets. +- the `asset_desc` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: + - links for storage such as for NFTs + - other metadata for native assets + - bridging information for wrapped assets (chain of origin, issuer name, etc) + - information to be committed by the issuer, though not enforceable by the protocol +- -- By setting the `finiteIssuance = 1` from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. -- When the `finiteIssuance = 0`, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to `1` either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached. -- Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset. +Security and Privacy Considerations +=================================== + + we did not include a design that would allow for replacing the key of a specific asset. In case of compromise, the following actions are recommended: + - If an asset ID is compromised, the finalization boolean should be put to `0` and a new asset ID generated. + - If an issuer verification key is compromised, the finalization boolean should be put to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance). + +We note that for bridging purposes, the secure method of doing it is to burn an asset with the burning mechanism. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset. Other Considerations ==================== +When issuing assets on the Zcash block chain for a specific application in mind (i.e.: NFTs), the issuer should consider the full ZSA protocol to ensure + Implementing Zcash clients -------------------------- @@ -211,4 +280,5 @@ References .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ -.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ \ No newline at end of file +.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ +.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ \ No newline at end of file From 7a22ab3d57a0fd09b5f911279f0232c822eebec6 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 16:41:02 +0100 Subject: [PATCH 013/101] final isuance zip --- zip-0226.html | 10 +- zip-0227.html | 329 +++++++++++++++++++++++++++++++++----------------- zip-0227.rst | 124 +++++++++---------- 3 files changed, 281 insertions(+), 182 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index a8b569eab..c1e4c008a 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -14,7 +14,6 @@ Aurelien Nicolas <aurel@qed-it.com> Credits: Daira Hopwood Jack Grigg - Shahaf Nacshon Vivek Arte Status: Draft Category: Consensus @@ -335,7 +334,7 @@

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, the unshielding is not not be possible for custom assets.

ZSA Transaction Structure

-

Similar to NU5 transaction structure, with the following modifications to the Orchard bundle, as defined in 14:

+

Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

@@ -346,12 +345,6 @@ - - - - - - @@ -366,6 +359,7 @@
newActionSize * nActionsZSAvActionsZSAActionDescription[nActionOrchard]
varies nAssetBurn
+

And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the AssetId). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action.

Other Considerations

Transaction Fees

diff --git a/zip-0227.html b/zip-0227.html index 990b12deb..449571265 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -14,29 +14,19 @@ Aurelien Nicolas <aurel@qed-it.com> Credits: Daira Hopwood Jack Grigg - Shahaf Nacshon Vivek Arte Status: Draft Category: Consensus Created: 2022-05-01 License: MIT Discussions-To: <https://github.com/zcash/zips/issues/618> -

TODO

-
    -
  • [x] change all issuerID to issuanceValidatingKey
    • -
  • [x] add definition of IssuanceAction & IssuanceBundle
    • -
  • [ ] Add a section on the security model of the shielded assets
    • -
  • [ ] review definitions of assets / zsa
    • -
  • [ ] finish going through math derivation of assets
    • -
-

Terminology

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

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

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

We define the following additional terms:

    -
  • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (asset_id).
    • +
  • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (AssetId).
  • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool.
  • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
  • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier.
    • @@ -44,129 +34,236 @@

Abstract

-

ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

+

ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

Motivation

The current Orchard protocol does not 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.

-

Overview & Rationale

-

This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work in conjunction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

-

In short, this ZIP enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. In essence, any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

-

We have designed the protocol such that at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the corresponding addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. Furthermore, in a single issuance transaction, the issuer can create multiple custom assets. Finally, a key component of our design is the finiteIssuance boolean that defines whether a specific custom asset can have further tokens issued or not.

-

The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

-
-

Issuance keys

-

There are two keys relevant to the Issuer:

-
    -
  1. The issuanceAuthorizingKey, denoted as isk, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer.
    2. -
  2. The issuanceValidatingKey, denoted as ik, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners) to associate the asset in question with the issuer.
    3. -
-

The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, as described in ZIP 32 7. Specifically, we derive

-
    -
  • The issuanceAuthorizingKey is derived directly from the spendingKey, sk, as a private signature key:
    • -
-

- \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([10])}\) -

-
    -
  • The issuanceValidatingKey is derived from the issuanceAuthorizingKey, isk, as a public verification key:
    • -
-

- \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\) -

-

This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while keeping the rest of the keys in the wallet safe.

-
-

Asset Identifier Generation

-

For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols), of 256 bytes in size. From this asset descritpion, we derive the specific asset identifier, AssetId, used within the notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

-

The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, asset_id as follows:

-

- \(\mathsf{asset_id := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}\) -

-

where

-
    -
  • asset_desc is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. the asset description
    • -
  • issuanceValidatingKey is the public key of the issuer, used to verify the signature on the transaction and is defined as ik (issuer key or issuer verification key):
    • -
-

Then we let issuanceInfo := (assetID, finiteSupply), where

-
    -
  • assetID is as defined above.
    • -
  • -
    -
    finiteSupply is a boolean variable that defines whether this issuance transaction of the specific asset type is the final issuance of tokens or not. Once finiteSupply is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism:
    -
    -
      -
    • Provides assetID revocation in case of compromise (issue last issuance with 0 token value)
      • -
    • Supports NFT issuance (where the first issuance with value of 1 is also the last)
      • -
    -
    -
    -
    • -
-
-

Issuance Protocol

-

The issuance protocol allows for a single issuance to be sent to many receivers, as the issuanceValidatingKey does not have to match the address ownership of the notes output. Furthermore, every transaction can contain many issuance instances. The design presented in this ZIP enables several use cases for issuance of shielded assets.

+

Use Cases

+

The design presented in this ZIP enables issuance of shielded assets in various modes:

  • The issuer knows in advance the receivers of the issued asset.
  • The asset is of non-fungible type, where each asset type can be made part of a single “series”
  • The supply of the asset is limited or not
  • The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it)
-

TODO: define IssueBundle as - ik - actions: - authorization: signature of the SIGHASH using the IssuanceSignatureKey

-

TODO: define IssueAction as - asset_desc - notes - finalize boolean

-

The protocol is as follows:

-
    -
  • -
    -
    For each asset type issued, generate a sequence of output notes, each with the following fields:
    -
    -
      -
    • ZSA output note - \(\mathsf{ note =(d, pkd, v, \rho, \psi, \mathsf{type}_\mathbb{P}, rcm)}\) - , where - \(\mathsf{type}_\mathbb{P} := \mathsf{GroupHash^{\mathbb{P}}}\mathsf{(assetID)}\) -
      • -
    -
    -
    -
    • -
  • Generate commitment of the note. cm as
    • -
-

NOTE that the commitment is not included in the IssuanceAction, but a computation done by the validators of the chain.

-

- \(cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})\) -

+

See the Concrete Applications section for more details.

+
+

Requirements

    -
  • Sign the issuance note with the issuanceValidatingKey as the signing key, using RedPallas as its signature scheme, on the SIGHASH of the transaction. Note that the SIGHASH will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain.
    • +
  • Any user of the Zcash block chain can issue custom assets on chain
    • +
  • The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain
    • +
  • A user without knowledge of the private key of the issuer of a specific asset should not be able to issue that asset or change the attributes of such asset
    • +
  • The asset identification should be unique and different issuer keys should not be able to generate the same asset identifier
-

Consensus Changes

-

Issuance requires the following additions to the global state: - previously_finalized, a set of asset_id that have been finalized (i.e.: the finalize flag has been set to 1).

-

Consensus rules

-

For the IssueBudnele, - Verify the signature on SIGHASH is valid, based on VerifySig.IssueAuthorization(ik, SIGHASH)

-

For each IssueAction in a loop,

+
+

Specification

+

As explained, the issuance protocol allows for a single issuance action to be sent to many receivers by mean of generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions. Thus we divide the protocol spec in two sections.

+

Overview

+

In short, this specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

+

The protocol was designed with three main properties in mind: - at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private - in a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets - every issuance action contains the finiteIssuance boolean that defines whether that specific custom asset can have further tokens issued or not

+

The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

+
+

Issuance Keys

+

There are two keys relevant to the Issuer:

+
    +
  1. The issuanceAuthorizingKey, denoted as isk, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
    2. +
  2. The issuanceValidatingKey, denoted as ik, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
    3. +
+

The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8. Specifically,

    -
  • check that asset_desc is properly constructed (not too short and not exceeding 512 bytes)
    • -
  • retrieve asset_id from first note and check that asset_id is properly constructed from asset_desc and ik, by checking the GroupHash of (ik, asset_desc)
    • -
  • check that the asset_id does not exist in the previously_finalized set
    • -
  • check that every note in the`IssueAction`` contains the same asset_id, and also that every note is properly constructed as note = (recipient, value, note(asset, rho, rseed)
    • -
  • If all of the above checks pass, do the following
    • -
  • For each note, compute the noteCommitment and
    • -
  • add noteCommitment to the Merkle tree of note commitments.
    • +
  • The issuanceAuthorizingKey is derived directly from the spendingKey, sk, as a private signature key:
+

+ \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])}\) +

+
    +
  • The issuanceValidatingKey is derived from the issuanceAuthorizingKey, isk, as a public verification key:
    • +
+

+ \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\) +

+

This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

-

Example applications

+

Asset Identifier

+

For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, AssetId, is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

+

The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, AssetId as follows:

+

+ \(\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}\) +

+

where

    -
  • By setting the finiteIssuance = 1 from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
    • -
  • When the finiteIssuance = 0, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to 1 either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached.
    • -
  • Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset.
    • +
  • asset_desc is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance
    • +
  • issuanceValidatingKey is the public key of the issuer, used to verify the signature on the transaction SIGHASH and is defined as ik
+

Global Issuance State

+

Issuance requires the following additions to the global state: - previously_finalized, a set of AssetId that have been finalized (i.e.: the finalize flag has been set to 1).

+
+

Issuance Action Description

+

An issuance action, IssueAction, is the instance of issuing a specific custom asset, and contains the following fields: - asset_desc: the asset description, a UTF-8 encoded string of up to 512 bytes - notes: an array containing the unencrypted output notes of the recipients of the asset, of type Note - finalize: a boolean that defines whether the issuance of that specific custom asset is finalized or not

+

Once finiteSupply is set to 1, it cannot be unset. For assets whose finalize = 1, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose finalize = 0, new issuance actions can be issued in future transactions. These must use the same asset description, asset_desc, and can either maintain finalize = 0 or change it to 1, denoting the last transaction containing issuance of such custom asset.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SizeNameData TypeDescription
Variesasset_descbyteUni-code encoded string of varied size, up to 512 bytes
VariesnNotescompactSizeThe number of notes in the issuance action
noteSize * nNotesvNotesNote[nNotes]A sequence of note descriptions within the issuance action
1 bitfinalizebooleanThe boolean that determines the finality of the issuance of that asset
+

We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the NoteCommitmentTree as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers.

+
+

Issuance Bundle

+

An issuance bundle, IssueBundle, is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields:

+
    +
  • ik: the issuanceValidatingKey, that allows the validators to verify that the AssetId is properly associated with the issuer
    • +
  • actions: an array of issuance actions, of type IssueAction
    • +
  • authorization: the signature of the transaction SIGHASH, signed by the issuanceAuthorizingKey, isk, that validates the issuance
    • +
+

The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BytesNameData TypeDescription
VariesnIssueActionscompactSizeThe number of issuance actions in the bundle
VariesvIssueActionsIssueAction[nIssueActions]A sequence of issuance actions descriptions
32ikbyte[32]The public verification key of the issuer, used to validate the signature
64authorizationbyte[64]The signature of the transaction SIGHASH, signed by the issuer
+
+

Issuance Protocol

+

The issuer program performs the following operations

+

For all actions IssueAction: - encode asset_desc as 512 byte-string - compute AssetId as + \(GroupHash^{\mathbb{P}}(ik || asset_desc)\) + - set the finalize boolean as desired (if more more issuance actions are to be created for this asset identifier, set finalize = 0, otherwise set finalize = 1) - For each recipient i:

+
+

System Message: ERROR/3 (zip-0227.rst line 174)

+

Unexpected indentation.

+
+
+
    +
  • generate a ZSA output note as + \(\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}\) +
    • +
+
+
+

System Message: WARNING/2 (zip-0227.rst line 175)

+

Block quote ends without a blank line; unexpected unindent.

+
+
    +
  • encode the IssueAction into the vector vIssueActions of the bundle
    • +
+

For the IssueBundle: - encode the vIssueActions vector - encode the ik as 32 byte-string - sign the SIGHASH of the transaction with the issuanceAuthorizingKey, isk, using the RedPallas signature scheme. The signature is then added to the issuance bundle.

+

NOTE that the commitment is not included in the IssuanceAction itsefl. As explained below, it is later computed by the validators and added to the NoteCommitmentTree.

+
+

Concrete applications

+

Bridging Assets Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - First, the issuance and burn mechanism can be used in conjunction to determine the

+

Asset Features - By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,

+
+

System Message: ERROR/3 (zip-0227.rst line 194)

+

Unexpected indentation.

+
+
+
    +
  • by setting finalize = 1 from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
    • +
+
+
+

System Message: WARNING/2 (zip-0227.rst line 195)

+

Block quote ends without a blank line; unexpected unindent.

+
+
    +
  • Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by - issuing a last set of tokens of that specific AssetId, while at the same time setting finalize = 1, or by - issuing a transaction with a single note in the issuance action pertaining to that AssetId, where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations).
    • +
  • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each AssetId corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
    • +
+
+

Consensus Rule Changes

+

For the IssueBundle, - Verify the RedPallas-based issuance authorization signature on SIGHASH, authorization is valid, based on authorization.VerifySig(ik, SIGHASH)

+

For each IssueAction in IssueBundle: - check that asset_desc is a string with 0 < byte size <= 512 - retrieve AssetId from the first note in the sequence and check that AssetId = GroupHash^{mathbb{P}}(ik || asset_desc) is properly derived - check that the AssetId does not exist in the previously_finalized set in the global state - check that every note in the IssueAction contains the same AssetId and also that every note is of type Note and is properly constructed as + \(note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) +

+

If all of the above checks pass, do the following: - For each note, compute the note commitment as + \(cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) + and - add cm to the Merkle tree of note commitments, NoteCommitmentTree - If finalize = 1, add AssetId to the previously_finalized set in the global state

+
+
+

Rationale

+

The following is a list of rationale for different decisions made in the proposal:

+
    +
  • The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets.
    • +
  • the asset_desc is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: - links for storage such as for NFTs - other metadata for native assets - bridging information for wrapped assets (chain of origin, issuer name, etc) - information to be committed by the issuer, though not enforceable by the protocol
    • +
+
+

Security and Privacy Considerations

+

Issuer Key or AssetId Compromise

+

The design of this protocol does not allow for a rotation of the issuerValidatingKey, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: - If an asset ID is compromised (and not the issuer verification key), the finalize boolean for that asset should be set to 0 and a new AssetId generated instead. - If an issuer verification key is compromised, the finalize boolean for all the assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new AssetId.

+

Briding Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

Other Considerations

-

Implementing Zcash clients

-

It is recommended that Zcash clients keep a mapping issuanceSupplyInfos from asset_id to issuanceSupplyInfo := (totalSupply, finalize) in order to properly keep track of the total supply for different asset types. This will be implemented in the Zcashd client.

+

Implementing Zcash Nodes

+

Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping issuanceSupplyInfoMap from AssetId to issuanceSupplyInfoMap := (totalSupply, finalize) in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

Fee Structures

-

The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

+

The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

+
+

Future Work

+

In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying ik of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether.

Test Vectors

@@ -240,6 +337,14 @@ + + + + + + + +
8ZIP 316: Unified Addresses and Unified Viewing Keys
diff --git a/zip-0227.rst b/zip-0227.rst index 4d9551f42..489968002 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -13,18 +13,6 @@ Created: 2022-05-01 License: MIT Discussions-To: - - - -TODO -===== -- [x] change all issuerID to issuanceValidatingKey -- [x] add definition of IssuanceAction & IssuanceBundle -- [ ] Add a section on the security model of the shielded assets -- [x] review definitions of assets / zsa -- [x] finish going through math derivation of assets -- [ ] add requirement: If you don't know the private key of the issuer of the asset type you should not be able to issue more notes of an asset type or change its finite issuance flag -- [ ] Terminology =========== @@ -46,7 +34,7 @@ We define the following additional terms: Abstract ======== -ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. +ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. This ZIP must only be implemented in conjuction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. Motivation ========== @@ -57,13 +45,24 @@ bridging purposes. Use Cases ========= -The design presented in this ZIP enables several use cases for issuance of shielded assets. +The design presented in this ZIP enables issuance of shielded assets in various modes: - The issuer knows in advance the receivers of the issued asset. - The asset is of non-fungible type, where each asset type can be made part of a single “series” - The supply of the asset is limited or not - The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) +See the Concrete Applications section for more details. + +Requirements +============ + +- Any user of the Zcash block chain can issue custom assets on chain +- The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain +- A user without knowledge of the private key of the issuer of a specific asset should not be able to issue that asset or change the attributes of such asset +- The asset identification should be unique and different issuer keys should not be able to generate the same asset identifier + + Specification ============= @@ -72,9 +71,7 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -This ZIP specifies the issuance mechanism of the Zcash Shielded Assets (ZSA) protocol and must work in conjunction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. - -In short, this ZIP enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. +In short, this specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: - at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private @@ -83,17 +80,16 @@ The protocol was designed with three main properties in mind: The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. - Issuance Keys ------------- There are two keys relevant to the Issuer: -1. The `issuanceAuthorizingKey`, denoted as `isk`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. +1. The `issuanceAuthorizingKey`, denoted as `isk`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. -2. The `issuanceValidatingKey`, denoted as `ik`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners) to associate the asset in question with the issuer. We loosely call this key the "Issuer ID" +2. The `issuanceValidatingKey`, denoted as `ik`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. -The two keys are derived in an analogous manner to the `spendAuthorizingKey` and `spendValidatingKey` keys, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. Specifically, +The two keys are derived in an analogous manner to the `spendAuthorizingKey` and `spendValidatingKey` keys, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. - The `issuanceAuthorizingKey` is derived directly from the `spendingKey`, `sk`, as a private signature key: @@ -103,7 +99,7 @@ The two keys are derived in an analogous manner to the `spendAuthorizingKey` and :math:`\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}` -This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while keeping the rest of the keys in the wallet safe. +This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. Asset Identifier ---------------- @@ -133,7 +129,7 @@ An issuance action, `IssueAction`, is the instance of issuing a specific custom - `notes`: an array containing the unencrypted output notes of the recipients of the asset, of type `Note` - `finalize`: a boolean that defines whether the issuance of that specific custom asset is finalized or not -For assets whose `finalize = 1`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose `finalize = 0`, new issuance actions can be issued in future transactions. These must use the same asset description, `asset_desc`, and can either maintain `finalize = 0` or change it to `1`, denoting the last transaction containing issuance of such custom asset. +Once `finiteSupply` is set to 1, it cannot be unset. For assets whose `finalize = 1`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose `finalize = 0`, new issuance actions can be issued in future transactions. These must use the same asset description, `asset_desc`, and can either maintain `finalize = 0` or change it to `1`, denoting the last transaction containing issuance of such custom asset. ================= ================== ========================== ======================================================================== Size Name Data Type Description @@ -146,8 +142,6 @@ noteSize * nNotes vNotes Note[nNotes] A sequence of no We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the `NoteCommitmentTree` as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers. - - Issuance Bundle --------------- @@ -159,16 +153,14 @@ An issuance bundle, `IssueBundle`, is the aggregate of all the issuance-related The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format. -======= ================== ========================== ======================================================================== +======= ================== ========================== ========================================================================= Bytes Name Data Type Description -======= ================== ========================== ======================================================================== +======= ================== ========================== ========================================================================= Varies nIssueActions compactSize The number of issuance actions in the bundle Varies vIssueActions IssueAction[nIssueActions] A sequence of issuance actions descriptions -32 ik byte[32] The public key of the issuer +32 ik byte[32] The public verification key of the issuer, used to validate the signature 64 authorization byte[64] The signature of the transaction SIGHASH, signed by the issuer -======= ================== ========================== ======================================================================== - - +======= ================== ========================== ========================================================================= Issuance Protocol ----------------- @@ -177,15 +169,18 @@ The issuer program performs the following operations For all actions `IssueAction`: - encode `asset_desc` as 512 byte-string - compute `AssetId` as :math:`GroupHash^{\mathbb{P}}(ik || asset_desc)` +- set the `finalize` boolean as desired (if more more issuance actions are to be created for this asset identifier, set `finalize = 0`, otherwise set `finalize = 1`) - For each recipient `i`: - - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, pkd_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` - + - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` +- encode the `IssueAction` into the vector `vIssueActions` of the bundle -NOTE that the commitment is not included in the IssuanceAction, but a computation done by the validators of the chain. +For the `IssueBundle`: +- encode the `vIssueActions` vector +- encode the `ik` as 32 byte-string +- sign the `SIGHASH` of the transaction with the `issuanceAuthorizingKey`, `isk`, using the RedPallas signature scheme. The signature is then added to the issuance bundle. -:math:`cm = \mathsf{NoteCommit^{ZSA}_{rcm}}(\mathsf{repr\mathbb{_P}(g_d)}, \mathsf{repr\mathbb{_P}(pk_d)}, v, \rho, \psi,\mathsf{type}_\mathbb{P})` -- Sign the issuance note with the `issuanceValidatingKey` as the signing key, using RedPallas as its signature scheme, on the `SIGHASH` of the transaction. Note that the `SIGHASH` will change as we include a new bundle in the Zcash transaction to enable this issuance mechanism on chain. +NOTE that the commitment is not included in the `IssuanceAction` itsefl. As explained below, it is later computed by the validators and added to the `NoteCommitmentTree`. Concrete applications --------------------- @@ -194,30 +189,30 @@ Concrete applications Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - First, the issuance and burn mechanism can be used in conjunction to determine the -Once `finiteSupply` is set, it cannot be unset. This allows expanding the functionality of the issuance mechanism: - - Provides `AssetId` revocation in case of compromise (issue last issuance with a single output note of `value = 0`) - - Supports NFT issuance (where the first issuance with value of 1 is also the last) - -Here are some examples for how to use this protocol within an application: -- By setting the `finiteIssuance = 1` from the first issuance instance of that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. -- When the `finiteIssuance = 0`, the issuer can keep creating tokens of that type (in a transparent manner). The boolean value can be changed with any new issuance transaction, and could be set to `1` either when the issuer keys have been compromised, and hence stopping all issuances of that asset type (the boolean cannot be reversed), or whenever the issuer decides that the max supply has been reached. -- Note that this mechanism can be used with the burning process to control and affect the supply of any custom asset. +**Asset Features** +- By using the `finalize` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any asset associated to their issuer keys. For example, + - by setting `finalize = 1` from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. +- Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by + - issuing a last set of tokens of that specific `AssetId`, while at the same time setting `finalize = 1`, or by + - issuing a transaction with a single note in the issuance action pertaining to that `AssetId`, where the note will contain a `value = 0`. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations). +- Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each `AssetId` corresponds to `value = 1` at the fundamental unit level. Issuers and users should make sure that `finalize = 1` for each of the actions in this scenario. Consensus Rule Changes ---------------------- For the IssueBundle, -- Verify the signature on SIGHASH is valid, based on `VerifySig.IssueAuthorization(ik, SIGHASH)` +- Verify the RedPallas-based issuance authorization signature on `SIGHASH`, `authorization` is valid, based on `authorization.VerifySig(ik, SIGHASH)` For each `IssueAction` in `IssueBundle`: -- check that `asset_desc` is properly constructed: byte size > 0 exceeding 512 bytes) -- retrieve asset_id from first note and check that `asset_id` is properly constructed from asset_desc and ik, by checking the GroupHash of (ik, asset_desc) -- check that the `asset_id` does not exist in the `previously_finalized` set -- check that every note in the`IssueAction`` contains the same asset_id, and also that every note is properly constructed as `note = (recipient, value, note(asset, rho, rseed)` -- If all of the above checks pass, do the following +- check that `asset_desc` is a string with `0 < byte size <= 512` +- retrieve `AssetId` from the first note in the sequence and check that `AssetId = GroupHash^{\mathbb{P}}(ik || asset_desc)` is properly derived +- check that the `AssetId` does not exist in the `previously_finalized` set in the global state +- check that every note in the `IssueAction` contains the same `AssetId` and also that every note is of type `Note` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` -- For each note, compute the `noteCommitment` and -- add `noteCommitment` to the Merkle tree of note commitments. +If all of the above checks pass, do the following: +- For each note, compute the note commitment as :math:`cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` and +- add `cm` to the Merkle tree of note commitments, `NoteCommitmentTree` +- If `finalize = 1`, add `AssetId` to the `previously_finalized` set in the global state Rationale ========= @@ -229,32 +224,37 @@ The following is a list of rationale for different decisions made in the proposa - other metadata for native assets - bridging information for wrapped assets (chain of origin, issuer name, etc) - information to be committed by the issuer, though not enforceable by the protocol -- Security and Privacy Considerations =================================== - we did not include a design that would allow for replacing the key of a specific asset. In case of compromise, the following actions are recommended: - - If an asset ID is compromised, the finalization boolean should be put to `0` and a new asset ID generated. - - If an issuer verification key is compromised, the finalization boolean should be put to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance). +**Issuer Key or AssetId Compromise** + +The design of this protocol does not allow for a rotation of the `issuerValidatingKey`, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: +- If an asset ID is compromised (and not the issuer verification key), the `finalize` boolean for that asset should be set to `0` and a new `AssetId` generated instead. +- If an issuer verification key is compromised, the `finalize` boolean for all the assets issued with that key should be set to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new `AssetId`. -We note that for bridging purposes, the secure method of doing it is to burn an asset with the burning mechanism. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset. +**Briding Assets** +For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 [#zip-0226]_. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset. Other Considerations ==================== -When issuing assets on the Zcash block chain for a specific application in mind (i.e.: NFTs), the issuer should consider the full ZSA protocol to ensure - -Implementing Zcash clients --------------------------- +Implementing Zcash Nodes +------------------------ -It is recommended that Zcash clients keep a mapping `issuanceSupplyInfos` from `asset_id` to `issuanceSupplyInfo := (totalSupply, finalize)` in order to properly keep track of the total supply for different asset types. This will be implemented in the Zcashd client. +Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping `issuanceSupplyInfoMap` from `AssetId` to `issuanceSupplyInfoMap := (totalSupply, finalize)` in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets. Fee Structures -------------- The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b [#zip-0317b]_. +Future Work +----------- + +In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying `ik` of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether. + Test Vectors ============ From f4fbd5723c3214e80be168faebb8b63a23d5e859 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 16:50:22 +0100 Subject: [PATCH 014/101] issuance zip includes txid generation --- zip-0227.rst | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/zip-0227.rst b/zip-0227.rst index 489968002..e4625cff6 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -225,6 +225,81 @@ The following is a list of rationale for different decisions made in the proposa - bridging information for wrapped assets (chain of origin, issuer name, etc) - information to be committed by the issuer, though not enforceable by the protocol +TxId Digest +=========== +A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:: + + issuance_txid_digest + ├── issueActions + └── issuerVerificationKey + +In the specification below, nodes of the tree are presented in depth-first order. + +issuance_txid_digest +-------------------- +A BLAKE2b-256 hash of the following values :: + + T.1: issueActions (field encoding bytes) + T.2: issuerVerificationKey (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxIdOrcZSAIssue" + +T.1 issueActions +```````````````` +A byte encoding of Issue Action information for all Issue Actions belonging to the transaction. For each Action, the following elements are included in the hash:: + + T.1a: notes (field encoding bytes) + T.1b: assetDescription (field encoding bytes) + T.1c: isFinalized (1 byte) + + +T.1a: notes +''''''''''' +A byte encoding of Note information for all Notes belonging to the Action. For each Note, the following elements are included in the hash:: + + T.1a.1: recipient (field encoding bytes) + T.1a.2: value (field encoding bytes) + T.1a.3: asset (field encoding bytes) + T.1a.4: rho (field encoding bytes) + T.1a.5: rseed (field encoding bytes) + + +T.1a.1: recipient +................. +Raw Address encoded as specified in [Zcash Protocol Spec § 5.6.4.2: Orchard Raw Payment Addresses]. + +T.1a.2: value +............. +Note value encoded as little-endian 8-byte representation of u64 raw value. + +T.1a.3: asset +............. +Asset ID encoded as 32-byte representation of Pallas point. + +T.1a.4: rho +........... +Nullifier encoded as 32-byte representation of Pallas point. + +T.1a.5: rseed +............. +The ZIP 212 32-byte seed randomness for a note. + +T.1b: assetDescription +'''''''''''''''''''''' +UTF-8 encoding of the asset description string. + +T.1c: isFinalized +''''''''''''''''' +1-byte representation of a boolean flag that is set to 'true' if the asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. + + +T.2 issuerVerificationKey +````````````````````````` +A byte encoding of issuer verification key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components]. + + Security and Privacy Considerations =================================== From e6c6ad2e058bbcd3f558335b69bce02702d0328b Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 17:33:58 +0100 Subject: [PATCH 015/101] final version of transfer zip --- zip-0226.rst | 111 +++++++++++++++++++++++++-------------------------- 1 file changed, 55 insertions(+), 56 deletions(-) diff --git a/zip-0226.rst b/zip-0226.rst index bc4ab4d1c..1f40daa5e 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -26,14 +26,14 @@ The term "Orchard" in this document is to be interpreted as described in ZIP 224 We define the following additional terms: -- Asset: A type of note that can be transferred on the Zcash block chain. +- Asset: A type of note that can be transferred on the Zcash block chain, identified by the `AssetId` parameter. - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. - Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. -- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific type. The Split Note is not spent in the transaction. +- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific `AssetId`. The Split Note is not spent in the transaction. - Split Action: a Zcash Shielded Asset Action that contains a Split Note. Abstract @@ -50,15 +50,15 @@ The current Orchard protocol does not support custom assets. Enabling multi-asse Overview ======== -In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the *type* of the Asset in question, which we call :math:`\mathsf{type}`. +In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the `AssetId` of the Asset in question, which we call :math:`\mathsf{AssetId}`. -The type will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset type**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset types, where the overall balance is checked without revealing which Assets (or how many different types) are being transferred. +The asset identifier will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred. As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 types in the transaction. We propose to make the :math:`\mathsf{type}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{type}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are asset identifiers in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same `AssetId`, and (2) that only actions with the same asset identifier will balance out in the binding and balance signature. -In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF. +In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the `AssetId` of the output note of that split action is the output of a PRF. 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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. @@ -67,33 +67,32 @@ Specification Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following. -Asset Types ------------ +Asset Identifiers +----------------- -In the OSA protocol, we include a new variable, the asset type identifier, :math:`\mathsf{type}`, which is generated as a 32-byte string during issuance (as described in the Issuance ZIP [#zip-0227]_). The :math:`\mathsf{type}` will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the :math:`\mathsf{GroupHash}` -function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see. +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). -We denote the string as :math:`\mathsf{type}` and we denote the equivalent group representation as :math:`\mathsf{type}_{\mathbb{G}}` when mapped into a specific group, :math:`\mathbb{G}`. Note that the type of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}` +This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom asset. Note that the :math:`\mathsf{AssetId}` of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}`. -In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one. +In future network and protocol upgrades, the same asset description string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset identifier, :math:`\mathsf{AssetId}`, from one group to another one. Note Structure & Commitment --------------------------- -First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the type of asset, :math:`\mathsf{type}_\mathbb{P}`. So an ZSA note looks like: +First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the identifier of asset, :math:`\mathsf{AssetId}`. So an ZSA note looks like: -:math:`(\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})` +:math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` -Where :math:`\mathsf{type}_\mathbb{P}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. +Where :math:`\mathsf{AssetId}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. -In this case, the note commitment, :math:`\mathsf{NoteCommit^{ZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification. +In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the asset identifier will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have -:math:`\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}` +:math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \{\mathsf{cm},\bot\}` The nullifier is generated in the same manner as in the Orchard protocol. @@ -115,79 +114,79 @@ In the case of the Orchard protocol, we see that the base points :math:`\mathcal :math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC being transferred. -In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a **different value base point**. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes +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**. This enables the final balance of the transaction to be securely computed, such that each asset identifier is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes -:math:`\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` +:math:`\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` -where :math:`\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}` such that :math:`\mathsf{v^*_{type}}` is the value of the note of type :math:`\mathsf{type}`, and +where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^*_{AssetId}}` is the value of the note of identifier :math:`\mathsf{AssetId}`, and .. _valuebase: -:math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || type\_params)}` +:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || ik || \mathsf{asset_desc})}` :math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` -Where :math:`\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}`. +Where :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}`. Value Balance Verification -------------------------- -In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in burnmechanism_. +In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in burnmechanism_. For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key :math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}` -Then we have that the verifier computes +Then the verifier MUST compute :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. -As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, will only be valid (and hence verify the signature correctly, as long as all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out **per asset type**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. +As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset identifier**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. Split Notes ----------- -One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a *dummy spend note* [#protocol-dummynotes]_. Basically, the input note is “faked” inside of the proof in order to hide which action contains the *real* spend note. +One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. -This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions *cannot* be of *any* asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. +This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions *cannot* be of *any* asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. +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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. -Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification: +Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification: 1. The split input note could be the same note as the original (non-split) Action, -2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent) -3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending) +2. The split input note could be a different unspent note of the same `AssetId` (note that the note will not actually be spent) +3. The split input note could be an already spent note of the same `AssetId` (note that by zeroing the value in the circuit, we prevent double spending) The specific circuit changes are presented below. Circuit Statement ================= -The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset type system. +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset identifier system. -**Asset Type Equality:** the following constraints must be added to ensure that the input and output note are of the -same type: +**Asset Identifier Equality:** the following constraints must be added to ensure that the input and output note are of the +same `AssetId`: -- The asset type, :math:`\mathsf{type_\mathbb{P}}`, for the note is witnessed once, as an auxiliary input. -- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the old note commitment input. -- The witnessed asset type, :math:`\mathsf{type_\mathbb{P}}`, is added to the new note commitment input. +- The asset identifier, :math:`\mathsf{AssetId}`, for the note is witnessed once, as an auxiliary input. +- The witnessed asset identifier, :math:`\mathsf{AssetId}`, is added to the old note commitment input. +- The witnessed asset identifier, :math:`\mathsf{AssetId}`, is added to the new note commitment input. -**Correct Value Commitment Type:** the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes +**Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes - The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two -- The witness to the value base-point, as defined in valuebase_ is the auxiliary input :math:`\mathsf{type}_\mathbb{P}`. +- The witness to the value base-point, as defined in valuebase_ is the auxiliary input :math:`\mathsf{AssetId}`. -**Enforce Secure Type for Split Actions:** the following constraints must be added to prevent senders from changing the asset type for the output note in the Split Actions: +**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the asset identifier for the output note in the Split Actions: - The Value Commitment Integrity should be changed - - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})` + - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}` - Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input - The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): @@ -200,12 +199,12 @@ same type: The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. -- The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note) - - If the type auxiliary input is set :math:`\mathsf{type}_\mathbb{P}` = :math:`\mathcal{V}^\mathsf{Orchard}` - - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type) +- The input note in the old note commitment integrity must either include an asset identifier (ZSA note) or not (ZEC-Orchard note) + - If the asset identifier auxiliary input is set :math:`\mathsf{AssetId}` = :math:`\mathcal{V}^\mathsf{Orchard}` + - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the identifier) - This path also uses the original domain separator for ZEC note commitment - Else, - - The NoteCommitment adds the type, :math:`\mathsf{type}_\mathbb{P}`, as a final “chunk” of the Sinsemilla commitment + - The NoteCommitment adds the identfier, :math:`\mathsf{AssetId}`, as a final “chunk” of the Sinsemilla commitment - The NoteCommitment uses a different domain separator for ZSA note commitment @@ -213,7 +212,7 @@ Backward Compatibility ---------------------- In order to have a "clean" backwards 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: -- The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree +- The input notes with an asset identifer denote the ZSA custom assets, generating a note commitment that includes the asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the asset identifier, in order to maintain the referencability to the Merkle tree - 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 @@ -223,22 +222,22 @@ Burn Mechanism ============== The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. -In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. +In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{type}}` variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC asset. +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{AssetId}}` variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{type}, type}_\mathbb{P})` 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 types in the transfer. +For every custom asset that is burnt, we add to the `assetBurn` vector the tuple :math:`(\mathsf{valueBalance_{AssetId}, 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. -:math:`\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]` +:math:`\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]` -The value balances for each asset type in `assetBurn` represents the amount of that asset type that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). +The value balances for each asset identifier in `assetBurn` represents the amount of that asset identifier that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). -Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows +Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective `AssetId` as the value base point of the Pedersen Commitment. This is done as follows -:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` +:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` -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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt. +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, the number of assets, nor their identifiers will be revealed, except in the case that an asset is burnt. **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, the unshielding is not not be possible for custom assets. @@ -271,8 +270,8 @@ Security and Privacy -------------------- - Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. -- When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design -- We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state +- When including new assets we would like to maintain the amount and identifiers of assets private, which is achieved with the design +- We prevent the "roadblock" attack on the asset identifer by ensuring the output notes receive an asset identifier that exists on the global state Deplopyment ----------- From 38d3168fd73964cade00ed50cae33e6c2dcc791b Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 17:44:41 +0100 Subject: [PATCH 016/101] fixes indentation issues --- zip-0226.html | 186 ++++++++++++++++++++++++-------------------------- zip-0226.rst | 6 +- zip-0227.html | 88 ++++++++++++++++++++++-- zip-0227.rst | 16 ++--- 4 files changed, 182 insertions(+), 114 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index c1e4c008a..f7b8dd8a4 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -26,7 +26,7 @@

The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

We define the following additional terms:

    -
  • Asset: A type of note that can be transferred on the Zcash block chain. +
  • Asset: A type of note that can be transferred on the Zcash block chain, identified by the AssetId parameter.
    • ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
    @@ -34,7 +34,7 @@
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
  • Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain.
  • Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain.
    • -
  • Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific type. The Split Note is not spent in the transaction.
    • +
  • Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific AssetId. The Split Note is not spent in the transaction.
  • Split Action: a Zcash Shielded Asset Action that contains a Split Note.
@@ -45,73 +45,69 @@

The current Orchard protocol does not 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.

Overview

-

In order to be able to represent different Asset types in Orchard, we need to define a new data field that uniquely represents the type of the Asset in question, which we call - \(\mathsf{type}\) +

In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the AssetId of the Asset in question, which we call + \(\mathsf{AssetId}\) .

-

The type will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), and by extension the balance of an Orchard transaction. That is, the sum of all the +

The asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), 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}-value^{new}}\) - , must be balanced only with respect to the same Asset type. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset types, where the overall balance is checked without revealing which Assets (or how many different types) are being transferred.

-

As was initially proposed by Jack Grigg and Daira Hopwood 16, we propose to make this happen by changing the value base point, + , must be balanced only with respect to the same Asset identifier. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred.

+

As was initially proposed by Jack Grigg and Daira Hopwood 15, we propose to make this happen by changing the value base point, \(\mathcal{V}^{\mathsf{Orchard}}\) , in the Homomorphic Pedersen Commitment that generates 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 types in the transaction. We propose to make the - \(\mathsf{type}\) +

Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are asset identifiers in the transaction. We propose to make the + \(\mathsf{AssetId}\) identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same - \(\mathsf{type}\) - is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same type, and (2) that only actions with the same asset type identifier will balance out in the binding and balance signature.

-

In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the type of the output note of that split action is the output of a PRF.

+ \(\mathsf{AssetId}\) + is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same AssetId, and (2) that only actions with the same asset identifier will balance out in the binding and balance signature.

+

In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the AssetId of the output note of that split action is the output of a PRF.

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 than what is used in Orchard to unshield ZEC, by using the \(\mathsf{valueBalance}\) of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets.

Specification

Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.

-

Asset Types

-

In the OSA protocol, we include a new variable, the asset type identifier, - \(\mathsf{type}\) - , which is generated as a 32-byte string during issuance (as described in the Issuance ZIP 5). The - \(\mathsf{type}\) - will then be publicly hashed into the corresponding group, in this case the Pallas curve, by using the - \(\mathsf{GroupHash}\) - function. In fact, every ZSA note will contain the group element representation of the asset type identifier. This will enable a much more elegant and simple version of the circuit, as we will see.

-

We denote the string as - \(\mathsf{type}\) - and we denote the equivalent group representation as - \(\mathsf{type}_{\mathbb{G}}\) - when mapped into a specific group, - \(\mathbb{G}\) - . Note that the type of the ZEC asset will be kept as the original value base-point, +

Asset Identifiers

+

For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, + \(\mathsf{AssetId}\) + , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

+

This + \(\mathsf{AssetId}\) + will be the base point of the value commitment for the specific custom asset. Note that the + \(\mathsf{AssetId}\) + of the ZEC asset will be kept as the original value base-point, \(\mathcal{V}^\mathsf{Orchard}\) -

-

In future network and protocol upgrades, the same asset type string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset type from one group to another one.

+ .

+

In future network and protocol upgrades, the same asset description string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset identifier, + \(\mathsf{AssetId}\) + , from one group to another one.

Note Structure & Commitment

-

First, we need to adapt the components that define the assets, i.e.: notes. A ZSA note differs from an Orchard note by including the type of asset, - \(\mathsf{type}_\mathbb{P}\) +

First, we need to adapt the components that define the assets, i.e.: notes. A ZSA note differs from an Orchard note by including the identifier of asset, + \(\mathsf{AssetId}\) . So an ZSA note looks like:

- \((\mathsf{g_d, pk_d, v, \rho, \psi, type}_{\mathbb{P}})\) + \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\)

Where - \(\mathsf{type}_\mathbb{P}\) - is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

-

In this case, the note commitment, - \(\mathsf{NoteCommit^{ZSA}_{rcm}}\) + \(\mathsf{AssetId}\) + is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

+

In this case, the instance of the note commitment scheme, + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC assets, the type will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the type as a final recursive step, and hence keep a single instance of the hash function in the circuit for the note commitment verification.

+ in that for non-ZEC assets, the asset identifier will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have

- \(\mathsf{NoteCommit^{ZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, type_\mathbb{P})} \in \{\mathsf{cm},\bot\}\) + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \{\mathsf{cm},\bot\}\)

The nullifier is generated in the same manner as in the Orchard protocol.

Value Commitment

-

The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

+

The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

\(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

@@ -129,81 +125,81 @@ and \(\mathcal{R}^{\mathsf{Orchard}}\) are fixed for every value commitment, as the values represent the amount of ZEC being transferred.

-

In the case of the ZSA protocol, the value of different asset types in a given transaction will be committed using a different value base point. This enables the final balance of the transaction to be securely computed, such that each asset type is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes

+

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. This enables the final balance of the transaction to be securely computed, such that each asset identifier is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes

- \(\mathsf{cv^{net}:=ValueCommit^{ZSA}_{rcv}(v^{net}_{type},\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}})}:= \mathsf{[v^{net}_{type}]}\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) + \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

where - \(\mathsf{v^{net}_{type}} = \mathsf{v^{old}_{type} - v^{new}_{type}}\) + \(\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}\) such that - \(\mathsf{v^*_{type}}\) - is the value of the note of type - \(\mathsf{type}\) + \(\mathsf{v^*_{AssetId}}\) + is the value of the note of identifier + \(\mathsf{AssetId}\) , and

- \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{type}}:=\mathsf{type_\mathbb{P}}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || type\_params)}\) + \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || ik || \mathsf{asset_desc})}\)

\(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\)

Where - \(\mathcal{V}^{\mathsf{ZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}\) + \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}\) .

Value Balance Verification

-

In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one type of value balance published, that of ZEC, +

In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) - , so no net amount of any type will be revealed, and neither the nnumber of types in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in burnmechanism.

+ , so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in burnmechanism.

For a total of \(n\) actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

\(\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}\)

-

Then we have that the verifier computes

+

Then the verifier MUST compute

\(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

-

And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

+

And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

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 all the value commitments (and corresponding value balances) are equal to zero. In contrast, in this protocol, the value commitments only cancel out per asset type, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

+ , 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 identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

Split Notes

-

One of the key functionalities in a UTXO based protocol is the fact that input notes are usually 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. This is called a 1-to-many (Orchard) transaction. In order to cope with this today, the input note of the second (third and more) Action (which we call split notes and split Actions respectively) is a dummy spend note 12. Basically, the input note is “faked” inside of the proof in order to hide which action contains the real spend note.

-

This, however, brings some issues when it comes to adding multiple asset types, as the output note of the split Actions cannot be of any asset type, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same type as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing type, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

-

In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 type as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

-

Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset type is the preserved for the output note of a split Action, for the value balance verification:

+

One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

+

This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions cannot be of any asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

+

In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

+

Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification:

  1. The split input note could be the same note as the original (non-split) Action,
    2. -
  2. The split input note could be a different unspent note of the same type (note that the note will not actually be spent)
    3. -
  3. The split input note could be an already spent note of the same type (note that by zeroing the value in the circuit, we prevent double spending)
    4. +
  4. The split input note could be a different unspent note of the same AssetId (note that the note will not actually be spent)
    5. +
  5. The split input note could be an already spent note of the same AssetId (note that by zeroing the value in the circuit, we prevent double spending)

The specific circuit changes are presented below.

Circuit Statement

-

The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset type system.

-

Asset Type Equality: the following constraints must be added to ensure that the input and output note are of the same type:

+

The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset identifier system.

+

Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same AssetId:

    -
  • The asset type, - \(\mathsf{type_\mathbb{P}}\) +
  • The asset identifier, + \(\mathsf{AssetId}\) , for the note is witnessed once, as an auxiliary input.
    • -
  • The witnessed asset type, - \(\mathsf{type_\mathbb{P}}\) +
  • The witnessed asset identifier, + \(\mathsf{AssetId}\) , is added to the old note commitment input.
    • -
  • The witnessed asset type, - \(\mathsf{type_\mathbb{P}}\) +
  • The witnessed asset identifier, + \(\mathsf{AssetId}\) , is added to the new note commitment input.
-

Correct Value Commitment Type: the following constraints must be added to ensure that the value commitment is computed using the witnessed type, as represented in the notes

+

Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes

  • The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:mathsf{cv}, is replaced with a variable-base multiplication between the two
  • The witness to the value base-point, as defined in valuebase is the auxiliary input - \(\mathsf{type}_\mathbb{P}\) + \(\mathsf{AssetId}\) .
-

Enforce Secure Type for Split Actions: the following constraints must be added to prevent senders from changing the asset type for the output note in the Split Actions:

+

Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the asset identifier for the output note in the Split Actions:

  • @@ -211,7 +207,7 @@
    • Replace the input note value by a generic value, v', as - \(\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardType(v’ - v^new, type}_\mathbb{P})\) + \(\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}\)
    @@ -270,19 +266,19 @@
    • -
      The input note in the old note commitment integrity must either include a type (ZSA note) or not (ZEC-Orchard note)
      +
      The input note in the old note commitment integrity must either include an asset identifier (ZSA note) or not (ZEC-Orchard note)
      • -
        If the type auxiliary input is set - \(\mathsf{type}_\mathbb{P}\) +
        If the asset identifier auxiliary input is set + \(\mathsf{AssetId}\) = \(\mathcal{V}^\mathsf{Orchard}\)
          -
        • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the type)
          • +
        • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the identifier)
        • This path also uses the original domain separator for ZEC note commitment
        @@ -293,8 +289,8 @@
        Else,
          -
        • The NoteCommitment adds the type, - \(\mathsf{type}_\mathbb{P}\) +
        • The NoteCommitment adds the identfier, + \(\mathsf{AssetId}\) , as a final “chunk” of the Sinsemilla commitment
        • The NoteCommitment uses a different domain separator for ZSA note commitment
        @@ -307,34 +303,34 @@

      Backward Compatibility

      -

      In order to have a "clean" backwards 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: - The input notes with a type denote the ZSA custom assets, generating a note commitment that includes the type; whereas the notes without a type, denote the ZEC notes, and generate a note commitment that does not include the type, in order to maintain the referencability to the Merkle tree - 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

      +

      In order to have a "clean" backwards 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: - The input notes with an asset identifer denote the ZSA custom assets, generating a note commitment that includes the asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the asset identifier, in order to maintain the referencability to the Merkle tree - 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

Burn Mechanism

The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

-

In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset type to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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.

+

In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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.

First, contrary to the strict transfer transaction, we allow the sender to include a - \(\mathsf{valueBalvalueBalance_{type}}\) - variable for every asset type that is being burnt. As we will show in the transaction structure, this is separate from the regular + \(\mathsf{valueBalvalueBalance_{AssetId}}\) + variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular \(\mathsf{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 - \((\mathsf{valueBalance_{type}, type}_\mathbb{P})\) - 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 types in the transfer.

+ \((\mathsf{valueBalance_{AssetId}, 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.

- \(\mathsf{assetBurn = [(v^{type}, type_\mathbb{P})}| \forall \mathsf{type}_\mathbb{P} \textit{ s.t.}\mathsf{v^{type}\neq 0}]\) + \(\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]\)

-

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

-

Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective types as the value base point of the Pedersen Commitment. This is done as follows

+

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

+

Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective AssetId as the value base point of the Pedersen Commitment. This is done as follows

- \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{type}\textit{ s.t. }\mathsf{v^{type}\neq 0}} \mathsf{Value Commit_0^{ZSA}(v^{type}type_\mathbb{P}) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) + \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

-

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, the number of assets, nor their types will be revealed, except in the case that an asset is burnt.

+

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, the number of assets, nor their identifiers will be revealed, except in the case that an asset is burnt.

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, the unshielding is not not be possible for custom assets.

ZSA Transaction Structure

-

Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

+

Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

@@ -363,13 +359,13 @@

Other Considerations

Transaction Fees

-

In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on fees market on Zcash 15

+

The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

Security and Privacy

  • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • -
  • When including new assets we would like to maintain the amount and types of assets private, which is achieved with the design
    • -
  • We prevent the "roadblock" attack on the asset type by ensuring the output notes receive a type of an asset that exists on the global state
    • +
  • When including new assets we would like to maintain the amount and identifiers of assets private, which is achieved with the design
    • +
  • We prevent the "roadblock" attack on the asset identifer by ensuring the output notes receive an asset identifier that exists on the global state

Deplopyment

@@ -500,19 +496,19 @@
- +
- +
15A Study of Decentralized Markets on the Zcash BlockchainUser-Defined Assets and Wrapped Assets
- +
- +
16User-Defined Assets and Wrapped AssetsZIP 317b: ZSA Extension Proportional Fee Mechanism
diff --git a/zip-0226.rst b/zip-0226.rst index 1f40daa5e..26a0a379f 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -262,9 +262,7 @@ Other Considerations Transaction Fees ---------------- -In order to maintain the ZEC economic incentive, the first version of the fees mechanism will be exactly the same as -the current Orchard protocol and will always be paid in ZEC denomination. The ECC and GMU team produced a study on -fees market on Zcash [#fees-study-GMU]_ +The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b [#zip-0317b]_. Security and Privacy -------------------- @@ -305,5 +303,5 @@ References .. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) `_ .. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ .. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ -.. [#fees-study-GMU] `A Study of Decentralized Markets on the Zcash Blockchain `_ .. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ +.. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ \ No newline at end of file diff --git a/zip-0227.html b/zip-0227.html index 449571265..01f8f6321 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -70,7 +70,7 @@
  • The issuanceAuthorizingKey, denoted as isk, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
  • The issuanceValidatingKey, denoted as ik, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
    • -

    The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8. Specifically,

    +

    The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    • The issuanceAuthorizingKey is derived directly from the spendingKey, sk, as a private signature key:
    @@ -83,7 +83,7 @@

    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)

    -

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, AssetId, is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    @@ -214,7 +214,7 @@

    System Message: WARNING/2 (zip-0227.rst line 175)

    Concrete applications

    Bridging Assets Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - First, the issuance and burn mechanism can be used in conjunction to determine the

    -

    Asset Features - By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,

    +

    Asset Features - By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,

    System Message: ERROR/3 (zip-0227.rst line 194)

    Unexpected indentation.

    @@ -229,7 +229,17 @@

    System Message: WARNING/2 (zip-0227.rst line 195)

    Block quote ends without a blank line; unexpected unindent.

      -
    • Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by - issuing a last set of tokens of that specific AssetId, while at the same time setting finalize = 1, or by - issuing a transaction with a single note in the issuance action pertaining to that AssetId, where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations).
      • +
    • +
      +
      Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by
      +
      +
        +
      • issuing a last set of tokens of that specific AssetId, while at the same time setting finalize = 1, or by
        • +
      • issuing a transaction with a single note in the issuance action pertaining to that AssetId, where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations).
        • +
      +
      +
      +
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each AssetId corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
    @@ -247,20 +257,84 @@

    System Message: WARNING/2 (zip-0227.rst line 195)

    The following is a list of rationale for different decisions made in the proposal:

    • The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets.
      • -
    • the asset_desc is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: - links for storage such as for NFTs - other metadata for native assets - bridging information for wrapped assets (chain of origin, issuer name, etc) - information to be committed by the issuer, though not enforceable by the protocol
      • +
    • +
      +
      the asset_desc is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are:
      +
      +
        +
      • links for storage such as for NFTs
        • +
      • other metadata for native assets
        • +
      • bridging information for wrapped assets (chain of origin, issuer name, etc)
        • +
      • information to be committed by the issuer, though not enforceable by the protocol
        • +
      +
      +
      +
    +

    TxId Digest

    +

    A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

    + 
    issuance_txid_digest
+├── issueActions
+└── issuerVerificationKey
    +

    In the specification below, nodes of the tree are presented in depth-first order.

    +

    issuance_txid_digest

    +

    A BLAKE2b-256 hash of the following values

    + 
    T.1: issueActions            (field encoding bytes)
+T.2: issuerVerificationKey   (field encoding bytes)
    +

    The personalization field of this hash is set to:

    + 
    "ZTxIdOrcZSAIssue"
    +

    T.1 issueActions

    +

    A byte encoding of Issue Action information for all Issue Actions belonging to the transaction. For each Action, the following elements are included in the hash:

    + 
    T.1a: notes                   (field encoding bytes)
+T.1b: assetDescription        (field encoding bytes)
+T.1c: isFinalized             (1 byte)
    +
    T.1a: notes
    +

    A byte encoding of Note information for all Notes belonging to the Action. For each Note, the following elements are included in the hash:

    + 
    T.1a.1: recipient                    (field encoding bytes)
+T.1a.2: value                        (field encoding bytes)
+T.1a.3: asset                        (field encoding bytes)
+T.1a.4: rho                          (field encoding bytes)
+T.1a.5: rseed                        (field encoding bytes)
    +
    T.1a.1: recipient
    +

    Raw Address encoded as specified in [Zcash Protocol Spec § 5.6.4.2: Orchard Raw Payment Addresses].

    +
    +
    T.1a.2: value
    +

    Note value encoded as little-endian 8-byte representation of u64 raw value.

    +
    +
    T.1a.3: asset
    +

    Asset ID encoded as 32-byte representation of Pallas point.

    +
    +
    T.1a.4: rho
    +

    Nullifier encoded as 32-byte representation of Pallas point.

    +
    +
    T.1a.5: rseed
    +

    The ZIP 212 32-byte seed randomness for a note.

    +
    +
    +
    T.1b: assetDescription
    +

    UTF-8 encoding of the asset description string.

    +
    +
    T.1c: isFinalized
    +

    1-byte representation of a boolean flag that is set to 'true' if the asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    +
    +
    +

    T.2 issuerVerificationKey

    +

    A byte encoding of issuer verification key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components].

    +
    +
    +

    Security and Privacy Considerations

    Issuer Key or AssetId Compromise

    The design of this protocol does not allow for a rotation of the issuerValidatingKey, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: - If an asset ID is compromised (and not the issuer verification key), the finalize boolean for that asset should be set to 0 and a new AssetId generated instead. - If an issuer verification key is compromised, the finalize boolean for all the assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new AssetId.

    -

    Briding Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    +

    Briding Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    Other Considerations

    Implementing Zcash Nodes

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping issuanceSupplyInfoMap from AssetId to issuanceSupplyInfoMap := (totalSupply, finalize) in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying ik of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether.

    diff --git a/zip-0227.rst b/zip-0227.rst index e4625cff6..bf12e1401 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -171,7 +171,7 @@ For all actions `IssueAction`: - compute `AssetId` as :math:`GroupHash^{\mathbb{P}}(ik || asset_desc)` - set the `finalize` boolean as desired (if more more issuance actions are to be created for this asset identifier, set `finalize = 0`, otherwise set `finalize = 1`) - For each recipient `i`: - - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` + - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` - encode the `IssueAction` into the vector `vIssueActions` of the bundle For the `IssueBundle`: @@ -191,10 +191,10 @@ Issuers can wrap assets defined in other chains and issue them at once in a sing **Asset Features** - By using the `finalize` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any asset associated to their issuer keys. For example, - - by setting `finalize = 1` from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + - by setting `finalize = 1` from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. - Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by - - issuing a last set of tokens of that specific `AssetId`, while at the same time setting `finalize = 1`, or by - - issuing a transaction with a single note in the issuance action pertaining to that `AssetId`, where the note will contain a `value = 0`. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations). + - issuing a last set of tokens of that specific `AssetId`, while at the same time setting `finalize = 1`, or by + - issuing a transaction with a single note in the issuance action pertaining to that `AssetId`, where the note will contain a `value = 0`. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations). - Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each `AssetId` corresponds to `value = 1` at the fundamental unit level. Issuers and users should make sure that `finalize = 1` for each of the actions in this scenario. Consensus Rule Changes @@ -220,10 +220,10 @@ The following is a list of rationale for different decisions made in the proposa - The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets. - the `asset_desc` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: - - links for storage such as for NFTs - - other metadata for native assets - - bridging information for wrapped assets (chain of origin, issuer name, etc) - - information to be committed by the issuer, though not enforceable by the protocol + - links for storage such as for NFTs + - other metadata for native assets + - bridging information for wrapped assets (chain of origin, issuer name, etc) + - information to be committed by the issuer, though not enforceable by the protocol TxId Digest =========== From a3a58547efbb3d5169052564e9e3310c02cea32f Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:00:02 +0200 Subject: [PATCH 017/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index bf12e1401..d9b0ec999 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -39,7 +39,7 @@ ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash S Motivation ========== -The current Orchard protocol does not 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 +The Orchard protocol deployed in NU5 does not 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. Use Cases From b2dff91f157cb988ccebca7a976f07c4a5b023bb Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:00:34 +0200 Subject: [PATCH 018/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index d9b0ec999..615da7f23 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -50,7 +50,7 @@ The design presented in this ZIP enables issuance of shielded assets in various - The issuer knows in advance the receivers of the issued asset. - The asset is of non-fungible type, where each asset type can be made part of a single “series” - The supply of the asset is limited or not -- The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it) +- The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains). See the Concrete Applications section for more details. From 1e60d282cba2d8bd736804adfa7754c88f30c9e3 Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:01:08 +0200 Subject: [PATCH 019/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0227.rst b/zip-0227.rst index 615da7f23..0f861caa9 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -48,8 +48,8 @@ Use Cases The design presented in this ZIP enables issuance of shielded assets in various modes: - The issuer knows in advance the receivers of the issued asset. -- The asset is of non-fungible type, where each asset type can be made part of a single “series” -- The supply of the asset is limited or not +- The asset can be of non-fungible type, where each asset type can be made part of a single “series”. +- The supply of the asset can be limited in advance or not. - The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains). See the Concrete Applications section for more details. From 5a2a7200b702c2940dd30215b7c62366175c917a Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:16:01 +0200 Subject: [PATCH 020/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index 0f861caa9..47791f4df 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -59,7 +59,7 @@ Requirements - Any user of the Zcash block chain can issue custom assets on chain - The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain -- A user without knowledge of the private key of the issuer of a specific asset should not be able to issue that asset or change the attributes of such asset +- Issuing or changing the attributes of a specific asset should require cryptographic authorization. - The asset identification should be unique and different issuer keys should not be able to generate the same asset identifier From 78f57207a1ea7678fed1c63c88c72f56f179d76f Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:19:51 +0200 Subject: [PATCH 021/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index 47791f4df..963947756 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -60,7 +60,7 @@ Requirements - Any user of the Zcash block chain can issue custom assets on chain - The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain - Issuing or changing the attributes of a specific asset should require cryptographic authorization. -- The asset identification should be unique and different issuer keys should not be able to generate the same asset identifier +- The asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same asset identifier. Specification From 75e3ee8279caa9b94374ff8f60550801a90850ee Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:20:21 +0200 Subject: [PATCH 022/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index 963947756..62c9aecc9 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -66,7 +66,7 @@ Requirements Specification ============= -As explained, the issuance protocol allows for a single issuance action to be sent to many receivers by mean of generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions. Thus we divide the protocol spec in two sections. +As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions. Overview -------- From 9abf395aaaf8376e3ab5f909acbfc88b917e8006 Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:21:45 +0200 Subject: [PATCH 023/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index 62c9aecc9..cd4618a3a 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -71,7 +71,7 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -In short, this specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. +This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: - at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private From e9511a0b33f7369fc86f12d37ac758158c2254ba Mon Sep 17 00:00:00 2001 From: "Jonathan S. Rouach" Date: Thu, 8 Dec 2022 12:22:02 +0200 Subject: [PATCH 024/101] Update zip-0227.rst Co-authored-by: Daira Hopwood --- zip-0227.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0227.rst b/zip-0227.rst index cd4618a3a..9e7b4df9f 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -78,7 +78,7 @@ The protocol was designed with three main properties in mind: - in a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets - every issuance action contains the `finiteIssuance` boolean that defines whether that specific custom asset can have further tokens issued or not -The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. Issuance Keys ------------- From 8d923484ae155f3773563ced72bb7be880ddf6de Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Thu, 15 Dec 2022 16:25:10 +0530 Subject: [PATCH 025/101] regenerating htmls, updating index.html and README.rst --- README.rst | 172 +++++++++++++++++++++++++------------------------- index.html | 172 +++++++++++++++++++++++++------------------------- zip-0226.html | 30 ++++----- zip-0227.html | 36 +++++------ 4 files changed, 207 insertions(+), 203 deletions(-) diff --git a/README.rst b/README.rst index 4a718bb5b..3d2373fff 100644 --- a/README.rst +++ b/README.rst @@ -75,89 +75,91 @@ Index of ZIPs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZIP Title Status
    0 ZIP Process Active
    1 Network Upgrade Policy and Scheduling Reserved
    2 Design Considerations for Network Upgrades Reserved
    32 Shielded Hierarchical Deterministic Wallets Final
    76 Transaction Signature Validation before Overwinter Reserved
    143 Transaction Signature Validation for Overwinter Final
    155 addrv2 message Proposed
    173 Bech32 Format Final
    200 Network Upgrade Mechanism Final
    201 Network Peer Management for Overwinter Final
    202 Version 3 Transaction Format for Overwinter Final
    203 Transaction Expiry Final
    204 Zcash P2P Network Protocol Reserved
    205 Deployment of the Sapling Network Upgrade Final
    206 Deployment of the Blossom Network Upgrade Final
    207 Funding Streams Final
    208 Shorter Block Target Spacing Final
    209 Prohibit Negative Shielded Chain Value Pool Balances Final
    210 Sapling Anchor Deduplication within Transactions Withdrawn
    211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
    212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
    213 Shielded Coinbase Final
    214 Consensus rules for a Zcash Development Fund Final
    215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
    216 Require Canonical Jubjub Point Encodings Final
    217 Aggregate Signatures Reserved
    219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
    220 Zcash Shielded Assets Withdrawn
    221 FlyClient - Consensus-Layer Changes Final
    222 Transparent Zcash Extensions Draft
    224 Orchard Shielded Protocol Final
    225 Version 5 Transaction Format Final
    226 Zcash Shielded Assets - Transfers and Burns Reserved
    227 Zcash Shielded Assets - Issuance Reserved
    239 Relay of Version 5 Transactions Final
    243 Transaction Signature Validation for Sapling Final
    244 Transaction Identifier Non-Malleability Final
    245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
    250 Deployment of the Heartwood Network Upgrade Final
    251 Deployment of the Canopy Network Upgrade Final
    252 Deployment of the NU5 Network Upgrade Final
    300 Cross-chain Atomic Transactions Proposed
    301 Zcash Stratum Protocol Final
    302 Standardized Memo Field Format Draft
    303 Sprout Payment Disclosure Reserved
    304 Sapling Address Signatures Draft
    305 Best Practices for Hardware Wallets supporting Sapling Reserved
    306 Security Considerations for Anchor Selection Reserved
    307 Light Client Protocol for Payment Detection Draft
    308 Sprout to Sapling Migration Final
    309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
    310 Security Properties of Sapling Viewing Keys Draft
    311 Sapling Payment Disclosure Reserved
    312 Shielded Multisignatures using FROST Reserved
    313 Reduce Conventional Transaction Fee to 1000 zatoshis Active
    314 Privacy upgrades to the Zcash light client protocol Reserved
    315 Best Practices for Wallet Handling of Multiple Pools Reserved
    316 Unified Addresses and Unified Viewing Keys Final
    317 Proportional Transfer Fee Mechanism Draft
    318 Associated Payload Encryption Reserved
    319 Options for Shielded Pool Retirement Reserved
    321 Payment Request URIs Proposed
    322 Generic Signed Message Format Reserved
    323 Specification of getblocktemplate for Zcash Reserved
    339 Wallet Recovery Words Reserved
    400 Wallet.dat format Draft
    401 Addressing Mempool Denial-of-Service Active
    402 New Wallet Database Format Reserved
    403 Verification Behaviour of zcashd Reserved
    416 Support for Unified Addresses in zcashd Reserved
    1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
    1002 Opt-in Donation Feature Obsolete
    1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
    1004 Miner-Directed Dev Fund Obsolete
    1005 Zcash Community Funding System Obsolete
    1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
    1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
    1008 Fund ECC for Two More Years Obsolete
    1009 Five-Entity Strategic Council Obsolete
    1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
    1011 Decentralize the Dev Fee Obsolete
    1012 Dev Fund to ECC + ZF + Major Grants Obsolete
    1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
    1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
    guide {Something Short and To the Point} Draft
    0 ZIP Process + Active +
    1 Network Upgrade Policy and Scheduling Reserved
    2 Design Considerations for Network Upgrades Reserved
    32 Shielded Hierarchical Deterministic Wallets Final
    76 Transaction Signature Validation before Overwinter Reserved
    143 Transaction Signature Validation for Overwinter Final
    155 addrv2 message Proposed
    173 Bech32 Format Final
    200 Network Upgrade Mechanism Final
    201 Network Peer Management for Overwinter Final
    202 Version 3 Transaction Format for Overwinter Final
    203 Transaction Expiry Final
    204 Zcash P2P Network Protocol Reserved
    205 Deployment of the Sapling Network Upgrade Final
    206 Deployment of the Blossom Network Upgrade Final
    207 Funding Streams Final
    208 Shorter Block Target Spacing Final
    209 Prohibit Negative Shielded Chain Value Pool Balances Final
    210 Sapling Anchor Deduplication within Transactions Withdrawn
    211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
    212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
    213 Shielded Coinbase Final
    214 Consensus rules for a Zcash Development Fund Final
    215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
    216 Require Canonical Jubjub Point Encodings Final
    217 Aggregate Signatures Reserved
    219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
    220 Zcash Shielded Assets Withdrawn
    221 FlyClient - Consensus-Layer Changes Final
    222 Transparent Zcash Extensions Draft
    224 Orchard Shielded Protocol Final
    225 Version 5 Transaction Format Final
    226 Transfer and Burn of Zcash Shielded Assets Draft
    227 Issuance of Zcash Shielded Assets Draft
    239 Relay of Version 5 Transactions Final
    243 Transaction Signature Validation for Sapling Final
    244 Transaction Identifier Non-Malleability Final
    245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
    250 Deployment of the Heartwood Network Upgrade Final
    251 Deployment of the Canopy Network Upgrade Final
    252 Deployment of the NU5 Network Upgrade Final
    300 Cross-chain Atomic Transactions Proposed
    301 Zcash Stratum Protocol Final
    302 Standardized Memo Field Format Draft
    303 Sprout Payment Disclosure Reserved
    304 Sapling Address Signatures Draft
    305 Best Practices for Hardware Wallets supporting Sapling Reserved
    306 Security Considerations for Anchor Selection Reserved
    307 Light Client Protocol for Payment Detection Draft
    308 Sprout to Sapling Migration Final
    309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
    310 Security Properties of Sapling Viewing Keys Draft
    311 Sapling Payment Disclosure Reserved
    312 Shielded Multisignatures using FROST Reserved
    313 Reduce Conventional Transaction Fee to 1000 zatoshis Active
    314 Privacy upgrades to the Zcash light client protocol Reserved
    315 Best Practices for Wallet Handling of Multiple Pools Reserved
    316 Unified Addresses and Unified Viewing Keys Final
    317 Proportional Transfer Fee Mechanism Draft
    318 Associated Payload Encryption Reserved
    319 Options for Shielded Pool Retirement Reserved
    321 Payment Request URIs Proposed
    322 Generic Signed Message Format Reserved
    323 Specification of getblocktemplate for Zcash Reserved
    339 Wallet Recovery Words Reserved
    400 Wallet.dat format Draft
    401 Addressing Mempool Denial-of-Service Active
    402 New Wallet Database Format Reserved
    403 Verification Behaviour of zcashd Reserved
    416 Support for Unified Addresses in zcashd Reserved
    1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
    1002 Opt-in Donation Feature Obsolete
    1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
    1004 Miner-Directed Dev Fund Obsolete
    1005 Zcash Community Funding System Obsolete
    1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
    1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
    1008 Fund ECC for Two More Years Obsolete
    1009 Five-Entity Strategic Council Obsolete
    1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
    1011 Decentralize the Dev Fee Obsolete
    1012 Dev Fund to ECC + ZF + Major Grants Obsolete
    1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
    1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
    guide {Something Short and To the Point} Draft
    diff --git a/index.html b/index.html index a62d3e192..e54761d4f 100644 --- a/index.html +++ b/index.html @@ -49,91 +49,93 @@

    Index of ZIPs

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZIP Title Status
    0 ZIP Process Active
    1 Network Upgrade Policy and Scheduling Reserved
    2 Design Considerations for Network Upgrades Reserved
    32 Shielded Hierarchical Deterministic Wallets Final
    76 Transaction Signature Validation before Overwinter Reserved
    143 Transaction Signature Validation for Overwinter Final
    155 addrv2 message Proposed
    173 Bech32 Format Final
    200 Network Upgrade Mechanism Final
    201 Network Peer Management for Overwinter Final
    202 Version 3 Transaction Format for Overwinter Final
    203 Transaction Expiry Final
    204 Zcash P2P Network Protocol Reserved
    205 Deployment of the Sapling Network Upgrade Final
    206 Deployment of the Blossom Network Upgrade Final
    207 Funding Streams Final
    208 Shorter Block Target Spacing Final
    209 Prohibit Negative Shielded Chain Value Pool Balances Final
    210 Sapling Anchor Deduplication within Transactions Withdrawn
    211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
    212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
    213 Shielded Coinbase Final
    214 Consensus rules for a Zcash Development Fund Final
    215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
    216 Require Canonical Jubjub Point Encodings Final
    217 Aggregate Signatures Reserved
    219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
    220 Zcash Shielded Assets Withdrawn
    221 FlyClient - Consensus-Layer Changes Final
    222 Transparent Zcash Extensions Draft
    224 Orchard Shielded Protocol Final
    225 Version 5 Transaction Format Final
    226 Zcash Shielded Assets - Transfers and Burns Reserved
    227 Zcash Shielded Assets - Issuance Reserved
    239 Relay of Version 5 Transactions Final
    243 Transaction Signature Validation for Sapling Final
    244 Transaction Identifier Non-Malleability Final
    245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
    250 Deployment of the Heartwood Network Upgrade Final
    251 Deployment of the Canopy Network Upgrade Final
    252 Deployment of the NU5 Network Upgrade Final
    300 Cross-chain Atomic Transactions Proposed
    301 Zcash Stratum Protocol Final
    302 Standardized Memo Field Format Draft
    303 Sprout Payment Disclosure Reserved
    304 Sapling Address Signatures Draft
    305 Best Practices for Hardware Wallets supporting Sapling Reserved
    306 Security Considerations for Anchor Selection Reserved
    307 Light Client Protocol for Payment Detection Draft
    308 Sprout to Sapling Migration Final
    309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
    310 Security Properties of Sapling Viewing Keys Draft
    311 Sapling Payment Disclosure Reserved
    312 Shielded Multisignatures using FROST Reserved
    313 Reduce Conventional Transaction Fee to 1000 zatoshis Active
    314 Privacy upgrades to the Zcash light client protocol Reserved
    315 Best Practices for Wallet Handling of Multiple Pools Reserved
    316 Unified Addresses and Unified Viewing Keys Final
    317 Proportional Transfer Fee Mechanism Draft
    318 Associated Payload Encryption Reserved
    319 Options for Shielded Pool Retirement Reserved
    321 Payment Request URIs Proposed
    322 Generic Signed Message Format Reserved
    323 Specification of getblocktemplate for Zcash Reserved
    339 Wallet Recovery Words Reserved
    400 Wallet.dat format Draft
    401 Addressing Mempool Denial-of-Service Active
    402 New Wallet Database Format Reserved
    403 Verification Behaviour of zcashd Reserved
    416 Support for Unified Addresses in zcashd Reserved
    1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
    1002 Opt-in Donation Feature Obsolete
    1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
    1004 Miner-Directed Dev Fund Obsolete
    1005 Zcash Community Funding System Obsolete
    1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
    1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
    1008 Fund ECC for Two More Years Obsolete
    1009 Five-Entity Strategic Council Obsolete
    1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
    1011 Decentralize the Dev Fee Obsolete
    1012 Dev Fund to ECC + ZF + Major Grants Obsolete
    1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
    1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
    guide {Something Short and To the Point} Draft
    0 ZIP Process + Active +
    1 Network Upgrade Policy and Scheduling Reserved
    2 Design Considerations for Network Upgrades Reserved
    32 Shielded Hierarchical Deterministic Wallets Final
    76 Transaction Signature Validation before Overwinter Reserved
    143 Transaction Signature Validation for Overwinter Final
    155 addrv2 message Proposed
    173 Bech32 Format Final
    200 Network Upgrade Mechanism Final
    201 Network Peer Management for Overwinter Final
    202 Version 3 Transaction Format for Overwinter Final
    203 Transaction Expiry Final
    204 Zcash P2P Network Protocol Reserved
    205 Deployment of the Sapling Network Upgrade Final
    206 Deployment of the Blossom Network Upgrade Final
    207 Funding Streams Final
    208 Shorter Block Target Spacing Final
    209 Prohibit Negative Shielded Chain Value Pool Balances Final
    210 Sapling Anchor Deduplication within Transactions Withdrawn
    211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
    212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
    213 Shielded Coinbase Final
    214 Consensus rules for a Zcash Development Fund Final
    215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
    216 Require Canonical Jubjub Point Encodings Final
    217 Aggregate Signatures Reserved
    219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
    220 Zcash Shielded Assets Withdrawn
    221 FlyClient - Consensus-Layer Changes Final
    222 Transparent Zcash Extensions Draft
    224 Orchard Shielded Protocol Final
    225 Version 5 Transaction Format Final
    226 Transfer and Burn of Zcash Shielded Assets Draft
    227 Issuance of Zcash Shielded Assets Draft
    239 Relay of Version 5 Transactions Final
    243 Transaction Signature Validation for Sapling Final
    244 Transaction Identifier Non-Malleability Final
    245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
    250 Deployment of the Heartwood Network Upgrade Final
    251 Deployment of the Canopy Network Upgrade Final
    252 Deployment of the NU5 Network Upgrade Final
    300 Cross-chain Atomic Transactions Proposed
    301 Zcash Stratum Protocol Final
    302 Standardized Memo Field Format Draft
    303 Sprout Payment Disclosure Reserved
    304 Sapling Address Signatures Draft
    305 Best Practices for Hardware Wallets supporting Sapling Reserved
    306 Security Considerations for Anchor Selection Reserved
    307 Light Client Protocol for Payment Detection Draft
    308 Sprout to Sapling Migration Final
    309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
    310 Security Properties of Sapling Viewing Keys Draft
    311 Sapling Payment Disclosure Reserved
    312 Shielded Multisignatures using FROST Reserved
    313 Reduce Conventional Transaction Fee to 1000 zatoshis Active
    314 Privacy upgrades to the Zcash light client protocol Reserved
    315 Best Practices for Wallet Handling of Multiple Pools Reserved
    316 Unified Addresses and Unified Viewing Keys Final
    317 Proportional Transfer Fee Mechanism Draft
    318 Associated Payload Encryption Reserved
    319 Options for Shielded Pool Retirement Reserved
    321 Payment Request URIs Proposed
    322 Generic Signed Message Format Reserved
    323 Specification of getblocktemplate for Zcash Reserved
    339 Wallet Recovery Words Reserved
    400 Wallet.dat format Draft
    401 Addressing Mempool Denial-of-Service Active
    402 New Wallet Database Format Reserved
    403 Verification Behaviour of zcashd Reserved
    416 Support for Unified Addresses in zcashd Reserved
    1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
    1002 Opt-in Donation Feature Obsolete
    1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
    1004 Miner-Directed Dev Fund Obsolete
    1005 Zcash Community Funding System Obsolete
    1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
    1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
    1008 Fund ECC for Two More Years Obsolete
    1009 Five-Entity Strategic Council Obsolete
    1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
    1011 Decentralize the Dev Fee Obsolete
    1012 Dev Fund to ECC + ZF + Major Grants Obsolete
    1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
    1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
    guide {Something Short and To the Point} Draft
    diff --git a/zip-0226.html b/zip-0226.html index f7b8dd8a4..d6fd06a57 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -21,9 +21,9 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/618>

    Terminology

    -

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

    -

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

    -

    The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

    +

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

    +

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

    +

    The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

    We define the following additional terms:

    • Asset: A type of note that can be transferred on the Zcash block chain, identified by the AssetId parameter. @@ -39,7 +39,7 @@

    Abstract

    -

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

    +

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

    Motivation

    The current Orchard protocol does not 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.

    @@ -48,12 +48,12 @@

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the AssetId of the Asset in question, which we call \(\mathsf{AssetId}\) .

    -

    The asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), 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}-value^{new}}\) , must be balanced only with respect to the same Asset identifier. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred.

    -

    As was initially proposed by Jack Grigg and Daira Hopwood 15, we propose to make this happen by changing the value base point, +

    As was initially proposed by Jack Grigg and Daira Hopwood 15, we propose to make this happen by changing the value base point, \(\mathcal{V}^{\mathsf{Orchard}}\) , in the Homomorphic Pedersen Commitment that generates the value commitment, \(\mathsf{cv^{net}}\) @@ -94,12 +94,12 @@

    Where \(\mathsf{AssetId}\) - is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

    + is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC assets, the asset identifier will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    + in that for non-ZEC assets, the asset identifier will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \{\mathsf{cm},\bot\}\) @@ -107,7 +107,7 @@

    The nullifier is generated in the same manner as in the Orchard protocol.

    Value Commitment

    -

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

    +

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

    \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    @@ -147,7 +147,7 @@ .

    Value Balance Verification

    -

    In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, +

    In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) , so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in burnmechanism.

    For a total of @@ -160,13 +160,13 @@

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

    +

    And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions cannot be of any asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification:

    @@ -179,7 +179,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same AssetId:

    • The asset identifier, @@ -330,7 +330,7 @@

      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, the unshielding is not not be possible for custom assets.

    ZSA Transaction Structure

    -

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    +

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    @@ -359,7 +359,7 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    Security and Privacy

      diff --git a/zip-0227.html b/zip-0227.html index 01f8f6321..b0973c802 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -21,9 +21,9 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/618>

      Terminology

      -

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

      -

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

      -

      The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

      +

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

      +

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

      +

      The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

      We define the following additional terms:

      • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (AssetId).
        • @@ -34,18 +34,18 @@

      Abstract

      -

      ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

      +

      ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

      Motivation

      -

      The current Orchard protocol does not 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.

      +

      The Orchard protocol deployed in NU5 does not 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.

      Use Cases

      The design presented in this ZIP enables issuance of shielded assets in various modes:

      • The issuer knows in advance the receivers of the issued asset.
        • -
      • The asset is of non-fungible type, where each asset type can be made part of a single “series”
        • -
      • The supply of the asset is limited or not
        • -
      • The assets can be wrapped versions of assets in other chains (as long as there is a bridge that supports it)
        • +
      • The asset can be of non-fungible type, where each asset type can be made part of a single “series”.
        • +
      • The supply of the asset can be limited in advance or not.
        • +
      • The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains).

      See the Concrete Applications section for more details.

      @@ -53,16 +53,16 @@
      • Any user of the Zcash block chain can issue custom assets on chain
      • The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain
        • -
      • A user without knowledge of the private key of the issuer of a specific asset should not be able to issue that asset or change the attributes of such asset
        • -
      • The asset identification should be unique and different issuer keys should not be able to generate the same asset identifier
        • +
      • Issuing or changing the attributes of a specific asset should require cryptographic authorization.
        • +
      • The asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same asset identifier.

    Specification

    -

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers by mean of generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions. Thus we divide the protocol spec in two sections.

    +

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    Overview

    -

    In short, this specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

    +

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

    The protocol was designed with three main properties in mind: - at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private - in a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets - every issuance action contains the finiteIssuance boolean that defines whether that specific custom asset can have further tokens issued or not

    -

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables, what we hope will be a useful set of, applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    +

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    Issuance Keys

    There are two keys relevant to the Issuer:

    @@ -70,7 +70,7 @@
  • The issuanceAuthorizingKey, denoted as isk, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
  • The issuanceValidatingKey, denoted as ik, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
    • -

    The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    +

    The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    • The issuanceAuthorizingKey is derived directly from the spendingKey, sk, as a private signature key:
    @@ -83,7 +83,7 @@

    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)

    -

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, AssetId, is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    @@ -214,7 +214,7 @@

    System Message: WARNING/2 (zip-0227.rst line 175)

    Concrete applications

    Bridging Assets Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - First, the issuance and burn mechanism can be used in conjunction to determine the

    -

    Asset Features - By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,

    +

    Asset Features - By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,

    System Message: ERROR/3 (zip-0227.rst line 194)

    Unexpected indentation.

    @@ -327,14 +327,14 @@

    System Message: WARNING/2 (zip-0227.rst line 195)

    Security and Privacy Considerations

    Issuer Key or AssetId Compromise

    The design of this protocol does not allow for a rotation of the issuerValidatingKey, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: - If an asset ID is compromised (and not the issuer verification key), the finalize boolean for that asset should be set to 0 and a new AssetId generated instead. - If an issuer verification key is compromised, the finalize boolean for all the assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new AssetId.

    -

    Briding Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    +

    Briding Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    Other Considerations

    Implementing Zcash Nodes

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping issuanceSupplyInfoMap from AssetId to issuanceSupplyInfoMap := (totalSupply, finalize) in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying ik of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether.

    From 214c865c654bea9f5743592d35a1598b943de973 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 19 Dec 2022 12:03:51 +0530 Subject: [PATCH 026/101] minor typographical improvements in ZIP 226 --- zip-0226.html | 17 +++++++++-------- zip-0226.rst | 15 +++++++-------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index d6fd06a57..52511a770 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -71,7 +71,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 identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, +

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, \(\mathsf{AssetId}\) , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    This @@ -136,7 +136,7 @@ is the value of the note of identifier \(\mathsf{AssetId}\) , and

    -

    +

    \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || ik || \mathsf{asset_desc})}\)

    @@ -149,7 +149,7 @@

    Value Balance Verification

    In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) - , so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in burnmechanism.

    + , so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in the burn mechanism.

    For a total of \(n\) actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

    @@ -166,7 +166,7 @@ , 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 identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions cannot be of any asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification:

    @@ -194,8 +194,10 @@

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes

      -
    • The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:mathsf{cv}, is replaced with a variable-base multiplication between the two
      • -
    • The witness to the value base-point, as defined in valuebase is the auxiliary input +
    • The fixed-base multiplication constraints 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 value base equation is the auxiliary input \(\mathsf{AssetId}\) .
    @@ -306,12 +308,11 @@

    In order to have a "clean" backwards 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: - The input notes with an asset identifer denote the ZSA custom assets, generating a note commitment that includes the asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the asset identifier, in order to maintain the referencability to the Merkle tree - 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

    -

    Burn Mechanism

    The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

    In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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.

    First, contrary to the strict transfer transaction, we allow the sender to include a - \(\mathsf{valueBalvalueBalance_{AssetId}}\) + \(\mathsf{valueBalance_{AssetId}}\) variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular \(\mathsf{valueBalance^Orchard}\) that is the default transparent value for the ZEC asset.

    diff --git a/zip-0226.rst b/zip-0226.rst index 26a0a379f..9f310016e 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -70,7 +70,7 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom asset. Note that the :math:`\mathsf{AssetId}` of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}`. @@ -122,7 +122,7 @@ In the case of the ZSA protocol, the value of different asset identifiers in a g where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^*_{AssetId}}` is the value of the note of identifier :math:`\mathsf{AssetId}`, and -.. _valuebase: +.. _`value base`: :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || ik || \mathsf{asset_desc})}` @@ -133,7 +133,7 @@ Where :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mat Value Balance Verification -------------------------- -In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in burnmechanism_. +In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in the `burn mechanism`_. For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key @@ -151,7 +151,7 @@ As in the Orchard protocol, the binding signature verification key, :math:`\math Split Notes ----------- -One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents and input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. +One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions *cannot* be of *any* asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. @@ -180,8 +180,8 @@ same `AssetId`: **Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes -- The fixed-base multiplication constraints between the value and the value base point of the value commitment,:math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two -- The witness to the value base-point, as defined in valuebase_ is the auxiliary input :math:`\mathsf{AssetId}`. +- The fixed-base multiplication constraints between the value and the value base point of the value commitment, :math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two. +- The witness to the value base-point, as defined in the `value base`_ equation is the auxiliary input :math:`\mathsf{AssetId}`. **Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the asset identifier for the output note in the Split Actions: @@ -216,7 +216,6 @@ In order to have a "clean" backwards compatibility with the ZEC notes, we have d - 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 -.. _burnmechanism: Burn Mechanism ============== @@ -224,7 +223,7 @@ The burn mechanism may be needed for off-boarding the wrapped assets from the ch In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalvalueBalance_{AssetId}}` variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC asset. +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{AssetId}}` variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{AssetId}, 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. From 06b9e7d27cbc9cc3f0fa0a905c8ce263be86bf9e Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 19 Dec 2022 23:00:32 +0530 Subject: [PATCH 027/101] typographical improvements in ZIP 227 --- zip-0227.html | 290 ++++++++++++++++++++++++++++++++------------------ zip-0227.rst | 154 +++++++++++++++------------ 2 files changed, 274 insertions(+), 170 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index b0973c802..2c4965635 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -26,7 +26,9 @@

    The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

    We define the following additional terms:

      -
    • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (AssetId).
      • +
    • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier ( + \(\mathsf{AssetId}\) + ).
    • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool.
    • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
    • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier.
      • @@ -47,12 +49,12 @@
    • The supply of the asset can be limited in advance or not.
    • The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains).
    -

    See the Concrete Applications section for more details.

    +

    See the Concrete Applications section for more details.

    Requirements

      -
    • Any user of the Zcash block chain can issue custom assets on chain
      • -
    • The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain
      • +
    • Any user of the Zcash block chain can issue custom assets on chain.
      • +
    • The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain.
    • Issuing or changing the attributes of a specific asset should require cryptographic authorization.
    • The asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same asset identifier.
    @@ -61,48 +63,81 @@

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    Overview

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

    -

    The protocol was designed with three main properties in mind: - at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private - in a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets - every issuance action contains the finiteIssuance boolean that defines whether that specific custom asset can have further tokens issued or not

    -

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    +

    The protocol was designed with three main properties in mind:

    +
      +
    • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
      • +
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets.
      • +
    • Every issuance action contains the finalize boolean that defines whether that specific custom asset can have further tokens issued or not.
      • +
    +

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    Issuance Keys

    There are two keys relevant to the Issuer:

      -
    1. The issuanceAuthorizingKey, denoted as isk, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
      2. -
    2. The issuanceValidatingKey, denoted as ik, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
      3. +
    3. The issuance authorizing key, denoted as + \(\mathsf{isk}\) + , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
      4. +
    4. The issuance validating key, denoted as + \(\mathsf{ik}\) + , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
    -

    The two keys are derived in an analogous manner to the spendAuthorizingKey and spendValidatingKey keys, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    +

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

      -
    • The issuanceAuthorizingKey is derived directly from the spendingKey, sk, as a private signature key:
      • +
    • The issuance authorizing key is derived directly from the spending key, + \(\mathsf{sk}\) + , as a private signature key:
    -

    - \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])}\) -

    +
    \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])}\)
      -
    • The issuanceValidatingKey is derived from the issuanceAuthorizingKey, isk, as a public verification key:
      • +
    • The issuance validating key is derived from the issuance authorizing key, + \(\mathsf{isk}\) + , as a public verification key:
    -

    - \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\) -

    +
    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    -

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, AssetId, is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    -

    The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, AssetId as follows:

    +

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, + \(\mathsf{asset\_desc}\) + , which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, + \(\mathsf{AssetId}\) + , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    +

    The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, + \(\mathsf{AssetId}\) + as follows:

    - \(\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}\) + \(\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset\_desc)}\)

    where

      -
    • asset_desc is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance
      • -
    • issuanceValidatingKey is the public key of the issuer, used to verify the signature on the transaction SIGHASH and is defined as ik
      • +
    • + \(\mathsf{asset\_desc}\) + is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance
      • +
    • + \(\mathsf{ik}\) + is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above

    Global Issuance State

    -

    Issuance requires the following additions to the global state: - previously_finalized, a set of AssetId that have been finalized (i.e.: the finalize flag has been set to 1).

    +

    Issuance requires the following additions to the global state:

    +
      +
    • previously_finalized, a set of + \(\mathsf{AssetId}\) + that have been finalized (i.e.: the finalize flag has been set to 1).
      • +

    Issuance Action Description

    -

    An issuance action, IssueAction, is the instance of issuing a specific custom asset, and contains the following fields: - asset_desc: the asset description, a UTF-8 encoded string of up to 512 bytes - notes: an array containing the unencrypted output notes of the recipients of the asset, of type Note - finalize: a boolean that defines whether the issuance of that specific custom asset is finalized or not

    -

    Once finiteSupply is set to 1, it cannot be unset. For assets whose finalize = 1, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose finalize = 0, new issuance actions can be issued in future transactions. These must use the same asset description, asset_desc, and can either maintain finalize = 0 or change it to 1, denoting the last transaction containing issuance of such custom asset.

    +

    An issuance action, IssueAction, is the instance of issuing a specific custom asset, and contains the following fields:

    +
      +
    • + \(\mathsf{asset\_desc}\) + : the asset description, a UTF-8 encoded string of up to 512 bytes
      • +
    • notes: an array containing the unencrypted output notes of the recipients of the asset, of type Note
      • +
    • finalize: a boolean that defines whether the issuance of that specific custom asset is finalized or not
      • +
    +

    Once finalize is set to 1, it cannot be unset. For assets whose finalize = 1, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose finalize = 0, new issuance actions can be issued in future transactions. These must use the same asset description, + \(\mathsf{asset\_desc}\) + , and can either maintain finalize = 0 or change it to finalize = 1, denoting the last transaction containing issuance of such custom asset.

    @@ -115,7 +150,9 @@ - + @@ -133,7 +170,7 @@ - + @@ -144,9 +181,15 @@

    Issuance Bundle

    An issuance bundle, IssueBundle, is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields:

      -
    • ik: the issuanceValidatingKey, that allows the validators to verify that the AssetId is properly associated with the issuer
      • -
    • actions: an array of issuance actions, of type IssueAction
      • -
    • authorization: the signature of the transaction SIGHASH, signed by the issuanceAuthorizingKey, isk, that validates the issuance
      • +
    • + \(\mathsf{ik}\) + : the issuance validating key, that allows the validators to verify that the + \(\mathsf{AssetId}\) + is properly associated with the issuer.
      • +
    • actions: an array of issuance actions, of type IssueAction.
      • +
    • authorization: the signature of the transaction SIGHASH, signed by the issuance authorizing key, + \(\mathsf{isk}\) + , that validates the issuance .

    The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format.
    Variesasset_desc + \(\mathsf{asset\_desc}\) + byte Uni-code encoded string of varied size, up to 512 bytes
    1 bitfinalizefinalize boolean The boolean that determines the finality of the issuance of that asset
    @@ -173,9 +216,11 @@ - + - + @@ -188,87 +233,114 @@

    Issuance Protocol

    The issuer program performs the following operations

    -

    For all actions IssueAction: - encode asset_desc as 512 byte-string - compute AssetId as - \(GroupHash^{\mathbb{P}}(ik || asset_desc)\) - - set the finalize boolean as desired (if more more issuance actions are to be created for this asset identifier, set finalize = 0, otherwise set finalize = 1) - For each recipient i:

    -
    -

    System Message: ERROR/3 (zip-0227.rst line 174)

    -

    Unexpected indentation.

    -
    -
    -
      -
    • generate a ZSA output note as - \(\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}\) -
      • -
    -
    -
    -

    System Message: WARNING/2 (zip-0227.rst line 175)

    -

    Block quote ends without a blank line; unexpected unindent.

    -
    +

    For all actions IssueAction:

      +
    • encode + \(\mathsf{asset\_desc}\) + as 512 byte-string
      • +
    • compute + \(\mathsf{AssetId}\) + as + \(GroupHash^{\mathbb{P}}(ik || asset_desc)\) +
      • +
    • set the finalize boolean as desired (if more more issuance actions are to be created for this asset identifier, set finalize = 0, otherwise set finalize = 1)
      • +
    • For each recipient i: +
        +
      • generate a ZSA output note as + \(\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}\) +
        • +
      +
    • encode the IssueAction into the vector vIssueActions of the bundle
    -

    For the IssueBundle: - encode the vIssueActions vector - encode the ik as 32 byte-string - sign the SIGHASH of the transaction with the issuanceAuthorizingKey, isk, using the RedPallas signature scheme. The signature is then added to the issuance bundle.

    -

    NOTE that the commitment is not included in the IssuanceAction itsefl. As explained below, it is later computed by the validators and added to the NoteCommitmentTree.

    +

    For the IssueBundle:

    +
      +
    • encode the vIssueActions vector
      • +
    • encode the + \(\mathsf{ik}\) + as 32 byte-string
      • +
    • sign the SIGHASH of the transaction with the issuance authorizing key, + \(\mathsf{isk}\) + , using the RedPallas signature scheme. The signature is then added to the issuance bundle.
      • +
    +

    NOTE that the commitment is not included in the IssuanceAction itself. As explained below, it is later computed by the validators and added to the NoteCommitmentTree.

    -

    Concrete applications

    -

    Bridging Assets Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - First, the issuance and burn mechanism can be used in conjunction to determine the

    -

    Asset Features - By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,

    -
    -

    System Message: ERROR/3 (zip-0227.rst line 194)

    -

    Unexpected indentation.

    -
    -
    -
      -
    • by setting finalize = 1 from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      • -
    -
    -
    -

    System Message: WARNING/2 (zip-0227.rst line 195)

    -

    Block quote ends without a blank line; unexpected unindent.

    -
    +

    Concrete Applications

    +

    Bridging Assets Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

      -
    • -
      -
      Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by
      -
      -
        -
      • issuing a last set of tokens of that specific AssetId, while at the same time setting finalize = 1, or by
        • -
      • issuing a transaction with a single note in the issuance action pertaining to that AssetId, where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations).
        • -
      -
      -
      +
    • First, the issuance and burn mechanism can be used in conjunction to determine the
      • +
    +

    Asset Features

    +
      +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example, +
        +
      • by setting finalize = 1 from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • +
      +
      • +
    • Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by +
        +
      • issuing a last set of tokens of that specific + \(\mathsf{AssetId}\) + , while at the same time setting finalize = 1, or by
        • +
      • issuing a transaction with a single note in the issuance action pertaining to that + \(\mathsf{AssetId}\) + , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations).
        • +
      • -
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each AssetId corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
      • +
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each + \(\mathsf{AssetId}\) + corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.

    Consensus Rule Changes

    -

    For the IssueBundle, - Verify the RedPallas-based issuance authorization signature on SIGHASH, authorization is valid, based on authorization.VerifySig(ik, SIGHASH)

    -

    For each IssueAction in IssueBundle: - check that asset_desc is a string with 0 < byte size <= 512 - retrieve AssetId from the first note in the sequence and check that AssetId = GroupHash^{mathbb{P}}(ik || asset_desc) is properly derived - check that the AssetId does not exist in the previously_finalized set in the global state - check that every note in the IssueAction contains the same AssetId and also that every note is of type Note and is properly constructed as - \(note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) -

    -

    If all of the above checks pass, do the following: - For each note, compute the note commitment as - \(cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) - and - add cm to the Merkle tree of note commitments, NoteCommitmentTree - If finalize = 1, add AssetId to the previously_finalized set in the global state

    +

    For the IssueBundle:

    +
      +
    • Verify the RedPallas-based issuance authorization signature on SIGHASH, authorization is valid, based on authorization.VerifySig(ik, SIGHASH)
      • +
    +

    For each IssueAction in IssueBundle:

    +
      +
    • check that + \(\mathsf{asset\_desc}\) + is a string with 0 < byte size <= 512
      • +
    • retrieve + \(\mathsf{AssetId}\) + from the first note in the sequence and check that + \(\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}\) + is properly derived
      • +
    • check that the + \(\mathsf{AssetId}\) + does not exist in the previously_finalized set in the global state
      • +
    • check that every note in the IssueAction contains the same + \(\mathsf{AssetId}\) + and also that every note is of type Note and is properly constructed as + \(note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) +
      • +
    +

    If all of the above checks pass, do the following:

    +
      +
    • For each note, compute the note commitment as + \(cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) + and
      • +
    • add cm to the Merkle tree of note commitments, NoteCommitmentTree
      • +
    • If finalize = 1, add + \(\mathsf{AssetId}\) + to the previously_finalized set in the global state
      • +

    Rationale

    The following is a list of rationale for different decisions made in the proposal:

    • The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets.
      • -
    • -
      -
      the asset_desc is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are:
      -
      -
        -
      • links for storage such as for NFTs
        • -
      • other metadata for native assets
        • -
      • bridging information for wrapped assets (chain of origin, issuer name, etc)
        • -
      • information to be committed by the issuer, though not enforceable by the protocol
        • -
      -
      -
      +
    • The + \(\mathsf{asset\_desc}\) + is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: +
        +
      • links for storage such as for NFTs
        • +
      • other metadata for native assets
        • +
      • bridging information for wrapped assets (chain of origin, issuer name, etc)
        • +
      • information to be committed by the issuer, though not enforceable by the protocol
        • +
    @@ -326,18 +398,32 @@

    System Message: WARNING/2 (zip-0227.rst line 195)

    Security and Privacy Considerations

    Issuer Key or AssetId Compromise

    -

    The design of this protocol does not allow for a rotation of the issuerValidatingKey, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: - If an asset ID is compromised (and not the issuer verification key), the finalize boolean for that asset should be set to 0 and a new AssetId generated instead. - If an issuer verification key is compromised, the finalize boolean for all the assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new AssetId.

    -

    Briding Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    +

    The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended:

    +
      +
    • If an asset ID is compromised (and not the issuer verification key), the finalize boolean for that asset should be set to 0 and a new + \(\mathsf{AssetId}\) + generated instead.
      • +
    • If an issuer verification key is compromised, the finalize boolean for all the assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new + \(\mathsf{AssetId}\) + .
      • +
    +

    Bridging Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    Other Considerations

    Implementing Zcash Nodes

    -

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping issuanceSupplyInfoMap from AssetId to issuanceSupplyInfoMap := (totalSupply, finalize) in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

    +

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping issuanceSupplyInfoMap from + \(\mathsf{AssetId}\) + to + \(\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}\) + in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

    Fee Structures

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    -

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying ik of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether.

    +

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying + \(\mathsf{ik}\) + of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether.

    Test Vectors

    diff --git a/zip-0227.rst b/zip-0227.rst index 9e7b4df9f..71021e636 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -25,7 +25,7 @@ The term "Orchard" in this document is to be interpreted as described in ZIP 224 We define the following additional terms: -- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (`AssetId`). +- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (:math:`\mathsf{AssetId}`). - Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool. - Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. - Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier. @@ -52,13 +52,13 @@ The design presented in this ZIP enables issuance of shielded assets in various - The supply of the asset can be limited in advance or not. - The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains). -See the Concrete Applications section for more details. +See the `Concrete Applications`_ section for more details. Requirements ============ -- Any user of the Zcash block chain can issue custom assets on chain -- The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain +- Any user of the Zcash block chain can issue custom assets on chain. +- The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain. - Issuing or changing the attributes of a specific asset should require cryptographic authorization. - The asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same asset identifier. @@ -74,71 +74,74 @@ Overview This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: -- at the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private -- in a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets -- every issuance action contains the `finiteIssuance` boolean that defines whether that specific custom asset can have further tokens issued or not -The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e.: assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +- At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. +- In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets. +- Every issuance action contains the ``finalize`` boolean that defines whether that specific custom asset can have further tokens issued or not. + +The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. Issuance Keys ------------- There are two keys relevant to the Issuer: -1. The `issuanceAuthorizingKey`, denoted as `isk`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. +1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. -2. The `issuanceValidatingKey`, denoted as `ik`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. +2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. -The two keys are derived in an analogous manner to the `spendAuthorizingKey` and `spendValidatingKey` keys, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. +The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. -- The `issuanceAuthorizingKey` is derived directly from the `spendingKey`, `sk`, as a private signature key: +- The issuance authorizing key is derived directly from the spending key, :math:`\mathsf{sk}`, as a private signature key: -:math:`\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])}` +.. math:: \mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])} -- The `issuanceValidatingKey` is derived from the `issuanceAuthorizingKey`, `isk`, as a public verification key: +- The issuance validating key is derived from the issuance authorizing key, :math:`\mathsf{isk}`, as a public verification key: -:math:`\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}` +.. math:: \mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)} This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. Asset Identifier ---------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols). From this asset descritpion, the specific asset identifier, `AssetId`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). -The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, `AssetId` as follows: +The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, :math:`\mathsf{AssetId}` as follows: -:math:`\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset_desc)}` +:math:`\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset\_desc)}` where -- `asset_desc` is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance -- `issuanceValidatingKey` is the public key of the issuer, used to verify the signature on the transaction SIGHASH and is defined as `ik` +- :math:`\mathsf{asset\_desc}` is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance +- :math:`\mathsf{ik}` is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above Global Issuance State --------------------- Issuance requires the following additions to the global state: -- `previously_finalized`, a set of `AssetId` that have been finalized (i.e.: the `finalize` flag has been set to `1`). + +- ``previously_finalized``, a set of :math:`\mathsf{AssetId}` that have been finalized (i.e.: the ``finalize`` flag has been set to ``1``). Issuance Action Description --------------------------- An issuance action, `IssueAction`, is the instance of issuing a specific custom asset, and contains the following fields: -- `asset_desc`: the asset description, a UTF-8 encoded string of up to 512 bytes + +- :math:`\mathsf{asset\_desc}`: the asset description, a UTF-8 encoded string of up to 512 bytes - `notes`: an array containing the unencrypted output notes of the recipients of the asset, of type `Note` -- `finalize`: a boolean that defines whether the issuance of that specific custom asset is finalized or not +- ``finalize``: a boolean that defines whether the issuance of that specific custom asset is finalized or not -Once `finiteSupply` is set to 1, it cannot be unset. For assets whose `finalize = 1`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose `finalize = 0`, new issuance actions can be issued in future transactions. These must use the same asset description, `asset_desc`, and can either maintain `finalize = 0` or change it to `1`, denoting the last transaction containing issuance of such custom asset. +Once ``finalize`` is set to 1, it cannot be unset. For assets whose ``finalize = 1``, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose ``finalize = 0``, new issuance actions can be issued in future transactions. These must use the same asset description, :math:`\mathsf{asset\_desc}`, and can either maintain ``finalize = 0`` or change it to ``finalize = 1``, denoting the last transaction containing issuance of such custom asset. -================= ================== ========================== ======================================================================== -Size Name Data Type Description -================= ================== ========================== ======================================================================== -Varies asset_desc byte Uni-code encoded string of varied size, up to 512 bytes -Varies nNotes compactSize The number of notes in the issuance action -noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action -1 bit finalize boolean The boolean that determines the finality of the issuance of that asset -================= ================== ========================== ======================================================================== +================= =============================== ========================== ======================================================================== +Size Name Data Type Description +================= =============================== ========================== ======================================================================== +Varies :math:`\mathsf{asset\_desc}` byte Uni-code encoded string of varied size, up to 512 bytes +Varies nNotes compactSize The number of notes in the issuance action +noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action +1 bit ``finalize`` boolean The boolean that determines the finality of the issuance of that asset +================= =============================== ========================== ======================================================================== We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the `NoteCommitmentTree` as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers. @@ -147,79 +150,93 @@ Issuance Bundle An issuance bundle, `IssueBundle`, is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields: -- `ik`: the `issuanceValidatingKey`, that allows the validators to verify that the `AssetId` is properly associated with the issuer -- `actions`: an array of issuance actions, of type `IssueAction` -- `authorization`: the signature of the transaction SIGHASH, signed by the `issuanceAuthorizingKey`, `isk`, that validates the issuance +- :math:`\mathsf{ik}`: the issuance validating key, that allows the validators to verify that the :math:`\mathsf{AssetId}` is properly associated with the issuer. +- `actions`: an array of issuance actions, of type `IssueAction`. +- `authorization`: the signature of the transaction SIGHASH, signed by the issuance authorizing key, :math:`\mathsf{isk}`, that validates the issuance . The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format. -======= ================== ========================== ========================================================================= +======= ==================== ========================== ========================================================================= Bytes Name Data Type Description -======= ================== ========================== ========================================================================= -Varies nIssueActions compactSize The number of issuance actions in the bundle -Varies vIssueActions IssueAction[nIssueActions] A sequence of issuance actions descriptions -32 ik byte[32] The public verification key of the issuer, used to validate the signature -64 authorization byte[64] The signature of the transaction SIGHASH, signed by the issuer -======= ================== ========================== ========================================================================= +======= ==================== ========================== ========================================================================= +Varies nIssueActions compactSize The number of issuance actions in the bundle +Varies vIssueActions IssueAction[nIssueActions] A sequence of issuance actions descriptions +32 :math:`\mathsf{ik}` byte[32] The issuance validating key of the issuer, used to validate the signature +64 authorization byte[64] The signature of the transaction SIGHASH, signed by the issuer +======= ==================== ========================== ========================================================================= Issuance Protocol ----------------- The issuer program performs the following operations For all actions `IssueAction`: -- encode `asset_desc` as 512 byte-string -- compute `AssetId` as :math:`GroupHash^{\mathbb{P}}(ik || asset_desc)` -- set the `finalize` boolean as desired (if more more issuance actions are to be created for this asset identifier, set `finalize = 0`, otherwise set `finalize = 1`) -- For each recipient `i`: + +- encode :math:`\mathsf{asset\_desc}` as 512 byte-string +- compute :math:`\mathsf{AssetId}` as :math:`GroupHash^{\mathbb{P}}(ik || asset_desc)` +- set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this asset identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) +- For each recipient ``i``: + - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` + - encode the `IssueAction` into the vector `vIssueActions` of the bundle For the `IssueBundle`: + - encode the `vIssueActions` vector -- encode the `ik` as 32 byte-string -- sign the `SIGHASH` of the transaction with the `issuanceAuthorizingKey`, `isk`, using the RedPallas signature scheme. The signature is then added to the issuance bundle. +- encode the :math:`\mathsf{ik}` as 32 byte-string +- sign the `SIGHASH` of the transaction with the issuance authorizing key, :math:`\mathsf{isk}`, using the RedPallas signature scheme. The signature is then added to the issuance bundle. -NOTE that the commitment is not included in the `IssuanceAction` itsefl. As explained below, it is later computed by the validators and added to the `NoteCommitmentTree`. +NOTE that the commitment is not included in the `IssuanceAction` itself. As explained below, it is later computed by the validators and added to the `NoteCommitmentTree`. -Concrete applications +Concrete Applications --------------------- **Bridging Assets** Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): + - First, the issuance and burn mechanism can be used in conjunction to determine the **Asset Features** -- By using the `finalize` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any asset associated to their issuer keys. For example, - - by setting `finalize = 1` from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + +- By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any asset associated to their issuer keys. For example, + + - by setting ``finalize = 1`` from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + - Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by - - issuing a last set of tokens of that specific `AssetId`, while at the same time setting `finalize = 1`, or by - - issuing a transaction with a single note in the issuance action pertaining to that `AssetId`, where the note will contain a `value = 0`. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations). -- Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each `AssetId` corresponds to `value = 1` at the fundamental unit level. Issuers and users should make sure that `finalize = 1` for each of the actions in this scenario. + + - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, while at the same time setting ``finalize = 1``, or by + - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations). + +- Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. Consensus Rule Changes ---------------------- -For the IssueBundle, +For the IssueBundle: + - Verify the RedPallas-based issuance authorization signature on `SIGHASH`, `authorization` is valid, based on `authorization.VerifySig(ik, SIGHASH)` For each `IssueAction` in `IssueBundle`: -- check that `asset_desc` is a string with `0 < byte size <= 512` -- retrieve `AssetId` from the first note in the sequence and check that `AssetId = GroupHash^{\mathbb{P}}(ik || asset_desc)` is properly derived -- check that the `AssetId` does not exist in the `previously_finalized` set in the global state -- check that every note in the `IssueAction` contains the same `AssetId` and also that every note is of type `Note` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` + +- check that :math:`\mathsf{asset\_desc}` is a string with `0 < byte size <= 512` +- retrieve :math:`\mathsf{AssetId}` from the first note in the sequence and check that :math:`\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}` is properly derived +- check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state +- check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetId}` and also that every note is of type `Note` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` If all of the above checks pass, do the following: + - For each note, compute the note commitment as :math:`cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` and - add `cm` to the Merkle tree of note commitments, `NoteCommitmentTree` -- If `finalize = 1`, add `AssetId` to the `previously_finalized` set in the global state +- If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set in the global state Rationale ========= The following is a list of rationale for different decisions made in the proposal: - The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets. -- the `asset_desc` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: +- The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: + - links for storage such as for NFTs - other metadata for native assets - bridging information for wrapped assets (chain of origin, issuer name, etc) @@ -305,11 +322,12 @@ Security and Privacy Considerations **Issuer Key or AssetId Compromise** -The design of this protocol does not allow for a rotation of the `issuerValidatingKey`, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: -- If an asset ID is compromised (and not the issuer verification key), the `finalize` boolean for that asset should be set to `0` and a new `AssetId` generated instead. -- If an issuer verification key is compromised, the `finalize` boolean for all the assets issued with that key should be set to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new `AssetId`. +The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: -**Briding Assets** +- If an asset ID is compromised (and not the issuer verification key), the ``finalize`` boolean for that asset should be set to `0` and a new :math:`\mathsf{AssetId}` generated instead. +- If an issuer verification key is compromised, the ``finalize`` boolean for all the assets issued with that key should be set to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new :math:`\mathsf{AssetId}`. + +**Bridging Assets** For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 [#zip-0226]_. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset. Other Considerations @@ -318,7 +336,7 @@ Other Considerations Implementing Zcash Nodes ------------------------ -Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping `issuanceSupplyInfoMap` from `AssetId` to `issuanceSupplyInfoMap := (totalSupply, finalize)` in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets. +Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets. Fee Structures -------------- @@ -328,7 +346,7 @@ The fee mechanism described in this ZIP will follow the mechanism described in Z Future Work ----------- -In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying `ik` of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether. +In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying :math:`\mathsf{ik}` of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether. Test Vectors ============ From b009b51b63dbc18f1b9e959760c1a08b37d1c026 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 19 Dec 2022 23:43:25 +0530 Subject: [PATCH 028/101] typographical improvements in ZIP 226 --- zip-0226.html | 48 ++++++++++++++++++++++++++++++++++-------------- zip-0226.rst | 33 ++++++++++++++------------------- 2 files changed, 48 insertions(+), 33 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 52511a770..7be5a5656 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -26,7 +26,9 @@

    The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

    We define the following additional terms:

      -
    • Asset: A type of note that can be transferred on the Zcash block chain, identified by the AssetId parameter. +
    • Asset: A type of note that can be transferred on the Zcash block chain, identified by the + \(\mathsf{AssetId}\) + parameter.
      • ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
      @@ -34,7 +36,9 @@
    • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
    • Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain.
    • Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain.
      • -
    • Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific AssetId. The Split Note is not spent in the transaction.
      • +
    • Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific + \(\mathsf{AssetId}\) + . The Split Note is not spent in the transaction.
    • Split Action: a Zcash Shielded Asset Action that contains a Split Note.
    @@ -45,7 +49,7 @@

    The current Orchard protocol does not 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.

    Overview

    -

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the AssetId of the Asset in question, which we call +

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call \(\mathsf{AssetId}\) .

    The asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), and by extension the balance of an Orchard transaction. That is, the sum of all the @@ -62,8 +66,12 @@ \(\mathsf{AssetId}\) identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same \(\mathsf{AssetId}\) - is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same AssetId, and (2) that only actions with the same asset identifier will balance out in the binding and balance signature.

    -

    In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the AssetId of the output note of that split action is the output of a PRF.

    + is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same + \(\mathsf{AssetId}\) + , and (2) that only actions with the same asset identifier will balance out in the binding and balance signature.

    +

    In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the + \(\mathsf{AssetId}\) + of the output note of that split action is the output of a PRF.

    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 than what is used in Orchard to unshield ZEC, by using the \(\mathsf{valueBalance}\) of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets.

    @@ -71,7 +79,9 @@

    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 identifier of the asset. Every asset is defined by the asset description, asset_desc, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, +

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, + \(\mathsf{asset\_desc}\) + , which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, \(\mathsf{AssetId}\) , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    This @@ -172,15 +182,21 @@

    Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification:

    1. The split input note could be the same note as the original (non-split) Action,
      2. -
    2. The split input note could be a different unspent note of the same AssetId (note that the note will not actually be spent)
      3. -
    3. The split input note could be an already spent note of the same AssetId (note that by zeroing the value in the circuit, we prevent double spending)
      4. +
    4. The split input note could be a different unspent note of the same + \(\mathsf{AssetId}\) + (note that the note will not actually be spent)
      5. +
    5. The split input note could be an already spent note of the same + \(\mathsf{AssetId}\) + (note that by zeroing the value in the circuit, we prevent double spending)

    The specific circuit changes are presented below.

    Circuit Statement

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset identifier system.

    -

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same AssetId:

    +

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same + \(\mathsf{AssetId}\) + :

    • The asset identifier, \(\mathsf{AssetId}\) @@ -217,10 +233,10 @@
    • -
      Add a boolean “split” variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
      +
      Add a boolean split variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
        -
      • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input
        • +
      • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input
      @@ -253,7 +269,7 @@ as \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\)
      • -
    • if split = 1 set +
    • if split = 1 set \(\psi' = \mathsf{randomSample}\) , otherwise set \(\psi' = \psi^{old}\) @@ -323,7 +339,9 @@ \(\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]\)

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

      -

      Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective AssetId as the value base point of the Pedersen Commitment. This is done as follows

      +

      Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective + \(\mathsf{AssetId}\) + as the value base point of the Pedersen Commitment. This is done as follows

      \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

      @@ -356,7 +374,9 @@
    32ik + \(\mathsf{ik}\) + byte[32]The public verification key of the issuer, used to validate the signatureThe issuance validating key of the issuer, used to validate the signature
    64
    -

    And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the AssetId). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action.

    +

    And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the + \(\mathsf{AssetId}\) + ). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action.

    Other Considerations

    Transaction Fees

    diff --git a/zip-0226.rst b/zip-0226.rst index 9f310016e..280204e60 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -26,14 +26,14 @@ The term "Orchard" in this document is to be interpreted as described in ZIP 224 We define the following additional terms: -- Asset: A type of note that can be transferred on the Zcash block chain, identified by the `AssetId` parameter. +- Asset: A type of note that can be transferred on the Zcash block chain, identified by the :math:`\mathsf{AssetId}` parameter. - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. - Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. -- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific `AssetId`. The Split Note is not spent in the transaction. +- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific :math:`\mathsf{AssetId}`. The Split Note is not spent in the transaction. - Split Action: a Zcash Shielded Asset Action that contains a Split Note. Abstract @@ -50,15 +50,15 @@ The current Orchard protocol does not support custom assets. Enabling multi-asse Overview ======== -In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the `AssetId` of the Asset in question, which we call :math:`\mathsf{AssetId}`. +In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call :math:`\mathsf{AssetId}`. The asset identifier will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred. As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same `AssetId`, and (2) that only actions with the same asset identifier will balance out in the binding and balance signature. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are asset identifiers in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same asset identifier will balance out in the binding and balance signature. -In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the `AssetId` of the output note of that split action is the output of a PRF. +In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the :math:`\mathsf{AssetId}` of the output note of that split action is the output of a PRF. 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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. @@ -70,7 +70,7 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, `asset_desc`, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom asset. Note that the :math:`\mathsf{AssetId}` of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}`. @@ -91,10 +91,8 @@ In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCom Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have - :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \{\mathsf{cm},\bot\}` - The nullifier is generated in the same manner as in the Orchard protocol. Value Commitment @@ -116,10 +114,8 @@ being transferred. 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**. This enables the final balance of the transaction to be securely computed, such that each asset identifier is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes - :math:`\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` - where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^*_{AssetId}}` is the value of the note of identifier :math:`\mathsf{AssetId}`, and .. _`value base`: @@ -143,7 +139,6 @@ Then the verifier MUST compute :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` - And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset identifier**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. @@ -161,8 +156,8 @@ will be zeroed in split Actions and the nullifier will be randomized, making the Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification: 1. The split input note could be the same note as the original (non-split) Action, -2. The split input note could be a different unspent note of the same `AssetId` (note that the note will not actually be spent) -3. The split input note could be an already spent note of the same `AssetId` (note that by zeroing the value in the circuit, we prevent double spending) +2. The split input note could be a different unspent note of the same :math:`\mathsf{AssetId}` (note that the note will not actually be spent) +3. The split input note could be an already spent note of the same :math:`\mathsf{AssetId}` (note that by zeroing the value in the circuit, we prevent double spending) The specific circuit changes are presented below. @@ -172,7 +167,7 @@ Circuit Statement The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset identifier system. **Asset Identifier Equality:** the following constraints must be added to ensure that the input and output note are of the -same `AssetId`: +same :math:`\mathsf{AssetId}`: - The asset identifier, :math:`\mathsf{AssetId}`, for the note is witnessed once, as an auxiliary input. - The witnessed asset identifier, :math:`\mathsf{AssetId}`, is added to the old note commitment input. @@ -187,13 +182,13 @@ same `AssetId`: - The Value Commitment Integrity should be changed - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}` -- Add a boolean “split” variable as an auxiliary witness. This variable is to be activated `split = 1` if the Action in question is a split and `split = 0` if the Action is actually spending an input note: - - If `split = 1` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input +- Add a boolean ``split`` variable as an auxiliary witness. This variable is to be activated ``split = 1`` if the Action in question is a split and ``split = 0`` if the Action is actually spending an input note: + - If ``split = 1`` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input - The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. - The Nullifier Integrity will be changed to prevent the identification of notes - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - - if `split = 1` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` + - if ``split = 1`` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. @@ -232,7 +227,7 @@ For every custom asset that is burnt, we add to the `assetBurn` vector the tuple The value balances for each asset identifier in `assetBurn` represents the amount of that asset identifier that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). -Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective `AssetId` as the value base point of the Pedersen Commitment. This is done as follows +Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective :math:`\mathsf{AssetId}` as the value base point of the Pedersen Commitment. This is done as follows :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` @@ -253,7 +248,7 @@ Similar to version 5 transaction format, with the following modifications to the | | | | 8 bytes of valueBalance | +-----------------+-------------+-----------------------------------+-------------------------+ -And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the `AssetId`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action. +And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the :math:`\mathsf{AssetId}`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action. Other Considerations ==================== From 820cfaecdb87b9c199c392fdeb2346a7ed66dad4 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 20 Dec 2022 01:27:57 +0530 Subject: [PATCH 029/101] resolving open comments from PR#628 --- zip-0226.html | 34 ++++++++++++++++++---------------- zip-0226.rst | 28 ++++++++++++++++------------ 2 files changed, 34 insertions(+), 28 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 7be5a5656..f13d867f0 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -36,17 +36,17 @@
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
  • Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain.
  • Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain.
    • -
  • Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific +
  • Split Input: an Action input identifying a Zcash Shielded Asset note, used to ensure that the output note of that Action is of a validly issued \(\mathsf{AssetId}\) - . The Split Note is not spent in the transaction.
    • -
  • Split Action: a Zcash Shielded Asset Action that contains a Split Note.
    • + when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input. +
  • Split Action: a Zcash Shielded Asset Action that contains a Split Input.

    • Abstract

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

    Motivation

    -

    The current Orchard protocol does not 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.

    +

    The current Orchard protocol does not 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.

    Overview

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call @@ -157,9 +157,9 @@ .

    Value Balance Verification

    -

    In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, +

    In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason why no changes to this process are needed is that no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) - , so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is burnt, as we will see below in the burn mechanism.

    + . No net amount of any other asset identifier will be revealed, and the number of asset identifiers in the transaction is also hidden. The only exception to this is in the case that an asset is burnt, as we will see below in the burn mechanism.

    For a total of \(n\) actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

    @@ -170,24 +170,26 @@

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification 7, by verifying the bindingSignature on the SIGHASH message.

    +

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 7.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    -

    This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions cannot be of any asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    +

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    -

    Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification:

    +

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    +

    Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before.

    +

    Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action:

      -
    1. The split input note could be the same note as the original (non-split) Action,
      2. -
    2. The split input note could be a different unspent note of the same +
    3. The Split Input note could be another note of the same asset identifier that is being spent by this transaction (but not by this Split Input).
      4. +
    4. The Split Input note could be a different unspent note of the same \(\mathsf{AssetId}\) - (note that the note will not actually be spent)
      5. -
    5. The split input note could be an already spent note of the same + (note that the note will not actually be spent).
      6. +
    6. The Split Input note could be an already spent note of the same \(\mathsf{AssetId}\) - (note that by zeroing the value in the circuit, we prevent double spending)
      7. + (note that by zeroing the value in the circuit, we prevent double spending).

    The specific circuit changes are presented below.

    @@ -213,11 +215,11 @@
  • The fixed-base multiplication constraints 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 value base equation is the auxiliary input +
  • The witness to the value base point, as defined in the value base equation is the auxiliary input \(\mathsf{AssetId}\) .
    • -

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the asset identifier for the output note in the Split Actions:

    +

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the asset identifier for the output note in a Split Action:

    • diff --git a/zip-0226.rst b/zip-0226.rst index 280204e60..06e916dd3 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -33,8 +33,8 @@ We define the following additional terms: - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. - Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. -- Split Note: a Zcash Shielded Asset spend note that is used within an Action to ensure the output note of that Action is of a specific :math:`\mathsf{AssetId}`. The Split Note is not spent in the transaction. -- Split Action: a Zcash Shielded Asset Action that contains a Split Note. +- Split Input: an Action input identifying a Zcash Shielded Asset note, used to ensure that the output note of that Action is of a validly issued :math:`\mathsf{AssetId}` when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input. +- Split Action: a Zcash Shielded Asset Action that contains a Split Input. Abstract ======== @@ -46,7 +46,7 @@ in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP Motivation ========== -The current Orchard protocol does not 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. +The current Orchard protocol does not 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. Overview ======== @@ -129,7 +129,7 @@ Where :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mat Value Balance Verification -------------------------- -In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason is because no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`, so no net amount of any asset identifier will be revealed, and neither the nnumber of asset identifiers in the transaction. The only exception to this is in the case that an asset is *burnt*, as we will see below in the `burn mechanism`_. +In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason why no changes to this process are needed is that no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other asset identifier will be revealed, and the number of asset identifiers in the transaction is also hidden. The only exception to this is in the case that an asset is *burnt*, as we will see below in the `burn mechanism`_. For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key @@ -139,7 +139,7 @@ Then the verifier MUST compute :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` -And uses it to verify the binding signature, as described in §4.14 of the Zcash Specification [#protocol-binding]_, by verifying the `bindingSignature` on the `SIGHASH` message. +and use it to verify the `bindingSignature` on the `SIGHASH` message, as described in §4.14 of the Zcash Specification [#protocol-binding]_. As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset identifier**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. @@ -148,16 +148,20 @@ Split Notes One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. -This, however, brings some issues when it comes to adding multiple asset identifiers, as the output note of the split Actions *cannot* be of *any* asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination of) an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. +This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions *cannot* be of *any* Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. -Note that this is enough to create a chain of induction that ensures that all output notes of a transfer are actual outputs of a GroupHash, preventing any malleability attacks, as they originate in the Issuance protocol, which is publicly verified. Furthermore, we do not care about whether the note is owned by the sender, or whether it was nullified before. Wallets and other clients have a choice to make to ensure the asset identifier is the preserved for the output note of a split Action, for the value balance verification: +This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets. -1. The split input note could be the same note as the original (non-split) Action, -2. The split input note could be a different unspent note of the same :math:`\mathsf{AssetId}` (note that the note will not actually be spent) -3. The split input note could be an already spent note of the same :math:`\mathsf{AssetId}` (note that by zeroing the value in the circuit, we prevent double spending) +Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before. + +Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action: + +1. The Split Input note could be another note of the same asset identifier that is being spent by this transaction (but not by this Split Input). +2. The Split Input note could be a different unspent note of the same :math:`\mathsf{AssetId}` (note that the note will not actually be spent). +3. The Split Input note could be an already spent note of the same :math:`\mathsf{AssetId}` (note that by zeroing the value in the circuit, we prevent double spending). The specific circuit changes are presented below. @@ -176,9 +180,9 @@ same :math:`\mathsf{AssetId}`: **Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes - The fixed-base multiplication constraints between the value and the value base point of the value commitment, :math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two. -- The witness to the value base-point, as defined in the `value base`_ equation is the auxiliary input :math:`\mathsf{AssetId}`. +- The witness to the value base point, as defined in the `value base`_ equation is the auxiliary input :math:`\mathsf{AssetId}`. -**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the asset identifier for the output note in the Split Actions: +**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the asset identifier for the output note in a Split Action: - The Value Commitment Integrity should be changed - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}` From fa9809aa10ebf789ac87f15104344a93832a77ad Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 20 Dec 2022 12:53:24 +0530 Subject: [PATCH 030/101] resolving open comments from PR#628 --- zip-0227.html | 25 ++++++++++++------------- zip-0227.rst | 14 +++++++------- 2 files changed, 19 insertions(+), 20 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 2c4965635..0ef84b541 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -24,19 +24,18 @@

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

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

      The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

      +

      The terms "Zcash Shielded Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 4.

      We define the following additional terms:

      • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier ( \(\mathsf{AssetId}\) ).
        • -
      • Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool.
        • -
      • Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain.
      • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier.
      • Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.

    Abstract

    -

    ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA.

    +

    ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

    Motivation

    The Orchard protocol deployed in NU5 does not 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.

    @@ -62,14 +61,14 @@

    Specification

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    Overview

    -

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

    +

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the block chain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

    The protocol was designed with three main properties in mind:

    • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets.
    • Every issuance action contains the finalize boolean that defines whether that specific custom asset can have further tokens issued or not.
    -

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    +

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    Issuance Keys

    There are two keys relevant to the Issuer:

    @@ -79,9 +78,9 @@ , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
  • The issuance validating key, denoted as \(\mathsf{ik}\) - , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
    • + , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all block chain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. -

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    +

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    • The issuance authorizing key is derived directly from the spending key, \(\mathsf{sk}\) @@ -94,14 +93,14 @@ , as a public verification key:
    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, \(\mathsf{asset\_desc}\) - , which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, + , which is a global byte string (valid across all -future- Zcash shielded protocols). From this asset description, the specific asset identifier, \(\mathsf{AssetId}\) - , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    + , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve).

    The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, \(\mathsf{AssetId}\) as follows:

    @@ -272,7 +271,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -407,7 +406,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -418,7 +417,7 @@ in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying diff --git a/zip-0227.rst b/zip-0227.rst index 71021e636..ba78e7419 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -23,18 +23,18 @@ The term "network upgrade" in this document is to be interpreted as described in The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. +The terms "Zcash Shielded Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 [#zip-0226]_. + We define the following additional terms: - Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (:math:`\mathsf{AssetId}`). -- Zcash Shielded Asset: an asset with issuance defined on the Zcash block chain, and, with this ZIP, belonging to the Orchard anonymity pool. -- Wrapped Asset: a ZSA asset with native issuance defined outside the Zcash block chain. - Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier. - Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction. Abstract ======== -ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. This ZIP must only be implemented in conjuction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, as it produces notes that can only be transferred under ZSA. +ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. This ZIP must only be implemented in conjuction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA. Motivation ========== @@ -71,7 +71,7 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the blockchain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. +This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the block chain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: @@ -79,7 +79,7 @@ The protocol was designed with three main properties in mind: - In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets. - Every issuance action contains the ``finalize`` boolean that defines whether that specific custom asset can have further tokens issued or not. -The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. Issuance Keys ------------- @@ -88,7 +88,7 @@ There are two keys relevant to the Issuer: 1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. -2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all blockchain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. +2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all block chain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. @@ -105,7 +105,7 @@ This allows the issuer to use the same wallet it usually uses to transfer assets Asset Identifier ---------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve). The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, :math:`\mathsf{AssetId}` as follows: From 0d9528ede6090c96870fe2187f7995d0dfcdab3e Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 24 Dec 2022 11:09:38 +0530 Subject: [PATCH 031/101] resolving comments from PR#628 --- zip-0226.html | 136 ++++++++++++++++++++++++++------------------------ zip-0226.rst | 98 ++++++++++++++++++------------------ 2 files changed, 119 insertions(+), 115 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index f13d867f0..49b626eef 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -30,7 +30,7 @@ \(\mathsf{AssetId}\) parameter.

      -
    • ZEC is the default (and currently the only defined) asset for the Zcash mainnet.
      • +
    • ZEC is the default (and currently the only defined) Asset for the Zcash mainnet.
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
    • @@ -43,16 +43,16 @@

    Abstract

    -

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4.

    +

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 5. The transfer and burn of such Assets is defined in ZIP 226 4.

    Motivation

    -

    The current Orchard protocol does not 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.

    +

    The current Orchard protocol does not 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.

    Overview

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call \(\mathsf{AssetId}\) .

    -

    The asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The Asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), 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}-value^{new}}\) @@ -62,62 +62,64 @@ , in the Homomorphic Pedersen Commitment that generates 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 in the transaction. We propose to make 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 in the transaction. We propose to make the \(\mathsf{AssetId}\) - identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same + identifier an auxiliary input to the proof for each Action, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetId}\) - is used in the old note commitment, in the new note commitment and in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same + is used in the old note commitment, in the new note commitment and as the base point + \(\mathcal{V}^\mathsf{Orchard}\) + in the value commitment. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetId}\) - , and (2) that only actions with the same asset identifier will balance out in the binding and balance signature.

    -

    In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the + , and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures.

    +

    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{AssetId}\) - of the output note of that split action is the output of a PRF.

    -

    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 than what is used in Orchard to unshield ZEC, by using the + of the output note of that split Action is the output of a PRF.

    +

    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 \(\mathsf{valueBalance}\) - of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets.

    + of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Native 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 identifier of the asset. Every asset is defined by the asset description, +

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, \(\mathsf{asset\_desc}\) - , which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, + , which is a global byte string (valid across all -future- Zcash protocols). From this Asset description the specific Asset identifier, \(\mathsf{AssetId}\) , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    This \(\mathsf{AssetId}\) - will be the base point of the value commitment for the specific custom asset. Note that the + will be the base point of the value commitment for the specific custom Asset. Note that the \(\mathsf{AssetId}\) - of the ZEC asset will be kept as the original value base-point, + of the ZEC Asset will be kept as the original value base point, \(\mathcal{V}^\mathsf{Orchard}\) .

    -

    In future network and protocol upgrades, the same asset description string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset identifier, +

    In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset identifier, \(\mathsf{AssetId}\) - , from one group to another one.

    + , from one shielded protocol to another.

    Note Structure & Commitment

    -

    First, we need to adapt the components that define the assets, i.e.: notes. A ZSA note differs from an Orchard note by including the identifier of asset, +

    First, we need to adapt the components that define the Assets, i.e.: notes. A ZSA note differs from an Orchard note by including the identifier of the Asset, \(\mathsf{AssetId}\) - . So an ZSA note looks like:

    + . So a ZSA note looks like:

    \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\)

    Where \(\mathsf{AssetId}\) - is the unique random group element that identifies each asset in the Pallas curve 8, 9 of the Orchard protocol.

    + is the unique random element of the Pallas group 8 that identifies each Asset in the Orchard protocol.

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC assets, the asset identifier will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment 10 allows us to add the asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have

    + in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 10 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have

    - \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \{\mathsf{cm},\bot\}\) + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} \cup \{\bot\}\)

    The nullifier is generated in the same manner as in the Orchard protocol.

    Value Commitment

    -

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

    +

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

    \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    @@ -135,7 +137,7 @@ and \(\mathcal{R}^{\mathsf{Orchard}}\) are fixed for every value commitment, as the values represent the amount of ZEC being transferred.

    -

    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. This enables the final balance of the transaction to be securely computed, such that each asset identifier is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes

    +

    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. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes

    \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    @@ -147,7 +149,7 @@ \(\mathsf{AssetId}\) , and

    - \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || ik || \mathsf{asset_desc})}\) + \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || } \mathsf{ik} \texttt{ || } \mathsf{asset\_desc} \texttt{)}\)

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) @@ -157,12 +159,12 @@ .

    Value Balance Verification

    -

    In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol 7. The main reason why no changes to this process are needed is that no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, +

    In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol 7. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) - . No net amount of any other asset identifier will be revealed, and the number of asset identifiers in the transaction is also hidden. The only exception to this is in the case that an asset is burnt, as we will see below in the burn mechanism.

    + . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    For a total of \(n\) - actions in a transfer, the prover can still sign the SIGHASH of the transaction using the binding signature key

    + Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key

    \(\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}\)

    @@ -170,20 +172,20 @@

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 7.

    +

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 7.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    -

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that every input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    +

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before.

    Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action:

      -
    1. The Split Input note could be another note of the same asset identifier that is being spent by this transaction (but not by this Split Input).
      2. +
    2. The Split Input note could be another note of the same Asset identifier that is being spent by this transaction (but not by this Split Input).
    3. The Split Input note could be a different unspent note of the same \(\mathsf{AssetId}\) (note that the note will not actually be spent).
      4. @@ -195,22 +197,22 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the Asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

      -
    • The asset identifier, +
    • The Asset identifier, \(\mathsf{AssetId}\) , for the note is witnessed once, as an auxiliary input.
      • -
    • The witnessed asset identifier, +
    • The witnessed Asset identifier, \(\mathsf{AssetId}\) , is added to the old note commitment input.
      • -
    • The witnessed asset identifier, +
    • The witnessed Asset identifier, \(\mathsf{AssetId}\) , is added to the new note commitment input.
    -

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes

    +

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset identifier, as represented in the notes:

    • The fixed-base multiplication constraints between the value and the value base point of the value commitment, \(\mathsf{cv}\) @@ -219,7 +221,7 @@ \(\mathsf{AssetId}\) .
    -

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the asset identifier for the output note in a Split Action:

    +

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the Asset identifier for the output note in a Split Action:

    • @@ -238,14 +240,14 @@
      Add a boolean split variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
        -
      • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input
        • +
      • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input.
    • -
      The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes):
      +
      The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes):
      • Check that (path, pos) is a valid Merkle path of depth @@ -271,27 +273,29 @@ as \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\)
        • -
      • if split = 1 set - \(\psi' = \mathsf{randomSample}\) - , otherwise set +
      • if + \(split = 0\) + then constrain \(\psi' = \psi^{old}\) -
        • + . (Otherwise + \(\psi'\) + should be sampled randomly.)

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes.

    -

    The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

    +

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

    • -
      The input note in the old note commitment integrity must either include an asset identifier (ZSA note) or not (ZEC-Orchard note)
      +
      The input note in the old note commitment integrity must either include an Asset identifier (ZSA note) or not (ZEC-Orchard note)
      • -
        If the asset identifier auxiliary input is set +
        If the Asset identifier auxiliary input is set \(\mathsf{AssetId}\) = \(\mathcal{V}^\mathsf{Orchard}\) @@ -323,35 +327,35 @@

      Backward Compatibility

      -

      In order to have a "clean" backwards 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: - The input notes with an asset identifer denote the ZSA custom assets, generating a note commitment that includes the asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the asset identifier, in order to maintain the referencability to the Merkle tree - 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

      +

      In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the ZSA custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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

    Burn Mechanism

    -

    The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

    -

    In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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 burn mechanism may be needed for off-boarding the Wrapped Assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

    +

    In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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.

    First, contrary to the strict transfer transaction, we allow the sender to include a \(\mathsf{valueBalance_{AssetId}}\) - variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular + variable for every Asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular \(\mathsf{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 + 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 \((\mathsf{valueBalance_{AssetId}, 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.

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

    \(\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]\)

    -

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

    -

    Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective +

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

    +

    Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective \(\mathsf{AssetId}\) as the value base point of the Pedersen Commitment. This is done as follows

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    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, the number of assets, nor their identifiers will be revealed, except in the case that an asset is burnt.

    -

    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, the unshielding is not not be possible for custom assets.

    +

    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, the number of Assets, nor their identifiers will be revealed, except in the case that an Asset is burnt.

    +

    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.

    ZSA Transaction Structure

    -

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    +

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    @@ -366,13 +370,13 @@ - + - +
    varies nAssetBurn compactSizenumber of assets burntnumber of Assets burnt
    40*nAssetBurn vAssetBurn bytes[40][nAssetBurn]32 bytes asset type_t, 8 bytes of valueBalance32 bytes Asset type_t, 8 bytes of valueBalance
    @@ -382,13 +386,13 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    Security and Privacy

    • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
      • -
    • When including new assets we would like to maintain the amount and identifiers of assets private, which is achieved with the design
      • -
    • We prevent the "roadblock" attack on the asset identifer by ensuring the output notes receive an asset identifier that exists on the global state
      • +
    • When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design
      • +
    • We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state

    Deplopyment

    diff --git a/zip-0226.rst b/zip-0226.rst index 06e916dd3..006870fc6 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -28,7 +28,7 @@ We define the following additional terms: - Asset: A type of note that can be transferred on the Zcash block chain, identified by the :math:`\mathsf{AssetId}` parameter. - - ZEC is the default (and currently the only defined) asset for the Zcash mainnet. + - ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. @@ -40,27 +40,27 @@ Abstract ======== ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the -Orchard protocol that enables the creation, transfer, and burn of custom assets on the Zcash chain. The creation of such assets is defined -in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. +Orchard protocol that enables the creation, transfer, and burn of custom Assets on the Zcash chain. The creation of such Assets is defined +in ZIP 227 [#zip-0227]_. The transfer and burn of such Assets is defined in ZIP 226 [#zip-0226]_. Motivation ========== -The current Orchard protocol does not 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. +The current Orchard protocol does not 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. Overview ======== In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call :math:`\mathsf{AssetId}`. -The asset identifier will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred. +The Asset identifier will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred. As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof, represented already as a point in the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment, in the new note commitment **and** in the value commitment as the base point of the value. This ensures that (1) the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same asset identifier will balance out in the binding and balance signature. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset identifiers in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof for each Action, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment, in the new note commitment **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures. -In order to ensure the security of the transfers, and as we will explain below, we are replacing input dummy notes for custom assets, as we need to enforce that the :math:`\mathsf{AssetId}` of the output note of that split action is the output of a PRF. +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 :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a PRF. -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 than what is used in Orchard to unshield ZEC, by using the :math:`\mathsf{valueBalance}` of the asset in question. Burning assets is useful for many purposes, including bridging of wrapped assets and removing supply of native assets. +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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Native Assets. Specification ============= @@ -70,28 +70,28 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash protocols). From this Asset description the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). -This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom asset. Note that the :math:`\mathsf{AssetId}` of the ZEC asset will be kept as the original value base-point, :math:`\mathcal{V}^\mathsf{Orchard}`. +This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom Asset. Note that the :math:`\mathsf{AssetId}` of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`. -In future network and protocol upgrades, the same asset description string can be carried on, with potentially a mapping into a different curve or group. In that case, the turnstile should know how to transform the asset identifier, :math:`\mathsf{AssetId}`, from one group to another one. +In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset identifier, :math:`\mathsf{AssetId}`, from one shielded protocol to another. Note Structure & Commitment --------------------------- -First, we need to adapt the components that define the assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the identifier of asset, :math:`\mathsf{AssetId}`. So an ZSA note looks like: +First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note looks like: :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` -Where :math:`\mathsf{AssetId}` is the unique random group element that identifies each asset in the Pallas curve [#protocol-pallasandvesta]_, [#pasta-evidence]_ of the Orchard protocol. +Where :math:`\mathsf{AssetId}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. -In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC assets, the asset identifier will be added as an input to the commitment computation. As we will see, the recursive structure of the Sinsemilla-base commitment [#protocol-concretesinsemillacommit]_ allows us to add the asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. +In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. -Since the commitment output is still indistinguishable with the original Orchard ZEC note commitments, by definition of the Sinsemilla hash, ZSA note commitments will be added to the same Merkle Commitment Tree. In essence, we have +The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have -:math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \{\mathsf{cm},\bot\}` +:math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} \cup \{\bot\}` The nullifier is generated in the same manner as in the Orchard protocol. @@ -112,7 +112,7 @@ In the case of the Orchard protocol, we see that the base points :math:`\mathcal :math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC being transferred. -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**. This enables the final balance of the transaction to be securely computed, such that each asset identifier is balanced independently, as the assets are not meant to be fungible. The value commitment then becomes +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**. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes :math:`\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` @@ -120,7 +120,7 @@ where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{A .. _`value base`: -:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || ik || \mathsf{asset_desc})}` +:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || } \mathsf{ik} \texttt{ || } \mathsf{asset\_desc} \texttt{)}` :math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` @@ -129,9 +129,9 @@ Where :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mat Value Balance Verification -------------------------- -In order to verify the balance of the different assets, verifier performs exactly the same the process as for the Orchard protocol [#protocol-binding]_. The main reason why no changes to this process are needed is that no custom assets can be unshielded, so all custom assets are contained within the shielded ZSA pool. This means that the net balance of the input and output values is zero, with only one asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other asset identifier will be revealed, and the number of asset identifiers in the transaction is also hidden. The only exception to this is in the case that an asset is *burnt*, as we will see below in the `burn mechanism`_. +In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol [#protocol-binding]_. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. -For a total of :math:`n` actions in a transfer, the prover can still sign the `SIGHASH` of the transaction using the binding signature key +For a total of :math:`n` Actions in a transfer, the prover MUST still sign the `SIGHASH` of the transaction using the binding signature key :math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}` @@ -150,7 +150,7 @@ One of the key functionalities in a UTXO-based protocol is the fact that input n This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions *cannot* be of *any* Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. -In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom assets and we enforce that *every* input note to an ZSA Action must be proven to exist in the set of note commitments in the Merkle Tree. We then enforce this real note to be “unspendable” in the sense that its value +In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets. @@ -159,7 +159,7 @@ Note that we do not care about whether the note identified by a Split Input is o Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action: -1. The Split Input note could be another note of the same asset identifier that is being spent by this transaction (but not by this Split Input). +1. The Split Input note could be another note of the same Asset identifier that is being spent by this transaction (but not by this Split Input). 2. The Split Input note could be a different unspent note of the same :math:`\mathsf{AssetId}` (note that the note will not actually be spent). 3. The Split Input note could be an already spent note of the same :math:`\mathsf{AssetId}` (note that by zeroing the value in the circuit, we prevent double spending). @@ -168,38 +168,38 @@ The specific circuit changes are presented below. Circuit Statement ================= -The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the asset identifier system. +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset identifier system. -**Asset Identifier Equality:** the following constraints must be added to ensure that the input and output note are of the -same :math:`\mathsf{AssetId}`: +**Asset Identifier Equality:** the following constraints must be added to ensure that +the input and output note are of the same :math:`\mathsf{AssetId}`: -- The asset identifier, :math:`\mathsf{AssetId}`, for the note is witnessed once, as an auxiliary input. -- The witnessed asset identifier, :math:`\mathsf{AssetId}`, is added to the old note commitment input. -- The witnessed asset identifier, :math:`\mathsf{AssetId}`, is added to the new note commitment input. +- The Asset identifier, :math:`\mathsf{AssetId}`, for the note is witnessed once, as an auxiliary input. +- The witnessed Asset identifier, :math:`\mathsf{AssetId}`, is added to the old note commitment input. +- The witnessed Asset identifier, :math:`\mathsf{AssetId}`, is added to the new note commitment input. -**Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed identifier, as represented in the notes +**Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset identifier, as represented in the notes: - The fixed-base multiplication constraints between the value and the value base point of the value commitment, :math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two. - The witness to the value base point, as defined in the `value base`_ equation is the auxiliary input :math:`\mathsf{AssetId}`. -**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the asset identifier for the output note in a Split Action: +**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the Asset identifier for the output note in a Split Action: - The Value Commitment Integrity should be changed - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}` - Add a boolean ``split`` variable as an auxiliary witness. This variable is to be activated ``split = 1`` if the Action in question is a split and ``split = 0`` if the Action is actually spending an input note: - - If ``split = 1`` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input -- The Merkle Path Validity should check the existance of the note commitment as usual (and not like with dummy notes): + - If ``split = 1`` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input. +- The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes): - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. - The Nullifier Integrity will be changed to prevent the identification of notes - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - - if ``split = 1`` set :math:`\psi' = \mathsf{randomSample}`, otherwise set :math:`\psi' = \psi^{old}` + - if :math:`split = 0` then constrain :math:`\psi' = \psi^{old}`. (Otherwise :math:`\psi'` should be sampled randomly.) **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. -The old note commitment is computed using a “rolling-aggregate” sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. +The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. -- The input note in the old note commitment integrity must either include an asset identifier (ZSA note) or not (ZEC-Orchard note) - - If the asset identifier auxiliary input is set :math:`\mathsf{AssetId}` = :math:`\mathcal{V}^\mathsf{Orchard}` +- The input note in the old note commitment integrity must either include an Asset identifier (ZSA note) or not (ZEC-Orchard note) + - If the Asset identifier auxiliary input is set :math:`\mathsf{AssetId}` = :math:`\mathcal{V}^\mathsf{Orchard}` - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the identifier) - This path also uses the original domain separator for ZEC note commitment - Else, @@ -211,33 +211,33 @@ Backward Compatibility ---------------------- In order to have a "clean" backwards 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: -- The input notes with an asset identifer denote the ZSA custom assets, generating a note commitment that includes the asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the asset identifier, in order to maintain the referencability to the Merkle tree +- The input notes with an Asset identifer denote the ZSA custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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 Burn Mechanism ============== -The burn mechanism may be needed for off-boarding the wrapped assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. +The burn mechanism may be needed for off-boarding the Wrapped Assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. -In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send assets to a non-spendable address, it simply reduces the total number of assets 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. +In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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. -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{AssetId}}` variable for every asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC asset. +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{AssetId}}` variable for every Asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{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 :math:`(\mathsf{valueBalance_{AssetId}, 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. +For every custom Asset that is burnt, we add to the `assetBurn` vector the tuple :math:`(\mathsf{valueBalance_{AssetId}, 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. :math:`\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]` -The value balances for each asset identifier in `assetBurn` represents the amount of that asset identifier that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). +The value balances for each Asset identifier in `assetBurn` represents the amount of that Asset identifier that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). -Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all assets, as committed using their respective :math:`\mathsf{AssetId}` as the value base point of the Pedersen Commitment. This is done as follows +Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective :math:`\mathsf{AssetId}` as the value base point of the Pedersen Commitment. This is done as follows :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` -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, the number of assets, nor their identifiers will be revealed, except in the case that an asset is burnt. +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, the number of Assets, nor their identifiers will be revealed, except in the case that an Asset is burnt. -**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, the unshielding is not not be possible for custom assets. +**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. ZSA Transaction Structure ========================= @@ -246,9 +246,9 @@ Similar to version 5 transaction format, with the following modifications to the +-----------------+-------------+-----------------------------------+-------------------------+ | Bytes | Name | Data Type | Description | +=================+=============+===================================+=========================+ -| varies | nAssetBurn | compactSize | number of assets burnt | +| varies | nAssetBurn | compactSize | number of Assets burnt | +-----------------+-------------+-----------------------------------+-------------------------+ -| 40*nAssetBurn | vAssetBurn | bytes[40][nAssetBurn] | 32 bytes asset type_t, | +| 40*nAssetBurn | vAssetBurn | bytes[40][nAssetBurn] | 32 bytes Asset type_t, | | | | | 8 bytes of valueBalance | +-----------------+-------------+-----------------------------------+-------------------------+ @@ -266,8 +266,8 @@ Security and Privacy -------------------- - Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. -- When including new assets we would like to maintain the amount and identifiers of assets private, which is achieved with the design -- We prevent the "roadblock" attack on the asset identifer by ensuring the output notes receive an asset identifier that exists on the global state +- When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design +- We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state Deplopyment ----------- From f40ce2a4079963d7e7e4ef634be2861d2de03fec Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 25 Dec 2022 11:36:47 +0530 Subject: [PATCH 032/101] resolving comments from PR#628 --- zip-0227.html | 102 +++++++++++++++++++++++++------------------------- zip-0227.rst | 96 +++++++++++++++++++++++------------------------ 2 files changed, 99 insertions(+), 99 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 0ef84b541..23bdaaf02 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -27,58 +27,58 @@

    The terms "Zcash Shielded Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 4.

    We define the following additional terms:

      -
    • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier ( +
    • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. Different custom Assets are defined and differentiated by their identifier ( \(\mathsf{AssetId}\) ).
      • -
    • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier.
      • +
    • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset identifier.
    • Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.

    Abstract

    -

    ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 5. The transfer and burn of such assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

    +

    ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 5. The transfer and burn of such Assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

    Motivation

    -

    The Orchard protocol deployed in NU5 does not 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.

    +

    The Orchard protocol deployed in NU5 does not 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.

    Use Cases

    -

    The design presented in this ZIP enables issuance of shielded assets in various modes:

    +

    The design presented in this ZIP enables issuance of shielded Assets in various modes:

      -
    • The issuer knows in advance the receivers of the issued asset.
      • -
    • The asset can be of non-fungible type, where each asset type can be made part of a single “series”.
      • -
    • The supply of the asset can be limited in advance or not.
      • -
    • The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains).
      • +
    • The issuer knows in advance the receivers of the issued Asset.
      • +
    • The Asset can be of non-fungible type, where each Asset type can be made part of a single “series”.
      • +
    • The supply of the Asset can be limited in advance or not.
      • +
    • The Asset can be a wrapped version of an Asset issued by another chain (as long as there is a bridge that supports transfer of that Asset between chains).

    See the Concrete Applications section for more details.

    Requirements

      -
    • Any user of the Zcash block chain can issue custom assets on chain.
      • -
    • The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain.
      • -
    • Issuing or changing the attributes of a specific asset should require cryptographic authorization.
      • -
    • The asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same asset identifier.
      • +
    • Any user of the Zcash block chain can issue custom Assets on chain.
      • +
    • The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain.
      • +
    • Issuing or changing the attributes of a specific Asset should require cryptographic authorization.
      • +
    • The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset identifier.

    Specification

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    Overview

    -

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the block chain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys.

    +

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset types, yet only a single issuer (a set of keys) can issue that specific Asset type, as the Asset identifiers are tied to the issuer keys.

    The protocol was designed with three main properties in mind:

    • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
      • -
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets.
      • -
    • Every issuance action contains the finalize boolean that defines whether that specific custom asset can have further tokens issued or not.
      • +
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom Assets.
      • +
    • Every issuance action contains the finalize boolean that defines whether that specific custom Asset can have further tokens issued or not.
    -

    The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    +

    The issuance mechanism is broad enough for issuers to either create native Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    Issuance Keys

    There are two keys relevant to the Issuer:

    1. The issuance authorizing key, denoted as \(\mathsf{isk}\) - , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
      2. + , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
    2. The issuance validating key, denoted as \(\mathsf{ik}\) - , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all block chain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key.
      3. + , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. Throughout we also call this key the issuer verification key.

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

      @@ -93,15 +93,15 @@ , as a public verification key:
    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    -

    For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, +

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, \(\mathsf{asset\_desc}\) - , which is a global byte string (valid across all -future- Zcash shielded protocols). From this asset description, the specific asset identifier, + , which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, \(\mathsf{AssetId}\) , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve).

    -

    The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, +

    The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, \(\mathsf{AssetId}\) as follows:

    @@ -111,10 +111,10 @@

    • \(\mathsf{asset\_desc}\) - is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance
      • + is the Asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance.
    • \(\mathsf{ik}\) - is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above
      • + is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above.

    Global Issuance State

    @@ -126,17 +126,17 @@

    Issuance Action Description

    -

    An issuance action, IssueAction, is the instance of issuing a specific custom asset, and contains the following fields:

    +

    An issuance action, IssueAction, is the instance of issuing a specific custom Asset, and contains the following fields:

    • \(\mathsf{asset\_desc}\) - : the asset description, a UTF-8 encoded string of up to 512 bytes
      • -
    • notes: an array containing the unencrypted output notes of the recipients of the asset, of type Note
      • -
    • finalize: a boolean that defines whether the issuance of that specific custom asset is finalized or not
      • + : the Asset description, a UTF-8 encoded string of up to 512 bytes +
    • notes: an array containing the unencrypted output notes of the recipients of the Asset, of type Note
      • +
    • finalize: a boolean that defines whether the issuance of that specific custom Asset is finalized or not
    -

    Once finalize is set to 1, it cannot be unset. For assets whose finalize = 1, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose finalize = 0, new issuance actions can be issued in future transactions. These must use the same asset description, +

    Once finalize is set to 1, it cannot be unset. For Assets whose finalize = 1, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets whose finalize = 0, new issuance actions can be issued in future transactions. These must use the same Asset description, \(\mathsf{asset\_desc}\) - , and can either maintain finalize = 0 or change it to finalize = 1, denoting the last transaction containing issuance of such custom asset.

    + , and can either maintain finalize = 0 or change it to finalize = 1, denoting the last transaction containing issuance of such custom Asset.

    @@ -171,7 +171,7 @@ - +
    1 bit finalize booleanThe boolean that determines the finality of the issuance of that assetThe boolean that determines the finality of the issuance of that Asset
    @@ -240,9 +240,9 @@
  • compute \(\mathsf{AssetId}\) as - \(GroupHash^{\mathbb{P}}(ik || asset_desc)\) + \(GroupHash^{\mathbb{P}}(ik || asset\_desc)\)
    • -
  • set the finalize boolean as desired (if more more issuance actions are to be created for this asset identifier, set finalize = 0, otherwise set finalize = 1)
    • +
  • set the finalize boolean as desired (if more more issuance actions are to be created for this Asset identifier, set finalize = 0, otherwise set finalize = 1)
  • For each recipient i:
    • generate a ZSA output note as @@ -265,25 +265,25 @@

      NOTE that the commitment is not included in the IssuanceAction itself. As explained below, it is later computed by the validators and added to the NoteCommitmentTree.

    • Concrete Applications

    -

    Bridging Assets Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    +

    Bridging Assets Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    • First, the issuance and burn mechanism can be used in conjunction to determine the

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
        -
      • by setting finalize = 1 from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • +
      • by setting finalize = 1 from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      • -
    • Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by +
    • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by
      • issuing a last set of tokens of that specific \(\mathsf{AssetId}\) , while at the same time setting finalize = 1, or by
      • issuing a transaction with a single note in the issuance action pertaining to that \(\mathsf{AssetId}\) - , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations).
        • + , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each @@ -333,11 +333,11 @@
    • The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets.
    • The \(\mathsf{asset\_desc}\) - is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: + is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are:
      • links for storage such as for NFTs
        • -
      • other metadata for native assets
        • -
      • bridging information for wrapped assets (chain of origin, issuer name, etc)
        • +
      • other metadata for native Assets
        • +
      • bridging information for wrapped Assets (chain of origin, issuer name, etc)
      • information to be committed by the issuer, though not enforceable by the protocol
      • @@ -384,10 +384,10 @@
    T.1b: assetDescription
    -

    UTF-8 encoding of the asset description string.

    +

    UTF-8 encoding of the Asset description string.

    T.1c: isFinalized
    -

    1-byte representation of a boolean flag that is set to 'true' if the asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    +

    1-byte representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    T.2 issuerVerificationKey

    @@ -397,24 +397,24 @@

    Security and Privacy Considerations

    Issuer Key or AssetId Compromise

    -

    The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended:

    +

    The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific Asset (see Future Work). In case of compromise, the following actions are recommended:

      -
    • If an asset ID is compromised (and not the issuer verification key), the finalize boolean for that asset should be set to 0 and a new +
    • If an Asset identifier is compromised (and not the issuer verification key), the finalize boolean for that Asset should be set to 0 and a new \(\mathsf{AssetId}\) generated instead.
      • -
    • If an issuer verification key is compromised, the finalize boolean for all the assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new +
    • If an issuer verification key is compromised, the finalize boolean for all the Assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new Assets, each with a new \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    -

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping issuanceSupplyInfoMap from +

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of Assets as a mutable mapping issuanceSupplyInfoMap from \(\mathsf{AssetId}\) to \(\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}\) - in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets.

    + in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    @@ -422,7 +422,7 @@

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying \(\mathsf{ik}\) - of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether.

    + of a given Asset, in case the original one was compromised, without having to change the Asset identifier altogether.

    Test Vectors

    diff --git a/zip-0227.rst b/zip-0227.rst index ba78e7419..81e885e6f 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -27,40 +27,40 @@ The terms "Zcash Shielded Asset" and "Wrapped Asset" in this document are to be We define the following additional terms: -- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) asset for the Zcash mainnet. Different custom assets are defined and differentiated by their identifier (:math:`\mathsf{AssetId}`). -- Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single asset identifier. +- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. Different custom Assets are defined and differentiated by their identifier (:math:`\mathsf{AssetId}`). +- Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset identifier. - Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction. Abstract ======== -ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom assets on the Zcash chain. The creation of such assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such assets is defined in ZIP 226 [#zip-0226]_. This ZIP must only be implemented in conjuction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA. +ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 [#zip-0227]_. The transfer and burn of such Assets is defined in ZIP 226 [#zip-0226]_. This ZIP must only be implemented in conjuction with ZIP 226 [#zip-0226]_, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA. Motivation ========== -The Orchard protocol deployed in NU5 does not 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 +The Orchard protocol deployed in NU5 does not 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. Use Cases ========= -The design presented in this ZIP enables issuance of shielded assets in various modes: +The design presented in this ZIP enables issuance of shielded Assets in various modes: -- The issuer knows in advance the receivers of the issued asset. -- The asset can be of non-fungible type, where each asset type can be made part of a single “series”. -- The supply of the asset can be limited in advance or not. -- The asset can be a wrapped version of an asset issued by another chain (as long as there is a bridge that supports transfer of that asset between chains). +- The issuer knows in advance the receivers of the issued Asset. +- The Asset can be of non-fungible type, where each Asset type can be made part of a single “series”. +- The supply of the Asset can be limited in advance or not. +- The Asset can be a wrapped version of an Asset issued by another chain (as long as there is a bridge that supports transfer of that Asset between chains). See the `Concrete Applications`_ section for more details. Requirements ============ -- Any user of the Zcash block chain can issue custom assets on chain. -- The issuance mechanism should enable tracking publicly the supply of the assets on the Zcash block chain. -- Issuing or changing the attributes of a specific asset should require cryptographic authorization. -- The asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same asset identifier. +- Any user of the Zcash block chain can issue custom Assets on chain. +- The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain. +- Issuing or changing the attributes of a specific Asset should require cryptographic authorization. +- The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset identifier. Specification @@ -71,24 +71,24 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of assets. Any user of the block chain can issue new asset types, yet only a single issuer (a set of keys) can issue that specific asset type, as the asset identifiers are tied to the issuer keys. +This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset types, yet only a single issuer (a set of keys) can issue that specific Asset type, as the Asset identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: - At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. -- In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom assets. -- Every issuance action contains the ``finalize`` boolean that defines whether that specific custom asset can have further tokens issued or not. +- In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom Assets. +- Every issuance action contains the ``finalize`` boolean that defines whether that specific custom Asset can have further tokens issued or not. -The issuance mechanism is broad enough for issuers to either create native assets on Zcash (i.e. assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +The issuance mechanism is broad enough for issuers to either create native Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. Issuance Keys ------------- There are two keys relevant to the Issuer: -1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. +1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. -2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific asset type, and is used by all block chain users (specifically the asset owners and consensus validators) to associate the asset in question with the issuer. Throughout we also call this key the issuer verification key. +2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. Throughout we also call this key the issuer verification key. The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. @@ -100,21 +100,21 @@ The two keys are derived in an analogous manner to the spend authorizing key and .. math:: \mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)} -This allows the issuer to use the same wallet it usually uses to transfer assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_, and can further be in It provides further anonymity and the ability to delegate issuance of an asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. +This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_, and can further be in It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. Asset Identifier ---------------- -For every new asset, there must be a new and unique identifier of the asset. Every asset is defined by the asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this asset description, the specific asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve). +For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve). -The main requirement for the asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the asset identifier, :math:`\mathsf{AssetId}` as follows: +The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, :math:`\mathsf{AssetId}` as follows: :math:`\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset\_desc)}` where -- :math:`\mathsf{asset\_desc}` is the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance -- :math:`\mathsf{ik}` is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above +- :math:`\mathsf{asset\_desc}` is the Asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. +- :math:`\mathsf{ik}` is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above. Global Issuance State --------------------- @@ -126,13 +126,13 @@ Issuance requires the following additions to the global state: Issuance Action Description --------------------------- -An issuance action, `IssueAction`, is the instance of issuing a specific custom asset, and contains the following fields: +An issuance action, `IssueAction`, is the instance of issuing a specific custom Asset, and contains the following fields: -- :math:`\mathsf{asset\_desc}`: the asset description, a UTF-8 encoded string of up to 512 bytes -- `notes`: an array containing the unencrypted output notes of the recipients of the asset, of type `Note` -- ``finalize``: a boolean that defines whether the issuance of that specific custom asset is finalized or not +- :math:`\mathsf{asset\_desc}`: the Asset description, a UTF-8 encoded string of up to 512 bytes +- `notes`: an array containing the unencrypted output notes of the recipients of the Asset, of type `Note` +- ``finalize``: a boolean that defines whether the issuance of that specific custom Asset is finalized or not -Once ``finalize`` is set to 1, it cannot be unset. For assets whose ``finalize = 1``, no further tokens can be issued, so as seen below, the validators will reject the transaction. For assets whose ``finalize = 0``, new issuance actions can be issued in future transactions. These must use the same asset description, :math:`\mathsf{asset\_desc}`, and can either maintain ``finalize = 0`` or change it to ``finalize = 1``, denoting the last transaction containing issuance of such custom asset. +Once ``finalize`` is set to 1, it cannot be unset. For Assets whose ``finalize = 1``, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets whose ``finalize = 0``, new issuance actions can be issued in future transactions. These must use the same Asset description, :math:`\mathsf{asset\_desc}`, and can either maintain ``finalize = 0`` or change it to ``finalize = 1``, denoting the last transaction containing issuance of such custom Asset. ================= =============================== ========================== ======================================================================== Size Name Data Type Description @@ -140,7 +140,7 @@ Size Name Data Type Des Varies :math:`\mathsf{asset\_desc}` byte Uni-code encoded string of varied size, up to 512 bytes Varies nNotes compactSize The number of notes in the issuance action noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action -1 bit ``finalize`` boolean The boolean that determines the finality of the issuance of that asset +1 bit ``finalize`` boolean The boolean that determines the finality of the issuance of that Asset ================= =============================== ========================== ======================================================================== We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the `NoteCommitmentTree` as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers. @@ -172,8 +172,8 @@ The issuer program performs the following operations For all actions `IssueAction`: - encode :math:`\mathsf{asset\_desc}` as 512 byte-string -- compute :math:`\mathsf{AssetId}` as :math:`GroupHash^{\mathbb{P}}(ik || asset_desc)` -- set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this asset identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) +- compute :math:`\mathsf{AssetId}` as :math:`GroupHash^{\mathbb{P}}(ik || asset\_desc)` +- set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) - For each recipient ``i``: - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` @@ -193,20 +193,20 @@ Concrete Applications --------------------- **Bridging Assets** -Issuers can wrap assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): +Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - First, the issuance and burn mechanism can be used in conjunction to determine the **Asset Features** -- By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any asset associated to their issuer keys. For example, +- By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any Asset associated to their issuer keys. For example, - - by setting ``finalize = 1`` from the first issuance action for that asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + - by setting ``finalize = 1`` from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. -- Issuers can also stop the existing supply production of any asset associated to their issuer keys. This could be done by +- Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, while at the same time setting ``finalize = 1``, or by - - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the asset issuance (see Security and Privacy Considerations). + - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations). - Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. @@ -235,11 +235,11 @@ Rationale The following is a list of rationale for different decisions made in the proposal: - The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets. -- The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the assets. Some are: +- The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: - links for storage such as for NFTs - - other metadata for native assets - - bridging information for wrapped assets (chain of origin, issuer name, etc) + - other metadata for native Assets + - bridging information for wrapped Assets (chain of origin, issuer name, etc) - information to be committed by the issuer, though not enforceable by the protocol TxId Digest @@ -305,11 +305,11 @@ The ZIP 212 32-byte seed randomness for a note. T.1b: assetDescription '''''''''''''''''''''' -UTF-8 encoding of the asset description string. +UTF-8 encoding of the Asset description string. T.1c: isFinalized ''''''''''''''''' -1-byte representation of a boolean flag that is set to 'true' if the asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. +1-byte representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. T.2 issuerVerificationKey @@ -322,13 +322,13 @@ Security and Privacy Considerations **Issuer Key or AssetId Compromise** -The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific asset (see Future Work). In case of compromise, the following actions are recommended: +The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific Asset (see Future Work). In case of compromise, the following actions are recommended: -- If an asset ID is compromised (and not the issuer verification key), the ``finalize`` boolean for that asset should be set to `0` and a new :math:`\mathsf{AssetId}` generated instead. -- If an issuer verification key is compromised, the ``finalize`` boolean for all the assets issued with that key should be set to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new assets, each with a new :math:`\mathsf{AssetId}`. +- If an Asset identifier is compromised (and not the issuer verification key), the ``finalize`` boolean for that Asset should be set to `0` and a new :math:`\mathsf{AssetId}` generated instead. +- If an issuer verification key is compromised, the ``finalize`` boolean for all the Assets issued with that key should be set to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new Assets, each with a new :math:`\mathsf{AssetId}`. **Bridging Assets** -For bridging purposes, the secure method of off-boarding assets is to burn an asset with the burning mechanism in ZIP 226 [#zip-0226]_. Users should be aware of issuers that demand the assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific wrapped asset. +For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 [#zip-0226]_. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset. Other Considerations ==================== @@ -336,7 +336,7 @@ Other Considerations Implementing Zcash Nodes ------------------------ -Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different asset types. This is useful for wallets and other applications that need to keep track of the total supply of assets. +Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets. Fee Structures -------------- @@ -346,7 +346,7 @@ The fee mechanism described in this ZIP will follow the mechanism described in Z Future Work ----------- -In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying :math:`\mathsf{ik}` of a given asset, in case the original one was compromised, without having to chance the asset identifier altogether. +In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying :math:`\mathsf{ik}` of a given Asset, in case the original one was compromised, without having to change the Asset identifier altogether. Test Vectors ============ From 8ed51c2444418e5eb675d94e7290bd9476fef138 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 27 Dec 2022 00:37:31 +0530 Subject: [PATCH 033/101] streamlining zip definitions, updating motivation for ZIP 227 --- zip-0226.html | 22 ++++++++++++---------- zip-0226.rst | 6 +++--- zip-0227.html | 21 ++++++++------------- zip-0227.rst | 8 +++----- 4 files changed, 26 insertions(+), 31 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 49b626eef..830922e77 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -31,11 +31,11 @@ parameter.
    • ZEC is the default (and currently the only defined) Asset for the Zcash mainnet.
      • +
    • We use the term "custom Asset" to refer to any Asset other than ZEC.
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
  • Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain.
    • -
  • Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain.
  • Split Input: an Action input identifying a Zcash Shielded Asset note, used to ensure that the output note of that Action is of a validly issued \(\mathsf{AssetId}\) when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input.
    • @@ -149,8 +149,10 @@ \(\mathsf{AssetId}\) , and

    - \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || } \mathsf{ik} \texttt{ || } \mathsf{asset\_desc} \texttt{)}\) -

    + \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}\) + , where the Asset identifier + \(\mathsf{AssetId}\) + is computed as defined in ZIP 227 5.

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\)

    @@ -159,7 +161,7 @@ .

    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 7. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, +

    In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol 7. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    For a total of @@ -172,13 +174,13 @@

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 7.

    +

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 7.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -197,7 +199,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the Asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the Asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -327,7 +329,7 @@

    Backward Compatibility

    -

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the ZSA custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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

    +

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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

    Burn Mechanism

    @@ -355,7 +357,7 @@

    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.

    ZSA Transaction Structure

    -

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    +

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    @@ -386,7 +388,7 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    Security and Privacy

      diff --git a/zip-0226.rst b/zip-0226.rst index 006870fc6..8ac23d89f 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -29,10 +29,10 @@ We define the following additional terms: - Asset: A type of note that can be transferred on the Zcash block chain, identified by the :math:`\mathsf{AssetId}` parameter. - ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. + - We use the term "custom Asset" to refer to any Asset other than ZEC. - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. -- Native Asset: a Zcash Shielded Asset created uniquely within the Zcash block chain. - Split Input: an Action input identifying a Zcash Shielded Asset note, used to ensure that the output note of that Action is of a validly issued :math:`\mathsf{AssetId}` when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input. - Split Action: a Zcash Shielded Asset Action that contains a Split Input. @@ -120,7 +120,7 @@ where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{A .. _`value base`: -:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "a" || } \mathsf{ik} \texttt{ || } \mathsf{asset\_desc} \texttt{)}` +:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}`, where the Asset identifier :math:`\mathsf{AssetId}` is computed as defined in ZIP 227 [#zip-0227]_. :math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` @@ -211,7 +211,7 @@ Backward Compatibility ---------------------- In order to have a "clean" backwards 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: -- The input notes with an Asset identifer denote the ZSA custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree +- The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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 diff --git a/zip-0227.html b/zip-0227.html index 23bdaaf02..18712cc6d 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -24,12 +24,9 @@

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

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

      The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.

      -

      The terms "Zcash Shielded Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 4.

      +

      The terms "Asset", "custom Asset", and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 4.

      We define the following additional terms:

        -
      • Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. Different custom Assets are defined and differentiated by their identifier ( - \(\mathsf{AssetId}\) - ).
      • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset identifier.
      • Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.
      @@ -38,7 +35,7 @@

      ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 5. The transfer and burn of such Assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

    Motivation

    -

    The Orchard protocol deployed in NU5 does not 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 is a supporting ZIP for ZIP 226 4, which lays out its motivations, but requires an issuance mechanism to be defined (which is substantial enough to stand on its own) in order to function.

    Use Cases

    The design presented in this ZIP enables issuance of shielded Assets in various modes:

    @@ -80,7 +77,7 @@ \(\mathsf{ik}\) , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. Throughout we also call this key the issuer verification key. -

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    +

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    • The issuance authorizing key is derived directly from the spending key, \(\mathsf{sk}\) @@ -93,7 +90,7 @@ , as a public verification key:
    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, @@ -104,9 +101,7 @@

    The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, \(\mathsf{AssetId}\) as follows:

    -

    - \(\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset\_desc)}\) -

    +
    \(\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)}\)

    where

    • @@ -271,7 +266,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -406,7 +401,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -417,7 +412,7 @@ in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying diff --git a/zip-0227.rst b/zip-0227.rst index 81e885e6f..c21bb1af6 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -23,11 +23,10 @@ The term "network upgrade" in this document is to be interpreted as described in The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. -The terms "Zcash Shielded Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 [#zip-0226]_. +The terms "Asset", "custom Asset", and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 [#zip-0226]_. We define the following additional terms: -- Custom Asset: A type of note that can be transferred on the Zcash block chain. ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. Different custom Assets are defined and differentiated by their identifier (:math:`\mathsf{AssetId}`). - Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset identifier. - Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction. @@ -39,8 +38,7 @@ ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_ propose in conjunction the Zcash S Motivation ========== -The Orchard protocol deployed in NU5 does not 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 is a supporting ZIP for ZIP 226 [#zip-0226]_, which lays out its motivations, but requires an issuance mechanism to be defined (which is substantial enough to stand on its own) in order to function. Use Cases ========= @@ -109,7 +107,7 @@ For every new Asset, there must be a new and unique identifier of the Asset. Eve The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, :math:`\mathsf{AssetId}` as follows: -:math:`\mathsf{AssetId := GroupHash^{\mathbb{P}}}\mathsf{(ik || asset\_desc)}` +.. math:: \mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)} where From 5c6aad43c9b8d0867e1430b2847f415becb299bf Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 27 Dec 2022 14:21:16 +0530 Subject: [PATCH 034/101] edits to reword native assets, and make Wrapped Asset usage consistent throughout the ZIPs --- zip-0226.html | 4 ++-- zip-0226.rst | 4 ++-- zip-0227.html | 10 +++++----- zip-0227.rst | 10 +++++----- 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 830922e77..3abc88546 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -76,7 +76,7 @@ of the output note of that split Action is the output of a PRF.

    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 \(\mathsf{valueBalance}\) - of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Native Assets.

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

    @@ -333,7 +333,7 @@

    Burn Mechanism

    -

    The burn mechanism may be needed for off-boarding the Wrapped Assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

    +

    The burn mechanism may be needed for off-boarding the Wrapped Assets from the chain, or enabling advanced tokenomics on Assets. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability.

    In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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.

    First, contrary to the strict transfer transaction, we allow the sender to include a \(\mathsf{valueBalance_{AssetId}}\) diff --git a/zip-0226.rst b/zip-0226.rst index 8ac23d89f..34900eb79 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -60,7 +60,7 @@ Because in a single transaction all value commitments are balanced, there must b 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 :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a PRF. -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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Native Assets. +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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets. Specification ============= @@ -218,7 +218,7 @@ In order to have a "clean" backwards compatibility with the ZEC notes, we have d Burn Mechanism ============== -The burn mechanism may be needed for off-boarding the Wrapped Assets from the chain, or enabling advanced tokenomics on native tokens. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. +The burn mechanism may be needed for off-boarding the Wrapped Assets from the chain, or enabling advanced tokenomics on Assets. It is part of the Issuance/Burn protocol, but given that it can be seen as an extension of the Transfer protocol, we add it here for readability. In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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. diff --git a/zip-0227.html b/zip-0227.html index 18712cc6d..8899bb4d8 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -65,7 +65,7 @@

  • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom Assets.
  • Every issuance action contains the finalize boolean that defines whether that specific custom Asset can have further tokens issued or not.
    • -

    The issuance mechanism is broad enough for issuers to either create native Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    +

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    Issuance Keys

    There are two keys relevant to the Issuer:

    @@ -330,10 +330,10 @@ \(\mathsf{asset\_desc}\) is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are:
      -
    • links for storage such as for NFTs
      • -
    • other metadata for native Assets
      • -
    • bridging information for wrapped Assets (chain of origin, issuer name, etc)
      • -
    • information to be committed by the issuer, though not enforceable by the protocol
      • +
    • links for storage such as for NFTs.
      • +
    • metadata for Assets, encoded in any format.
      • +
    • bridging information for Wrapped Assets (chain of origin, issuer name, etc)
      • +
    • information to be committed by the issuer, though not enforceable by the protocol.
    diff --git a/zip-0227.rst b/zip-0227.rst index c21bb1af6..b693db654 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -77,7 +77,7 @@ The protocol was designed with three main properties in mind: - In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom Assets. - Every issuance action contains the ``finalize`` boolean that defines whether that specific custom Asset can have further tokens issued or not. -The issuance mechanism is broad enough for issuers to either create native Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. Issuance Keys ------------- @@ -235,10 +235,10 @@ The following is a list of rationale for different decisions made in the proposa - The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets. - The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: - - links for storage such as for NFTs - - other metadata for native Assets - - bridging information for wrapped Assets (chain of origin, issuer name, etc) - - information to be committed by the issuer, though not enforceable by the protocol + - links for storage such as for NFTs. + - metadata for Assets, encoded in any format. + - bridging information for Wrapped Assets (chain of origin, issuer name, etc) + - information to be committed by the issuer, though not enforceable by the protocol. TxId Digest =========== From 1e3c89fc1cf7f579e36b6378281b984e783a4b9c Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 27 Dec 2022 15:03:46 +0530 Subject: [PATCH 035/101] adding burn consensus rule (disallowing burning 0 value of assets) --- zip-0226.html | 6 +++++- zip-0226.rst | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/zip-0226.html b/zip-0226.html index 3abc88546..b8c73754f 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -339,7 +339,11 @@ \(\mathsf{valueBalance_{AssetId}}\) variable for every Asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular \(\mathsf{valueBalance^Orchard}\) - that is the default transparent value for the ZEC Asset.

    + that is the default transparent value for the ZEC Asset. We require that for every + \(\mathsf{valueBalance_{AssetId}}\) + provided as above by the sender, + \(\mathsf{valueBalance_{AssetId}} \neq 0\) + . This is enforced via a consensus rule.

    For every custom Asset that is burnt, we add to the assetBurn vector the tuple \((\mathsf{valueBalance_{AssetId}, 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.

    diff --git a/zip-0226.rst b/zip-0226.rst index 34900eb79..aa1173a14 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -223,6 +223,7 @@ The burn mechanism may be needed for off-boarding the Wrapped Assets from the ch In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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. First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{AssetId}}` variable for every Asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC Asset. +We require that for every :math:`\mathsf{valueBalance_{AssetId}}` provided as above by the sender, :math:`\mathsf{valueBalance_{AssetId}} \neq 0`. This is enforced via a consensus rule. For every custom Asset that is burnt, we add to the `assetBurn` vector the tuple :math:`(\mathsf{valueBalance_{AssetId}, 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. From 943415170f656d7ddd0d829d08175c78c4c0907e Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 27 Dec 2022 17:56:26 +0530 Subject: [PATCH 036/101] adding the AssetIdHash abstraction to the issuance ZIP --- zip-0227.html | 25 ++++++++++++++++++++----- zip-0227.rst | 13 ++++++++++--- 2 files changed, 30 insertions(+), 8 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 8899bb4d8..644d889f8 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -97,11 +97,13 @@ \(\mathsf{asset\_desc}\) , which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, \(\mathsf{AssetId}\) - , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve).

    + , is derived using an Asset identifier hash, + \(\mathsf{AssetIdHash}\) + that is defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve), and used within the output notes.

    The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, \(\mathsf{AssetId}\) as follows:

    -
    \(\mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)}\)
    +
    \(\mathsf{AssetId} = \mathsf{AssetIdHash(ik, asset\_desc)}\)

    where

    • @@ -111,6 +113,11 @@ \(\mathsf{ik}\) is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above.
    +

    In the case of the Orchard protocol, we define

    +
    \(\mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)}\)
    +

    where + \(\mathsf{GroupHash^{\mathbb{P}}}\) + is the Group Hash into the group of points on the Pallas curve defined in the protocol spec 9

    Global Issuance State

    Issuance requires the following additions to the global state:

    @@ -266,7 +273,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -401,7 +408,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -412,7 +419,7 @@ in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -499,6 +506,14 @@

    + + + + + + + +
    9Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta
    diff --git a/zip-0227.rst b/zip-0227.rst index b693db654..1dbdc50b3 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -103,17 +103,23 @@ This allows the issuer to use the same wallet it usually uses to transfer Assets Asset Identifier ---------------- -For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve). +For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived using an Asset identifier hash, :math:`\mathsf{AssetIdHash}` that is defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve), and used within the output notes. The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, :math:`\mathsf{AssetId}` as follows: -.. math:: \mathsf{AssetId}= \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)} +.. math:: \mathsf{AssetId} = \mathsf{AssetIdHash(ik, asset\_desc)} where - :math:`\mathsf{asset\_desc}` is the Asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. - :math:`\mathsf{ik}` is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above. +In the case of the Orchard protocol, we define + +.. math:: \mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)} + +where :math:`\mathsf{GroupHash^{\mathbb{P}}}` is the Group Hash into the group of points on the Pallas curve defined in the protocol spec [#protocol-concretegrouphashpallasandvesta]_ + Global Issuance State --------------------- @@ -372,4 +378,5 @@ References .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ -.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ \ No newline at end of file +.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ +.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ \ No newline at end of file From 44a1ef309eb2caa91018dc8965a7572e91836b05 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 3 Jan 2023 08:17:30 +0530 Subject: [PATCH 037/101] adding suggestions based on comments --- zip-0226.html | 2 +- zip-0226.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index b8c73754f..f22643e48 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -46,7 +46,7 @@

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 5. The transfer and burn of such Assets is defined in ZIP 226 4.

    Motivation

    -

    The current Orchard protocol does not 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.

    +

    The Orchard protocol deployed in NU5 does not 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.

    Overview

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call diff --git a/zip-0226.rst b/zip-0226.rst index aa1173a14..2be23034d 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -46,7 +46,7 @@ in ZIP 227 [#zip-0227]_. The transfer and burn of such Assets is defined in ZIP Motivation ========== -The current Orchard protocol does not 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. +The Orchard protocol deployed in NU5 does not 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. Overview ======== From 3bfd9b479bae697e4e70f8f7e7069f147fbc94b1 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Tue, 3 Jan 2023 10:16:55 +0530 Subject: [PATCH 038/101] Applying suggestions from ZIP review Co-authored-by: Deirdre Connolly --- zip-0227.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/zip-0227.rst b/zip-0227.rst index 1dbdc50b3..8c99f3a4b 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -219,7 +219,7 @@ Consensus Rule Changes For the IssueBundle: -- Verify the RedPallas-based issuance authorization signature on `SIGHASH`, `authorization` is valid, based on `authorization.VerifySig(ik, SIGHASH)` +- Verify the RedPallas-based issuance authorization signature on `SIGHASH`, `authorization`, is verified by invoking `authorization.VerifySig(ik, SIGHASH)` For each `IssueAction` in `IssueBundle`: @@ -234,6 +234,7 @@ If all of the above checks pass, do the following: - add `cm` to the Merkle tree of note commitments, `NoteCommitmentTree` - If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set in the global state + Rationale ========= The following is a list of rationale for different decisions made in the proposal: @@ -248,7 +249,7 @@ The following is a list of rationale for different decisions made in the proposa TxId Digest =========== -A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:: +A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below: issuance_txid_digest ├── issueActions From 44f4c3233be1ef197847358a4803cd60566a9661 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 3 Jan 2023 10:18:27 +0530 Subject: [PATCH 039/101] making html based on suggested changes in the previous commit --- zip-0227.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 644d889f8..fe7675bb7 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -296,7 +296,7 @@

    Consensus Rule Changes

    For the IssueBundle:

      -
    • Verify the RedPallas-based issuance authorization signature on SIGHASH, authorization is valid, based on authorization.VerifySig(ik, SIGHASH)
      • +
    • Verify the RedPallas-based issuance authorization signature on SIGHASH, authorization, is verified by invoking authorization.VerifySig(ik, SIGHASH)

    For each IssueAction in IssueBundle:

      @@ -347,9 +347,9 @@

    TxId Digest

    A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

    - 
    issuance_txid_digest
-├── issueActions
-└── issuerVerificationKey
    +
    +

    issuance_txid_digest ├── issueActions └── issuerVerificationKey

    +

    In the specification below, nodes of the tree are presented in depth-first order.

    issuance_txid_digest

    A BLAKE2b-256 hash of the following values

    From 9270a78b95bbc8802142a123b9b2b928f6357e3a Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 3 Jan 2023 23:53:57 +0530 Subject: [PATCH 040/101] edits based on review comments --- zip-0227.html | 18 +++++++++--------- zip-0227.rst | 18 +++++++++--------- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index fe7675bb7..9fccd6854 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -40,7 +40,7 @@

    Use Cases

    The design presented in this ZIP enables issuance of shielded Assets in various modes:

      -
    • The issuer knows in advance the receivers of the issued Asset.
      • +
    • The issuer may or may not know the receivers of the issued Asset in advance.
    • The Asset can be of non-fungible type, where each Asset type can be made part of a single “series”.
    • The supply of the Asset can be limited in advance or not.
    • The Asset can be a wrapped version of an Asset issued by another chain (as long as there is a bridge that supports transfer of that Asset between chains).
      • @@ -155,7 +155,7 @@ \(\mathsf{asset\_desc}\) byte - Uni-code encoded string of varied size, up to 512 bytes + UTF-8 encoded string of varied size, up to 512 bytes Varies @@ -282,7 +282,7 @@
      • issuing a last set of tokens of that specific \(\mathsf{AssetId}\) - , while at the same time setting finalize = 1, or by
        • + , during which finalize = 1, or by
      • issuing a transaction with a single note in the issuance action pertaining to that \(\mathsf{AssetId}\) , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
        • @@ -361,7 +361,7 @@

        A byte encoding of Issue Action information for all Issue Actions belonging to the transaction. For each Action, the following elements are included in the hash:

        T.1a: notes                   (field encoding bytes)
 T.1b: assetDescription        (field encoding bytes)
-T.1c: isFinalized             (1 byte)
        +T.1c: isFinalized (1 bit)
        T.1a: notes

        A byte encoding of Note information for all Notes belonging to the Action. For each Note, the following elements are included in the hash:

        T.1a.1: recipient                    (field encoding bytes)
@@ -389,11 +389,11 @@
                         
        UTF-8 encoding of the Asset description string.
        T.1c: isFinalized
        -

        1-byte representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

        +

        1-bit representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    T.2 issuerVerificationKey

    -

    A byte encoding of issuer verification key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components].

    +

    A byte encoding of issuer validating key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components].

    @@ -401,10 +401,10 @@

    Issuer Key or AssetId Compromise

    The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific Asset (see Future Work). In case of compromise, the following actions are recommended:

      -
    • If an Asset identifier is compromised (and not the issuer verification key), the finalize boolean for that Asset should be set to 0 and a new +
    • If an Asset identifier is compromised (and not the issuer validating key), the finalize boolean for that Asset should be set to 0 and a new \(\mathsf{AssetId}\) generated instead.
      • -
    • If an issuer verification key is compromised, the finalize boolean for all the Assets issued with that key should be set to 0 and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new Assets, each with a new +
    • If an issuer validating key is compromised, the finalize boolean for all the Assets issued with that key should be set to 0 and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new \(\mathsf{AssetId}\) .
    @@ -412,7 +412,7 @@

    Other Considerations

    Implementing Zcash Nodes

    -

    Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of Assets as a mutable mapping issuanceSupplyInfoMap from +

    Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping issuanceSupplyInfoMap from \(\mathsf{AssetId}\) to \(\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}\) diff --git a/zip-0227.rst b/zip-0227.rst index 8c99f3a4b..2ee61f6a0 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -45,7 +45,7 @@ Use Cases The design presented in this ZIP enables issuance of shielded Assets in various modes: -- The issuer knows in advance the receivers of the issued Asset. +- The issuer may or may not know the receivers of the issued Asset in advance. - The Asset can be of non-fungible type, where each Asset type can be made part of a single “series”. - The supply of the Asset can be limited in advance or not. - The Asset can be a wrapped version of an Asset issued by another chain (as long as there is a bridge that supports transfer of that Asset between chains). @@ -141,7 +141,7 @@ Once ``finalize`` is set to 1, it cannot be unset. For Assets whose ``finalize = ================= =============================== ========================== ======================================================================== Size Name Data Type Description ================= =============================== ========================== ======================================================================== -Varies :math:`\mathsf{asset\_desc}` byte Uni-code encoded string of varied size, up to 512 bytes +Varies :math:`\mathsf{asset\_desc}` byte UTF-8 encoded string of varied size, up to 512 bytes Varies nNotes compactSize The number of notes in the issuance action noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action 1 bit ``finalize`` boolean The boolean that determines the finality of the issuance of that Asset @@ -209,7 +209,7 @@ Issuers can wrap Assets defined in other chains and issue them at once in a sing - Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by - - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, while at the same time setting ``finalize = 1``, or by + - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, during which ``finalize = 1``, or by - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations). - Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. @@ -274,7 +274,7 @@ A byte encoding of Issue Action information for all Issue Actions belonging to t T.1a: notes (field encoding bytes) T.1b: assetDescription (field encoding bytes) - T.1c: isFinalized (1 byte) + T.1c: isFinalized (1 bit) T.1a: notes @@ -314,12 +314,12 @@ UTF-8 encoding of the Asset description string. T.1c: isFinalized ''''''''''''''''' -1-byte representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. +1-bit representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. T.2 issuerVerificationKey ````````````````````````` -A byte encoding of issuer verification key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components]. +A byte encoding of issuer validating key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components]. Security and Privacy Considerations @@ -329,8 +329,8 @@ Security and Privacy Considerations The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific Asset (see Future Work). In case of compromise, the following actions are recommended: -- If an Asset identifier is compromised (and not the issuer verification key), the ``finalize`` boolean for that Asset should be set to `0` and a new :math:`\mathsf{AssetId}` generated instead. -- If an issuer verification key is compromised, the ``finalize`` boolean for all the Assets issued with that key should be set to `0` and the issuer should change to a new spending key altogether (for the purpose of issuance), and issue new Assets, each with a new :math:`\mathsf{AssetId}`. +- If an Asset identifier is compromised (and not the issuer validating key), the ``finalize`` boolean for that Asset should be set to `0` and a new :math:`\mathsf{AssetId}` generated instead. +- If an issuer validating key is compromised, the ``finalize`` boolean for all the Assets issued with that key should be set to `0` and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new :math:`\mathsf{AssetId}`. **Bridging Assets** For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 [#zip-0226]_. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset. @@ -341,7 +341,7 @@ Other Considerations Implementing Zcash Nodes ------------------------ -Although not enforced in the global state, it is recommended that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets. +Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets. Fee Structures -------------- From b6d2efc41ec19a3329173842c707d3c0e83d0610 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 9 Jan 2023 12:21:32 +0530 Subject: [PATCH 041/101] adding reference links to ZIP 226 --- zip-0226.html | 150 +++++++++++++++++++++++++++----------------------- zip-0226.rst | 65 +++++++++++----------- 2 files changed, 113 insertions(+), 102 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index f22643e48..8a3de2998 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -52,26 +52,26 @@

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call \(\mathsf{AssetId}\) .

    -

    The Asset identifier will be used to enforce the balance of an Action Description 6 is preserved across Assets (see the Orchard Binding Signature 7), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The Asset identifier will be used to enforce the balance of an Action Description 7 is preserved across Assets (see the Orchard Binding Signature 8), 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}-value^{new}}\) , must be balanced only with respect to the same Asset identifier. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred.

    -

    As was initially proposed by Jack Grigg and Daira Hopwood 15, we propose to make this happen by changing the value base point, +

    As was initially proposed by Jack Grigg and Daira Hopwood 17, we propose to make this happen by changing the value base point, \(\mathcal{V}^{\mathsf{Orchard}}\) , in the Homomorphic Pedersen Commitment that generates 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 in the transaction. We propose to make the \(\mathsf{AssetId}\) - identifier an auxiliary input to the proof for each Action, represented already as a point on the Pallas curve. The circuit then should check that the same + identifier an auxiliary input to the proof for each Action statement 15, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetId}\) - is used in the old note commitment, in the new note commitment and as the base point + is used in the old note commitment and the new note commitment 12, and as the base point \(\mathcal{V}^\mathsf{Orchard}\) - in the value commitment. This ensures (1) that the input and output notes are of the same + in the value commitment 13. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetId}\) , and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures.

    -

    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 +

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 14 for custom Assets, as we need to enforce that the \(\mathsf{AssetId}\) of the output note of that split Action is the output of a PRF.

    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 @@ -98,89 +98,83 @@ , from one shielded protocol to another.

    Note Structure & Commitment

    -

    First, we need to adapt the components that define the Assets, i.e.: notes. A ZSA note differs from an Orchard note by including the identifier of the Asset, +

    First, we need to adapt the components that define the Assets, i.e.: notes. A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, \(\mathsf{AssetId}\) - . So a ZSA note looks like:

    -

    + . So a ZSA note is a tuple \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) -

    -

    Where + , where \(\mathsf{AssetId}\) - is the unique random element of the Pallas group 8 that identifies each Asset in the Orchard protocol.

    + is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.

    +

    Let + \(\mathsf{Note^{OrchardZSA}}\) + be the type of a ZSA note, i.e. + \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^{*}\) + .

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 10 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have

    -

    - \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} \cup \{\bot\}\) -

    + in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 12 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 11. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    +
    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)

    The nullifier is generated in the same manner as in the Orchard protocol.

    Value Commitment

    -

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 11 which is instantiated as

    -

    - \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) -

    -

    Where +

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    +
    \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)
    +

    where \(\mathsf{v^{net} = v^{old} - v^{new}}\) - and

    -

    + ; \(\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}\) -

    -

    + ; and \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}\) -

    + .

    In the case of the Orchard protocol, we see that the base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) are fixed for every value commitment, as the values represent the amount of ZEC being transferred.

    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. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes

    -

    - \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\) -

    +
    \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    where \(\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}\) such that - \(\mathsf{v^*_{AssetId}}\) - is the value of the note of identifier + \(\mathsf{v^{old}_{AssetId}}\) + and + \(\mathsf{v^{new}_{AssetId}}\) + are the values of the old and new notes of identifier \(\mathsf{AssetId}\) - , and

    + respectively,

    \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}\) , where the Asset identifier \(\mathsf{AssetId}\) - is computed as defined in ZIP 227 5.

    + is computed as defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) -

    -

    Where - \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}\) .

    +

    We define + \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    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 7. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, +

    In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol 8. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    For a total of \(n\) - Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key

    -

    + Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key \(\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}\) -

    + .

    Then the verifier MUST compute

    -

    - \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) -

    -

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 7.

    +
    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)
    +

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 8.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 12, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 14, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -199,7 +193,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 13, except for a few additions that ensure the security of the Asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 15, except for a few additions that ensure the security of the Asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -242,7 +236,11 @@
    Add a boolean split variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
      -
    • If split = 1 then set v' = 0 otherwise v'=v^old from the auxiliary input.
      • +
    • If split = 1 then set + \(\mathsf{v}' = 0\) + otherwise + \(\mathsf{v}'=\mathsf{v^{old}}\) + from the auxiliary input.
    @@ -329,7 +327,7 @@

    Backward Compatibility

    -

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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

    +

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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.

    Burn Mechanism

    @@ -348,20 +346,20 @@ \((\mathsf{valueBalance_{AssetId}, 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.

    - \(\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]\) + \(\mathsf{assetBurn = \{ (v^{AssetId}, AssetId)}\ |\ \forall\ \mathsf{AssetId}\ \textit{s.t.}\ \mathsf{v^{AssetId}} \neq 0 \}\)

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

    Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective \(\mathsf{AssetId}\) as the value base point of the Pedersen Commitment. This is done as follows

    - \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\) + \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{OrchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    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, the number of Assets, nor their identifiers will be revealed, except in the case that an Asset is burnt.

    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.

    ZSA Transaction Structure

    -

    Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in 14:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 16, with the following additions to the Orchard bundle:

    @@ -386,19 +384,19 @@
    -

    And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the +

    In terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (due to the addition of the \(\mathsf{AssetId}\) ). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action.

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 16.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 18.

    Security and Privacy

    • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
      • -
    • When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design
      • -
    • We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state
      • +
    • When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design.
      • +
    • We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state.

    Deplopyment

    @@ -457,10 +455,18 @@ - +
    + + + +
    6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes
    + + + + @@ -468,15 +474,15 @@
    7 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
    - - + +
    7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)
    - + @@ -484,15 +490,23 @@
    89 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
    - +
    910 Pallas/Vesta supporting evidence
    + + + + + + + +
    11Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla hash function
    - + @@ -500,7 +514,7 @@
    1012 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
    - + @@ -508,7 +522,7 @@
    1113 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
    - + @@ -516,7 +530,7 @@
    1214 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard)
    - + @@ -524,7 +538,7 @@
    1315 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
    - + @@ -532,7 +546,7 @@
    1416 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    - + @@ -540,7 +554,7 @@
    1517 User-Defined Assets and Wrapped Assets
    - + diff --git a/zip-0226.rst b/zip-0226.rst index 2be23034d..840f9538f 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -56,9 +56,9 @@ The Asset identifier will be used to enforce the balance of an Action Descriptio As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\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 in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof for each Action, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment, in the new note commitment **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset identifiers in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures. -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 :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a PRF. +In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes [#protocol-dummynotes]_ for custom Assets, as we need to enforce that the :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a PRF. 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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets. @@ -79,34 +79,30 @@ In future network and protocol upgrades, the same Asset description string can b Note Structure & Commitment --------------------------- -First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note by including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note looks like: +First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, +where :math:`\mathsf{AssetId}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. - -:math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` - - -Where :math:`\mathsf{AssetId}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. +Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. +:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^{*}`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. -The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have +The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function [#protocol-concretesinsemillahash]_. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have: -:math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} \cup \{\bot\}` +.. math:: \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} The nullifier is generated in the same manner as in the Orchard protocol. Value Commitment ---------------- -The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ which is instantiated as +The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, which is instantiated as -:math:`\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` +.. math:: \mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} -Where :math:`\mathsf{v^{net} = v^{old} - v^{new}}` and - -:math:`\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}` - -:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}` +where :math:`\mathsf{v^{net} = v^{old} - v^{new}}`; +:math:`\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}`; and +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}`. In the case of the Orchard protocol, we see that the base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and :math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC @@ -114,17 +110,17 @@ being transferred. 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**. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes -:math:`\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}` +.. math:: \mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} -where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^*_{AssetId}}` is the value of the note of identifier :math:`\mathsf{AssetId}`, and +where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^{old}_{AssetId}}` and :math:`\mathsf{v^{new}_{AssetId}}` are the values of the old and new notes of identifier :math:`\mathsf{AssetId}` respectively, .. _`value base`: -:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}`, where the Asset identifier :math:`\mathsf{AssetId}` is computed as defined in ZIP 227 [#zip-0227]_. +:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}`, where the Asset identifier :math:`\mathsf{AssetId}` is computed as defined in ZIP 227 [#zip-0227]_, and -:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}` +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}`. -Where :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} =\mathcal{V}^{\mathsf{Orchard}}`. +We define :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}` so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 [#zip-0224]_. Value Balance Verification -------------------------- @@ -132,12 +128,11 @@ 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 [#protocol-binding]_. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. For a total of :math:`n` Actions in a transfer, the prover MUST still sign the `SIGHASH` of the transaction using the binding signature key - -:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}` +:math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}`. Then the verifier MUST compute -:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}` +.. math:: \mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}} and use it to verify the `bindingSignature` on the `SIGHASH` message, as described in §4.14 of the Zcash Specification [#protocol-binding]_. @@ -187,7 +182,7 @@ the input and output note are of the same :math:`\mathsf{AssetId}`: - The Value Commitment Integrity should be changed - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}` - Add a boolean ``split`` variable as an auxiliary witness. This variable is to be activated ``split = 1`` if the Action in question is a split and ``split = 0`` if the Action is actually spending an input note: - - If ``split = 1`` then set `v' = 0` otherwise `v'=v^old` from the auxiliary input. + - If ``split = 1`` then set :math:`\mathsf{v}' = 0` otherwise :math:`\mathsf{v}'=\mathsf{v^{old}}` from the auxiliary input. - The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes): - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. - The Nullifier Integrity will be changed to prevent the identification of notes @@ -213,7 +208,7 @@ Backward Compatibility In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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 +- The ZEC-based actions will still include dummy input notes, whereas the ZSA-based actions will include split input notes. Burn Mechanism @@ -228,13 +223,13 @@ We require that for every :math:`\mathsf{valueBalance_{AssetId}}` provided as ab For every custom Asset that is burnt, we add to the `assetBurn` vector the tuple :math:`(\mathsf{valueBalance_{AssetId}, 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. -:math:`\mathsf{assetBurn = [(v^{AssetId}, AssetId)}| \forall \mathsf{AssetId} \textit{ s.t.}\mathsf{v^{AssetId}\neq 0}]` +:math:`\mathsf{assetBurn = \{ (v^{AssetId}, AssetId)}\ |\ \forall\ \mathsf{AssetId}\ \textit{s.t.}\ \mathsf{v^{AssetId}} \neq 0 \}` The value balances for each Asset identifier in `assetBurn` represents the amount of that Asset identifier that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective :math:`\mathsf{AssetId}` as the value base point of the Pedersen Commitment. This is done as follows -:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{ORchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` +:math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{OrchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` 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, the number of Assets, nor their identifiers will be revealed, except in the case that an Asset is burnt. @@ -242,7 +237,7 @@ In the case that the balance of all the action values related to a specific Asse ZSA Transaction Structure ========================= -Similar to version 5 transaction format, with the following modifications to the Orchard bundle, as defined in [#protocol-transactionstructure]_: +The transaction format is similar to the version 5 transaction format described in the Zcash specification [#protocol-transactionstructure]_, with the following additions to the Orchard bundle: +-----------------+-------------+-----------------------------------+-------------------------+ | Bytes | Name | Data Type | Description | @@ -253,7 +248,7 @@ Similar to version 5 transaction format, with the following modifications to the | | | | 8 bytes of valueBalance | +-----------------+-------------+-----------------------------------+-------------------------+ -And in terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (given by the addition of the :math:`\mathsf{AssetId}`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action. +In terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (due to the addition of the :math:`\mathsf{AssetId}`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action. Other Considerations ==================== @@ -267,8 +262,8 @@ Security and Privacy -------------------- - Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. -- When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design -- We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state +- When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design. +- We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state. Deplopyment ----------- @@ -293,10 +288,12 @@ References .. [#zip-0224] `ZIP 224: Orchard `_ .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ +.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes `_ .. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ .. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ .. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ +.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla hash function `_ .. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments `_ .. [#protocol-concretevaluecommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ .. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) `_ From 9b2e51ae2d66da7b45bb695dab4d26d4accd8636 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 10 Jan 2023 08:23:14 +0530 Subject: [PATCH 042/101] edits to ZIP 226 and ZIP 227 --- zip-0226.html | 9 ++++++--- zip-0226.rst | 4 +++- zip-0227.html | 30 ++++++++++++++++++++---------- zip-0227.rst | 17 +++++++++-------- 4 files changed, 38 insertions(+), 22 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 8a3de2998..310ba3847 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -102,9 +102,12 @@ \(\mathsf{AssetId}\) . So a ZSA note is a tuple \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) - , where - \(\mathsf{AssetId}\) - is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.

    + , where

    +
      +
    • + \(\mathsf{AssetId} : \mathbb{P}^*\) + is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.
      • +

    Let \(\mathsf{Note^{OrchardZSA}}\) be the type of a ZSA note, i.e. diff --git a/zip-0226.rst b/zip-0226.rst index 840f9538f..55891e420 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -80,7 +80,9 @@ Note Structure & Commitment --------------------------- First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, -where :math:`\mathsf{AssetId}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. +where + +- :math:`\mathsf{AssetId} : \mathbb{P}^*` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. :math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^{*}`. diff --git a/zip-0227.html b/zip-0227.html index 9fccd6854..126e2a55e 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -90,7 +90,7 @@ , as a public verification key:

    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7, and can further be in It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, @@ -117,7 +117,7 @@

    \(\mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)}\)

    where \(\mathsf{GroupHash^{\mathbb{P}}}\) - is the Group Hash into the group of points on the Pallas curve defined in the protocol spec 9

    + is the Group Hash into the group of points on the Pallas curve defined in the protocol specification 9.

    Global Issuance State

    Issuance requires the following additions to the global state:

    @@ -192,7 +192,7 @@ \(\mathsf{isk}\) , that validates the issuance . -

    The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format.

    +

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 10.

    1618 ZIP 317b: ZSA Extension Proportional Fee Mechanism
    @@ -238,17 +238,19 @@
    • encode \(\mathsf{asset\_desc}\) - as 512 byte-string
      • + as 512 byte-string.
    • compute \(\mathsf{AssetId}\) as - \(GroupHash^{\mathbb{P}}(ik || asset\_desc)\) + \(\mathsf{AssetIdHash(ik, asset\_desc)}\)
    • set the finalize boolean as desired (if more more issuance actions are to be created for this Asset identifier, set finalize = 0, otherwise set finalize = 1)
      • -
    • For each recipient i: +
    • For each recipient + \(i\) + :
      • generate a ZSA output note as - \(\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}\) + \(\mathsf{note}_i =(\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetId}, \mathsf{rcm}_i)\)
      • @@ -273,7 +275,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -408,7 +410,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -419,7 +421,7 @@ in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -514,6 +516,14 @@

    + + + + + + + +
    10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    diff --git a/zip-0227.rst b/zip-0227.rst index 2ee61f6a0..028450fad 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -98,7 +98,7 @@ The two keys are derived in an analogous manner to the spend authorizing key and .. math:: \mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)} -This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_, and can further be in It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. +This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. Asset Identifier ---------------- @@ -118,7 +118,7 @@ In the case of the Orchard protocol, we define .. math:: \mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)} -where :math:`\mathsf{GroupHash^{\mathbb{P}}}` is the Group Hash into the group of points on the Pallas curve defined in the protocol spec [#protocol-concretegrouphashpallasandvesta]_ +where :math:`\mathsf{GroupHash^{\mathbb{P}}}` is the Group Hash into the group of points on the Pallas curve defined in the protocol specification [#protocol-concretegrouphashpallasandvesta]_. Global Issuance State --------------------- @@ -158,7 +158,7 @@ An issuance bundle, `IssueBundle`, is the aggregate of all the issuance-related - `actions`: an array of issuance actions, of type `IssueAction`. - `authorization`: the signature of the transaction SIGHASH, signed by the issuance authorizing key, :math:`\mathsf{isk}`, that validates the issuance . -The issuance bundle is then added within the transaction format as a new bundle. This structure will be added to the v6 transaction format. +The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format [#protocol-transactionstructure]_. ======= ==================== ========================== ========================================================================= Bytes Name Data Type Description @@ -175,12 +175,12 @@ The issuer program performs the following operations For all actions `IssueAction`: -- encode :math:`\mathsf{asset\_desc}` as 512 byte-string -- compute :math:`\mathsf{AssetId}` as :math:`GroupHash^{\mathbb{P}}(ik || asset\_desc)` +- encode :math:`\mathsf{asset\_desc}` as 512 byte-string. +- compute :math:`\mathsf{AssetId}` as :math:`\mathsf{AssetIdHash(ik, asset\_desc)}` - set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) -- For each recipient ``i``: +- For each recipient :math:`i`: - - generate a ZSA output note as :math:`\mathsf{ note_i =(d_i, {pk_d}_i, v_i, \rho_i, \psi_i, \mathsf{AssetId}, rcm_i)}` + - generate a ZSA output note as :math:`\mathsf{note}_i =(\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetId}, \mathsf{rcm}_i)` - encode the `IssueAction` into the vector `vIssueActions` of the bundle @@ -380,4 +380,5 @@ References .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ -.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ \ No newline at end of file +.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ +.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ \ No newline at end of file From c0caa9c4947943c682d5ab4ed21dbf7cc97c8634 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 11 Jan 2023 15:23:38 +0530 Subject: [PATCH 043/101] correcting small error --- zip-0226.html | 4 ++-- zip-0226.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 310ba3847..ec672ecc8 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -105,13 +105,13 @@ , where

    • - \(\mathsf{AssetId} : \mathbb{P}^*\) + \(\mathsf{AssetId} : \mathbb{P}\) is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.

    Let \(\mathsf{Note^{OrchardZSA}}\) be the type of a ZSA note, i.e. - \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^{*}\) + \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}\) .

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) diff --git a/zip-0226.rst b/zip-0226.rst index 55891e420..7bd4285db 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -82,10 +82,10 @@ Note Structure & Commitment First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P}^*` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. +- :math:`\mathsf{AssetId} : \mathbb{P}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. -:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^{*}`. +:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. From c44d3106e36c1c83719e3e17f23f5ebc7d85b245 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 01:22:13 +0530 Subject: [PATCH 044/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zip-0226.rst b/zip-0226.rst index 7bd4285db..928dc2336 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -29,7 +29,8 @@ We define the following additional terms: - Asset: A type of note that can be transferred on the Zcash block chain, identified by the :math:`\mathsf{AssetId}` parameter. - ZEC is the default (and currently the only defined) Asset for the Zcash mainnet. - - We use the term "custom Asset" to refer to any Asset other than ZEC. + - TAZ is the default (and currently the only defined) Asset for the Zcash testnet. + - We use the term "Custom Asset" to refer to any Asset other than ZEC and TAZ. - Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. - Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. From df1f240e274ccb89a0b8f970eccb42930e1feaf9 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 01:23:06 +0530 Subject: [PATCH 045/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/zip-0226.rst b/zip-0226.rst index 928dc2336..606d05b15 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -40,9 +40,12 @@ We define the following additional terms: Abstract ======== -ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the -Orchard protocol that enables the creation, transfer, and burn of custom Assets on the Zcash chain. The creation of such Assets is defined -in ZIP 227 [#zip-0227]_. The transfer and burn of such Assets is defined in ZIP 226 [#zip-0226]_. +ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol — a set +of protocol features that enable the creation, transfer, and burn of Custom Assets on the Zcash chain. + +Creation of such Assets is defined in ZIP 227 [#zip-0227]_. Transfer and burn of such Assets is defined +in ZIP 226 [#zip-0226]_. The ZSA protocol is proposed to be instantiated by a modification to the +Orchard protocol, as specified in these ZIPs. Motivation ========== From 5ea0ad47c6e06b83cd3690214c3f10c2bfbc639a Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 01:23:43 +0530 Subject: [PATCH 046/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/zip-0226.rst b/zip-0226.rst index 606d05b15..2d4f306af 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -50,7 +50,10 @@ Orchard protocol, as specified in these ZIPs. Motivation ========== -The Orchard protocol deployed in NU5 does not 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. +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. Overview ======== From 47bc7798116cceba2ea11db3a4dd007a3adacc02 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 01:24:23 +0530 Subject: [PATCH 047/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0226.rst b/zip-0226.rst index 2d4f306af..9abcf562a 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -59,7 +59,7 @@ Overview ======== In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call :math:`\mathsf{AssetId}`. -The Asset identifier will be used to enforce the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred. +The Asset identifier will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially 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 [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\mathsf{cv^{net}}`, of the *net value* in an Orchard Action. From 46d603b867bac8b2f0afb72de994822ccf70af68 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 01:25:23 +0530 Subject: [PATCH 048/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0226.rst b/zip-0226.rst index 9abcf562a..b8150e8d7 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -61,7 +61,7 @@ In order to be able to represent different Asset identifiers in Orchard, we need The Asset identifier will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially 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 [#initial-zsa-issue]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that generates the value commitment, :math:`\mathsf{cv^{net}}`, of the *net value* in an Orchard Action. +As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_ [#generalized-value-commitments]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that derives the value commitment, :math:`\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 in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures. From 2352b639ba8e296e1c154b9b2b084843d9ab5574 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 01:25:38 +0530 Subject: [PATCH 049/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/zip-0226.rst b/zip-0226.rst index b8150e8d7..b27cfe260 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -309,4 +309,5 @@ References .. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ .. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ .. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ +.. [#generalized-value-commitments] `Comment on Generalized Value Commitments `_ .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ \ No newline at end of file From 0b35efaaa7ca0e24c3d17823d034d58806f8d45b Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 25 Jan 2023 01:32:10 +0530 Subject: [PATCH 050/101] updating html file to match rst file changed during review --- zip-0226.html | 60 ++++++++++++++++++++++++++++++--------------------- 1 file changed, 35 insertions(+), 25 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index ec672ecc8..593a856b3 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -31,7 +31,8 @@ parameter.

    • ZEC is the default (and currently the only defined) Asset for the Zcash mainnet.
      • -
    • We use the term "custom Asset" to refer to any Asset other than ZEC.
      • +
    • TAZ is the default (and currently the only defined) Asset for the Zcash testnet.
      • +
    • We use the term "Custom Asset" to refer to any Asset other than ZEC and TAZ.
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
    • @@ -43,35 +44,36 @@

    Abstract

    -

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer, and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 5. The transfer and burn of such Assets is defined in ZIP 226 4.

    +

    ZIP 226 and ZIP 227 propose in conjunction the Zcash Shielded Assets (ZSA) protocol &mdash; a set of protocol features that enable the creation, transfer, and burn of Custom Assets on the Zcash chain.

    +

    Creation of such Assets is defined in ZIP 227 5. Transfer and burn of such Assets is defined in ZIP 226 4. The ZSA protocol is proposed to be instantiated by a modification to the Orchard protocol, as specified in these ZIPs.

    Motivation

    -

    The Orchard protocol deployed in NU5 does not 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.

    +

    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.

    Overview

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call \(\mathsf{AssetId}\) .

    -

    The Asset identifier will be used to enforce the balance of an Action Description 7 is preserved across Assets (see the Orchard Binding Signature 8), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The Asset identifier will be used to enforce that the balance of an Action Description 7 is preserved across Assets (see the Orchard Binding Signature 8), 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}-value^{new}}\) - , must be balanced only with respect to the same Asset identifier. This is specially important since we will allow different Action Descriptions to transfer notes of different Asset identifiers, where the overall balance is checked without revealing which Assets (or how many different identifiers) are being transferred.

    -

    As was initially proposed by Jack Grigg and Daira Hopwood 17, we propose to make this happen by changing the value base point, + , must be balanced only with respect to the same Asset identifier. This is specially 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 17 18, we propose to make this happen by changing the value base point, \(\mathcal{V}^{\mathsf{Orchard}}\) - , in the Homomorphic Pedersen Commitment that generates the value commitment, + , 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 in the transaction. We propose to make the \(\mathsf{AssetId}\) - identifier an auxiliary input to the proof for each Action statement 15, represented already as a point on the Pallas curve. The circuit then should check that the same + identifier an auxiliary input to the proof for each Action statement 15, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetId}\) - is used in the old note commitment and the new note commitment 12, and as the base point + is used in the old note commitment and the new note commitment 12, and as the base point \(\mathcal{V}^\mathsf{Orchard}\) - in the value commitment 13. This ensures (1) that the input and output notes are of the same + in the value commitment 13. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetId}\) , and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures.

    -

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 14 for custom Assets, as we need to enforce that the +

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 14 for custom Assets, as we need to enforce that the \(\mathsf{AssetId}\) of the output note of that split Action is the output of a PRF.

    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 @@ -98,7 +100,7 @@ , from one shielded protocol to another.

    Note Structure & Commitment

    -

    First, we need to adapt the components that define the Assets, i.e.: notes. A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, +

    First, we need to adapt the components that define the Assets, i.e.: notes. A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, \(\mathsf{AssetId}\) . So a ZSA note is a tuple \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) @@ -106,7 +108,7 @@

    • \(\mathsf{AssetId} : \mathbb{P}\) - is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.
      • + is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.

    Let \(\mathsf{Note^{OrchardZSA}}\) @@ -117,13 +119,13 @@ \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 12 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 11. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    + in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 12 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 11. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)

    The nullifier is generated in the same manner as in the Orchard protocol.

    Value Commitment

    -

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    +

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    where \(\mathsf{v^{net} = v^{old} - v^{new}}\) @@ -152,16 +154,16 @@ \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}\) , where the Asset identifier \(\mathsf{AssetId}\) - is computed as defined in ZIP 227 5, and

    + is computed as defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) .

    We define \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    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 8. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, +

    In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol 8. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    For a total of @@ -171,13 +173,13 @@ .

    Then the verifier MUST compute

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)
    -

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 8.

    +

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 8.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 14, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 14, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -196,7 +198,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 15, except for a few additions that ensure the security of the Asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 15, except for a few additions that ensure the security of the Asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -362,7 +364,7 @@

    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.

    ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 16, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 16, with the following additions to the Orchard bundle:

    @@ -393,7 +395,7 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 18.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 19.

    Security and Privacy

      @@ -554,10 +556,18 @@
    - +
    + + + +
    18Comment on Generalized Value Commitments
    + + + + From 97eacabbef9377ede457bf6faff92cc53513cd9f Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Wed, 25 Jan 2023 17:46:32 +0530 Subject: [PATCH 051/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0226.rst b/zip-0226.rst index b27cfe260..5285d3e62 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -32,10 +32,10 @@ We define the following additional terms: - TAZ is the default (and currently the only defined) Asset for the Zcash testnet. - We use the term "Custom Asset" to refer to any Asset other than ZEC and TAZ. -- Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool. -- Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain. -- Split Input: an Action input identifying a Zcash Shielded Asset note, used to ensure that the output note of that Action is of a validly issued :math:`\mathsf{AssetId}` when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input. -- Split Action: a Zcash Shielded Asset Action that contains a Split Input. +- Native Asset: a Custom Asset with issuance defined on the Zcash block chain. +- Wrapped Asset: a Custom Asset with native issuance defined outside the Zcash block chain. +- Split Input: an Action input identifying a Custom Asset note, used to ensure that the output note of that Action is of a validly issued :math:`\mathsf{AssetId}` when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input. +- Split Action: an Action that contains a Split Input. Abstract ======== From e08fc8423729f79fdb26b456983cde29a5a7299f Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Fri, 27 Jan 2023 19:40:31 +0530 Subject: [PATCH 052/101] Apply suggestions from ZIP review Co-authored-by: Deirdre Connolly --- zip-0226.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/zip-0226.rst b/zip-0226.rst index 5285d3e62..3a541db84 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -57,7 +57,7 @@ issuance and bridging purposes. Overview ======== -In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call :math:`\mathsf{AssetId}`. +In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field in a note that uniquely represents the identifier of the Asset in question, which we call :math:`\mathsf{AssetId^{Orchard}}`. The Asset identifier will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially 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. @@ -77,7 +77,7 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash protocols). From this Asset description the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom Asset. Note that the :math:`\mathsf{AssetId}` of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`. @@ -86,13 +86,13 @@ In future network and protocol upgrades, the same Asset description string can b Note Structure & Commitment --------------------------- -First, we need to adapt the components that define the Assets, i.e.: *notes*. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, +A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where - :math:`\mathsf{AssetId} : \mathbb{P}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. -:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}`. +:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. @@ -198,7 +198,7 @@ the input and output note are of the same :math:`\mathsf{AssetId}`: - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - if :math:`split = 0` then constrain :math:`\psi' = \psi^{old}`. (Otherwise :math:`\psi'` should be sampled randomly.) -**Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes. +**Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with Orchard ZEC notes. The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. @@ -217,7 +217,7 @@ Backward Compatibility In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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. +- The ZEC-based Actions will still include dummy input notes, whereas the ZSA-based Actions will include split input notes. Burn Mechanism @@ -234,18 +234,19 @@ For every custom Asset that is burnt, we add to the `assetBurn` vector the tuple :math:`\mathsf{assetBurn = \{ (v^{AssetId}, AssetId)}\ |\ \forall\ \mathsf{AssetId}\ \textit{s.t.}\ \mathsf{v^{AssetId}} \neq 0 \}` -The value balances for each Asset identifier in `assetBurn` represents the amount of that Asset identifier that is being burnt. In the case of ZEC, the value balance represents either the transaction fee, or the amount of ZEC changing anonymity pools (to Sapling or Transparent). +The value balances for each Asset identifier in `assetBurn` represents the amount of that Asset identifier 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). Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective :math:`\mathsf{AssetId}` as the value base point of the Pedersen Commitment. This is done as follows :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{OrchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` -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, the number of Assets, nor their identifiers will be revealed, except in the case that an Asset is burnt. +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 identifiers, will be revealed, except in the case that an Asset is burnt. **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. ZSA Transaction Structure ========================= + The transaction format is similar to the version 5 transaction format described in the Zcash specification [#protocol-transactionstructure]_, with the following additions to the Orchard bundle: +-----------------+-------------+-----------------------------------+-------------------------+ @@ -257,7 +258,7 @@ The transaction format is similar to the version 5 transaction format described | | | | 8 bytes of valueBalance | +-----------------+-------------+-----------------------------------+-------------------------+ -In terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (due to the addition of the :math:`\mathsf{AssetId}`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action. +In terms of the Action size, the ZSA action size differs from the Orchard action size by 32 bytes (due to the addition of the :math:`\mathsf{AssetId}`). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA Action. Other Considerations ==================== @@ -274,7 +275,7 @@ Security and Privacy - When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design. - We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state. -Deplopyment +Deployment ----------- The Zcash Shielded Assets protocol should be deployed by replacing the Orchard protocol in a subsequent Network Upgrade. The design of this protocol ensures that there is no need to use any turnstile mechanism, being that Orchard-based ZEC notes can be used directly within the ZSA Actions. From b1ce706e4277788145c701ee7a2af86939c39155 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 25 Jan 2023 18:53:27 +0530 Subject: [PATCH 053/101] adding key components spec link --- zip-0226.html | 8 ++++---- zip-0227.html | 32 ++++++++++++++++++++------------ zip-0227.rst | 7 ++++--- 3 files changed, 28 insertions(+), 19 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 593a856b3..c001e1ecf 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -35,12 +35,12 @@
  • We use the term "Custom Asset" to refer to any Asset other than ZEC and TAZ.
    • -
  • Zcash Shielded Asset: an Asset with issuance defined on the Zcash block chain, and, for now, belonging to the Orchard shielded pool.
    • -
  • Wrapped Asset: a Zcash Shielded Asset with native issuance defined outside the Zcash block chain.
    • -
  • Split Input: an Action input identifying a Zcash Shielded Asset note, used to ensure that the output note of that Action is of a validly issued +
  • Native Asset: a Custom Asset with issuance defined on the Zcash block chain.
    • +
  • Wrapped Asset: a Custom Asset with native issuance defined outside the Zcash block chain.
    • +
  • Split Input: an Action input identifying a Custom Asset note, used to ensure that the output note of that Action is of a validly issued \(\mathsf{AssetId}\) when there is no corresponding real input note to spend. The Action does not spend the note identified by the Split Input.
    • -
  • Split Action: a Zcash Shielded Asset Action that contains a Split Input.
    • +
  • Split Action: an Action that contains a Split Input.

    • Abstract

    diff --git a/zip-0227.html b/zip-0227.html index 126e2a55e..a3aafa099 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -68,16 +68,16 @@

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    Issuance Keys

    -

    There are two keys relevant to the Issuer:

    +

    The ZSA Protocol adds the following two keys to the key components 9:

    1. The issuance authorizing key, denoted as \(\mathsf{isk}\) - , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key.
      2. + , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer.
    2. The issuance validating key, denoted as \(\mathsf{ik}\) - , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. Throughout we also call this key the issuer verification key.
      3. + , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.
    -

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    +

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    • The issuance authorizing key is derived directly from the spending key, \(\mathsf{sk}\) @@ -90,7 +90,7 @@ , as a public verification key:
    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, @@ -117,7 +117,7 @@

    \(\mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)}\)

    where \(\mathsf{GroupHash^{\mathbb{P}}}\) - is the Group Hash into the group of points on the Pallas curve defined in the protocol specification 9.

    + is the Group Hash into the group of points on the Pallas curve defined in the protocol specification 10.

    Global Issuance State

    Issuance requires the following additions to the global state:

    @@ -192,7 +192,7 @@ \(\mathsf{isk}\) , that validates the issuance . -

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 10.

    +

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 11.

    19 ZIP 317b: ZSA Extension Proportional Fee Mechanism
    @@ -275,7 +275,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -410,7 +410,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -421,7 +421,7 @@ in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -508,10 +508,18 @@

    - +
    + + + +
    9Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys
    + + + + @@ -519,7 +527,7 @@
    10 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta
    - + diff --git a/zip-0227.rst b/zip-0227.rst index 028450fad..287eceb01 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -82,11 +82,11 @@ The issuance mechanism is broad enough for issuers to either create Assets on Zc Issuance Keys ------------- -There are two keys relevant to the Issuer: +The ZSA Protocol adds the following two keys to the key components [#protocol-addressesandkeys]_: -1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer. Throughout we also call this key the issuer signature key. +1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer. -2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. Throughout we also call this key the issuer verification key. +2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. @@ -380,5 +380,6 @@ References .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ +.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys `_ .. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ .. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ \ No newline at end of file From 4a6b4af8f97882a73721f62418ddf5d41c6f3705 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Fri, 27 Jan 2023 19:13:24 +0530 Subject: [PATCH 054/101] changes to ZIP 226 --- zip-0226.html | 36 ++++++++++++++++++------------------ zip-0226.rst | 10 +++++----- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index c001e1ecf..261406349 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -51,8 +51,8 @@

    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.

    Overview

    -

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field that uniquely represents the identifier of the Asset in question, which we call - \(\mathsf{AssetId}\) +

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field in a note that uniquely represents the identifier of the Asset in question, which we call + \(\mathsf{AssetId^{Orchard}}\) .

    The Asset identifier will be used to enforce that the balance of an Action Description 7 is preserved across Assets (see the Orchard Binding Signature 8), and by extension the balance of an Orchard transaction. That is, the sum of all the \(\mathsf{value^{net}}\) @@ -85,7 +85,7 @@

    Asset Identifiers

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, \(\mathsf{asset\_desc}\) - , which is a global byte string (valid across all -future- Zcash protocols). From this Asset description the specific Asset identifier, + , which is a global byte string (scoped across all future versions of Zcash). From this Asset description the specific Asset identifier, \(\mathsf{AssetId}\) , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    This @@ -100,26 +100,26 @@ , from one shielded protocol to another.

    Note Structure & Commitment

    -

    First, we need to adapt the components that define the Assets, i.e.: notes. A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, +

    Let + \(\mathsf{Note^{OrchardZSA}}\) + be the type of a ZSA note, i.e. + \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}\) + .

    +

    A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, \(\mathsf{AssetId}\) . So a ZSA note is a tuple \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) , where

    • - \(\mathsf{AssetId} : \mathbb{P}\) + \(\mathsf{AssetId} : \mathbb{P*}\) is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.
    -

    Let - \(\mathsf{Note^{OrchardZSA}}\) - be the type of a ZSA note, i.e. - \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}\) - .

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 12 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    + in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 12 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 11. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)

    The nullifier is generated in the same manner as in the Orchard protocol.

    @@ -290,7 +290,7 @@ -

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with the Orchard ZEC notes.

    +

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

    • @@ -332,7 +332,7 @@

    Backward Compatibility

    -

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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.

    +

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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.

    Burn Mechanism

    @@ -353,14 +353,14 @@

    \(\mathsf{assetBurn = \{ (v^{AssetId}, AssetId)}\ |\ \forall\ \mathsf{AssetId}\ \textit{s.t.}\ \mathsf{v^{AssetId}} \neq 0 \}\)

    -

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

    +

    The value balances for each Asset identifier in assetBurn represents the amount of that Asset identifier 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).

    Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective \(\mathsf{AssetId}\) as the value base point of the Pedersen Commitment. This is done as follows

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{OrchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    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, the number of Assets, nor their identifiers will be revealed, except in the case that an Asset is burnt.

    +

    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 identifiers, will be revealed, except in the case that an Asset is burnt.

    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.

    ZSA Transaction Structure

    @@ -389,9 +389,9 @@
    1011 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    -

    In terms of the action size, the ZSA action size differs from the Orchard action size by 32 bytes (due to the addition of the +

    In terms of the Action size, the ZSA action size differs from the Orchard action size by 32 bytes (due to the addition of the \(\mathsf{AssetId}\) - ). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA action.

    + ). This implies that the size goes from 820 bytes in the Orchard action to 852 bytes in the ZSA Action.

    Other Considerations

    Transaction Fees

    @@ -404,7 +404,7 @@
  • We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state.
    • -

    Deplopyment

    +

    Deployment

    The Zcash Shielded Assets protocol should be deployed by replacing the Orchard protocol in a subsequent Network Upgrade. The design of this protocol ensures that there is no need to use any turnstile mechanism, being that Orchard-based ZEC notes can be used directly within the ZSA Actions.

    diff --git a/zip-0226.rst b/zip-0226.rst index 3a541db84..df1617c92 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -86,15 +86,15 @@ In future network and protocol upgrades, the same Asset description string can b Note Structure & Commitment --------------------------- +Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. +:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}`. + A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. - -Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. -:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}`. +- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. -In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for non-ZEC Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. +In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function [#protocol-concretesinsemillahash]_. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have: From b45bcf8518f299bd6e24d08b8a1f2c8d93a1f55a Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Sat, 28 Jan 2023 12:15:42 +0530 Subject: [PATCH 055/101] Update zip-0226.rst Co-authored-by: str4d --- zip-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0226.rst b/zip-0226.rst index df1617c92..28da5ecc8 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -105,7 +105,7 @@ The nullifier is generated in the same manner as in the Orchard protocol. Value Commitment ---------------- -The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, which is instantiated as +The Orchard Protocol uses a Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, which is instantiated as .. math:: \mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} From b54785369c83c1fc0d3f967403539ebbb1f683c9 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 28 Jan 2023 12:16:25 +0530 Subject: [PATCH 056/101] added note plaintext updates to ZIP 226 --- zip-0226.html | 8 +++++++- zip-0226.rst | 7 ++++++- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 261406349..beac6c394 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -113,7 +113,9 @@
    • \(\mathsf{AssetId} : \mathbb{P*}\) - is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol.
      • + is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as + \(\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})\) + .

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) @@ -123,6 +125,10 @@

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 11. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)

    The nullifier is generated in the same manner as in the Orchard protocol.

    +

    The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext. It consists of

    +

    + \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\) +

    Value Commitment

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    diff --git a/zip-0226.rst b/zip-0226.rst index 28da5ecc8..6fd52ae43 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -92,7 +92,7 @@ Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. +- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. @@ -102,6 +102,11 @@ The commitment output is still indistinguishable from the original Orchard ZEC n The nullifier is generated in the same manner as in the Orchard protocol. +The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext. +It consists of + +:math:`(\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})` + Value Commitment ---------------- From 0f62ddafc618c2ba8db486b76675461401391bb0 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 28 Jan 2023 19:53:02 +0530 Subject: [PATCH 057/101] added html file update of ZIP 226 --- zip-0226.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0226.html b/zip-0226.html index beac6c394..eb9dec8c9 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -131,7 +131,7 @@

    Value Commitment

    -

    The Orchard Protocol uses a Sinsemilla-based Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    where \(\mathsf{v^{net} = v^{old} - v^{new}}\) From 6e24472d4469936b4f3ffb4780f5dc78521aca41 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 30 Jan 2023 08:03:44 +0530 Subject: [PATCH 058/101] further edits and rearrangements --- zip-0226.html | 122 +++++++++++++++++++++++++++----------------------- zip-0226.rst | 40 ++++++++--------- 2 files changed, 85 insertions(+), 77 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index eb9dec8c9..562755a72 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -54,28 +54,30 @@

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field in a note that uniquely represents the identifier of the Asset in question, which we call \(\mathsf{AssetId^{Orchard}}\) .

    -

    The Asset identifier will be used to enforce that the balance of an Action Description 7 is preserved across Assets (see the Orchard Binding Signature 8), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The Asset identifier will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 9), 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}-value^{new}}\) , must be balanced only with respect to the same Asset identifier. This is specially 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 17 18, we propose to make this happen by changing the value base point, +

    As was initially proposed by Jack Grigg and Daira Hopwood 19 20, 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 in the transaction. We propose to make the \(\mathsf{AssetId}\) - identifier an auxiliary input to the proof for each Action statement 15, represented already as a point on the Pallas curve. The circuit then should check that the same + identifier an auxiliary input to the proof for each Action statement 17, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetId}\) - is used in the old note commitment and the new note commitment 12, and as the base point + is used in the old note commitment and the new note commitment 14, and as the base point \(\mathcal{V}^\mathsf{Orchard}\) - in the value commitment 13. This ensures (1) that the input and output notes are of the same + in the value commitment 15. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetId}\) , and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures.

    -

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 14 for custom Assets, as we need to enforce that the +

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 16 for Custom Assets, as we need to enforce that the \(\mathsf{AssetId}\) - of the output note of that split Action is the output of a PRF.

    + of the output note of that split Action is the output of a valid + \(\mathsf{AssetIdHash}\) + computation defined in ZIP 227 5.

    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 \(\mathsf{valueBalance}\) of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets.

    @@ -87,7 +89,7 @@ \(\mathsf{asset\_desc}\) , which is a global byte string (scoped across all future versions of Zcash). From this Asset description the specific Asset identifier, \(\mathsf{AssetId}\) - , is derived with a GroupHash and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve).

    + , is derived as defined in ZIP 227 5.

    This \(\mathsf{AssetId}\) will be the base point of the value commitment for the specific custom Asset. Note that the @@ -105,7 +107,7 @@ be the type of a ZSA note, i.e. \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}\) .

    -

    A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, +

    A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, \(\mathsf{AssetId}\) . So a ZSA note is a tuple \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) @@ -113,7 +115,7 @@

    • \(\mathsf{AssetId} : \mathbb{P*}\) - is the unique random element of the Pallas group 9 that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as + is the unique random element of the Pallas group 11 that identifies each Asset in the Orchard protocol, as . The byte representation of the Asset identifier is defined as \(\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})\) .
    @@ -121,30 +123,19 @@ \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 12 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 11. 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 identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 14 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 13. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)
    -

    The nullifier is generated in the same manner as in the Orchard protocol.

    -

    The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext. It consists of

    -

    - \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\) -

    +

    The nullifier is generated in the same manner as in the Orchard protocol 10.

    +

    The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext 7. It consists of

    +
    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)

    Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 13 to perform the value commitment, which is instantiated as

    -
    \(\mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)
    -

    where - \(\mathsf{v^{net} = v^{old} - v^{new}}\) - ; - \(\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}\) - ; and - \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}\) - .

    -

    In the case of the Orchard protocol, we see that the base points +

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

    + as the values represent the amount of ZEC being transferred.

    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. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes

    \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    where @@ -160,18 +151,16 @@ \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}\) , where the Asset identifier \(\mathsf{AssetId}\) - is computed as defined in ZIP 227 5, and

    + is computed as defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) - .

    + , as in the Orchard protocol.

    We define \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    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 8. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, - \(\mathsf{v^{balanceOrchard}}\) - . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    +

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

    For a total of \(n\) Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key @@ -179,13 +168,18 @@ .

    Then the verifier MUST compute

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)
    -

    and use it to verify the bindingSignature on the SIGHASH message, as described in §4.14 of the Zcash Specification 8.

    -

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    +

    and use it to verify the bindingSignature on the SIGHASH message.

    +

    Rationale for Value Balance Verification

    +

    The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, + \(\mathsf{v^{balanceOrchard}}\) + . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    +

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    +

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 14, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -204,7 +198,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 15, except for a few additions that ensure the security of the Asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 17, except for a few additions that ensure the security of the Asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -370,7 +364,7 @@

    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.

    ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 16, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    @@ -401,7 +395,7 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 19.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 21.

    Security and Privacy

      @@ -474,10 +468,18 @@
    - +
    + + + +
    7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.5: Encodings of Note Plaintexts and Memo Fields
    + + + + @@ -485,15 +487,23 @@
    8 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
    - - + + + + +
    8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)9Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard)
    + + + + +
    10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.16: Note Commitments and Nullifiers
    - + @@ -501,7 +511,7 @@
    911 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
    - + @@ -509,7 +519,7 @@
    1012 Pallas/Vesta supporting evidence
    - + @@ -517,7 +527,7 @@
    1113 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla hash function
    - + @@ -525,7 +535,7 @@
    1214 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
    - + @@ -533,7 +543,7 @@
    1315 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
    - + @@ -541,7 +551,7 @@
    1416 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard)
    - + @@ -549,7 +559,7 @@
    1517 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
    - + @@ -557,7 +567,7 @@
    1618 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    - + @@ -565,7 +575,7 @@
    1719 User-Defined Assets and Wrapped Assets
    - + @@ -573,7 +583,7 @@
    1820 Comment on Generalized Value Commitments
    - + diff --git a/zip-0226.rst b/zip-0226.rst index 6fd52ae43..783d530b8 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -65,7 +65,7 @@ As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_ Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset identifiers in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures. -In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes [#protocol-dummynotes]_ for custom Assets, as we need to enforce that the :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a PRF. +In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes [#protocol-dummynotes]_ for Custom Assets, as we need to enforce that the :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a valid :math:`\mathsf{AssetIdHash}` computation defined in ZIP 227 [#zip-0227]_. 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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets. @@ -77,7 +77,7 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived with a `GroupHash` and used within the output notes, as defined by the specific protocol (e.g.: for now Orchard-style, using Pallas curve). +For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived as defined in ZIP 227 [#zip-0227]_. This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom Asset. Note that the :math:`\mathsf{AssetId}` of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`. @@ -92,7 +92,7 @@ Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. +- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, as . The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. @@ -100,27 +100,17 @@ The commitment output is still indistinguishable from the original Orchard ZEC n .. math:: \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} -The nullifier is generated in the same manner as in the Orchard protocol. +The nullifier is generated in the same manner as in the Orchard protocol [#protocol-commitmentsandnullifiers]_. -The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext. +The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext [#protocol-notept]_. It consists of -:math:`(\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})` +.. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]}) Value Commitment ---------------- -The Orchard Protocol uses a Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, which is instantiated as - -.. math:: \mathsf{cv^{net}:=ValueCommit^{Orchard}_{rcv}(v^{net})}:= \mathsf{[v^{net}]}\mathcal{V}^{\mathsf{Orchard}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} - -where :math:`\mathsf{v^{net} = v^{old} - v^{new}}`; -:math:`\mathcal{V}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "v")}`; and -:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}(\texttt{"z.cash:Orchard-cv", "r")}`. - -In the case of the Orchard protocol, we see that the base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and -:math:`\mathcal{R}^{\mathsf{Orchard}}` are fixed for every value commitment, as the values represent the amount of ZEC -being transferred. +The Orchard Protocol uses a Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, with fixed base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and :math:`\mathcal{R}^{\mathsf{Orchard}}` as the values represent the amount of ZEC being transferred. 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**. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes @@ -132,14 +122,14 @@ where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{A :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}`, where the Asset identifier :math:`\mathsf{AssetId}` is computed as defined in ZIP 227 [#zip-0227]_, and -:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}`. +:math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}`, as in the Orchard protocol. We define :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}` so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 [#zip-0224]_. 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 [#protocol-binding]_. The main reason why no changes to this process are needed is that no custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. +In order to verify the balance of the different Assets, the verifier MUST perform exactly the same process as for the Orchard protocol [#protocol-binding]_. For a total of :math:`n` Actions in a transfer, the prover MUST still sign the `SIGHASH` of the transaction using the binding signature key :math:`\mathsf{bsk} = \sum_{\mathsf{ \forall i\in \{1,...,n\}}} \mathsf{rcv_{i}}`. @@ -148,10 +138,16 @@ Then the verifier MUST compute .. math:: \mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}} -and use it to verify the `bindingSignature` on the `SIGHASH` message, as described in §4.14 of the Zcash Specification [#protocol-binding]_. +and use it to verify the `bindingSignature` on the `SIGHASH` message. + +Rationale for Value Balance Verification +'''''''''''''''''''''''''''''''''''''''' + +The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset identifier**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. + Split Notes ----------- @@ -304,8 +300,10 @@ References .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#protocol-notes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes `_ +.. [#protocol-notept] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ .. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.16: Note Commitments and Nullifiers `_ .. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ .. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ .. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla hash function `_ From aac639dec70eddcbd1e96bcb9fc158081183ed28 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 30 Jan 2023 12:02:38 +0530 Subject: [PATCH 059/101] edits to ZIP 226 based on review comments --- zip-0226.html | 24 ++++++++++++++---------- zip-0226.rst | 8 ++++---- 2 files changed, 18 insertions(+), 14 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 562755a72..11e83e532 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -170,7 +170,7 @@
    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    and use it to verify the bindingSignature on the SIGHASH message.

    Rationale for Value Balance Verification

    -

    The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, +

    The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    As in the Orchard protocol, the binding signature verification key, @@ -181,7 +181,7 @@

    Split Notes

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    -

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    +

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before.

    Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action:

    @@ -206,12 +206,16 @@
  • The Asset identifier, \(\mathsf{AssetId}\) , for the note is witnessed once, as an auxiliary input.
    • -
  • The witnessed Asset identifier, - \(\mathsf{AssetId}\) - , is added to the old note commitment input.
    • -
  • The witnessed Asset identifier, - \(\mathsf{AssetId}\) - , is added to the new note commitment input.
    • +
  • In the Old note commitment integrity constraint in the Orchard Action statement 17, + \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) + is replaced with + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, AssetId)}\) + .
    • +
  • In the New note commitment integrity constraint in the Orchard Action statement 17, + \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) + is replaced with + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, AssetId)}\) + .

    • Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset identifier, as represented in the notes:

      @@ -364,7 +368,7 @@

      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.

    ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    1921 ZIP 317b: ZSA Extension Proportional Fee Mechanism
    @@ -395,7 +399,7 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 21.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 21.

    Security and Privacy

      diff --git a/zip-0226.rst b/zip-0226.rst index 783d530b8..8abc2f525 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -143,7 +143,7 @@ and use it to verify the `bindingSignature` on the `SIGHASH` message. Rationale for Value Balance Verification '''''''''''''''''''''''''''''''''''''''' -The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. +The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset identifier**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. @@ -155,7 +155,7 @@ One of the key functionalities in a UTXO-based protocol is the fact that input n This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions *cannot* be of *any* Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. -In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for custom Assets and 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 +In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets. @@ -179,8 +179,8 @@ The advantage of the design described above, with respect to the circuit stateme the input and output note are of the same :math:`\mathsf{AssetId}`: - The Asset identifier, :math:`\mathsf{AssetId}`, for the note is witnessed once, as an auxiliary input. -- The witnessed Asset identifier, :math:`\mathsf{AssetId}`, is added to the old note commitment input. -- The witnessed Asset identifier, :math:`\mathsf{AssetId}`, is added to the new note commitment input. +- In the Old note commitment integrity constraint in the Orchard Action statement [#protocol-actionstatement]_, :math:`\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}` is replaced with :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, AssetId)}`. +- In the New note commitment integrity constraint in the Orchard Action statement [#protocol-actionstatement]_, :math:`\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}` is replaced with :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, AssetId)}`. **Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset identifier, as represented in the notes: From 29baf46b6f3b46440eb0c9a3730de30150ef9582 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 30 Jan 2023 19:18:54 +0530 Subject: [PATCH 060/101] further edits based on review comments --- zip-0226.html | 8 +++++--- zip-0226.rst | 4 ++-- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 11e83e532..34aedd2fb 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -233,8 +233,10 @@
      The Value Commitment Integrity should be changed
        -
      • Replace the input note value by a generic value, v', as - \(\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}\) +
      • Replace the input note value by a generic value, + \(\mathsf{v}'\) + , as + \(\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, AssetId)}\)
      @@ -283,7 +285,7 @@ \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\)
    • if - \(split = 0\) + \(\mathtt{split} = 0\) then constrain \(\psi' = \psi^{old}\) . (Otherwise diff --git a/zip-0226.rst b/zip-0226.rst index 8abc2f525..ead633cad 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -190,14 +190,14 @@ the input and output note are of the same :math:`\mathsf{AssetId}`: **Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the Asset identifier for the output note in a Split Action: - The Value Commitment Integrity should be changed - - Replace the input note value by a generic value, `v'`, as :math:`\mathsf{cv^net} = \mathsf{ValueCommit_rcv^OrchardZSA(v’ - v^new, AssetId)}` + - Replace the input note value by a generic value, :math:`\mathsf{v}'`, as :math:`\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, AssetId)}` - Add a boolean ``split`` variable as an auxiliary witness. This variable is to be activated ``split = 1`` if the Action in question is a split and ``split = 0`` if the Action is actually spending an input note: - If ``split = 1`` then set :math:`\mathsf{v}' = 0` otherwise :math:`\mathsf{v}'=\mathsf{v^{old}}` from the auxiliary input. - The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes): - Check that (path, pos) is a valid Merkle path of depth :math:`\mathsf{MerkleDepth^Orchard}`, from :math:`\mathsf{cm^old}` to the anchor :math:`\mathsf{rt^Orchard}`. - The Nullifier Integrity will be changed to prevent the identification of notes - Replace the :math:`\psi_{old}` value with a generic :math:`\psi'` as :math:`\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})` - - if :math:`split = 0` then constrain :math:`\psi' = \psi^{old}`. (Otherwise :math:`\psi'` should be sampled randomly.) + - if :math:`\mathtt{split} = 0` then constrain :math:`\psi' = \psi^{old}`. (Otherwise :math:`\psi'` should be sampled randomly.) **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with Orchard ZEC notes. From 5ffb6841d66c2c21150e2304c2acc938adedb2d1 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 30 Jan 2023 19:55:28 +0530 Subject: [PATCH 061/101] edits to ZIP 227 based on review comments --- zip-0227.html | 6 ++---- zip-0227.rst | 4 ++-- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index a3aafa099..d1509f493 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -53,6 +53,7 @@
    • The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain.
    • Issuing or changing the attributes of a specific Asset should require cryptographic authorization.
    • The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset identifier.
      • +
    • An issuer should be able to issue different Assets in the same transaction.

    Specification

    @@ -403,10 +404,7 @@

    Issuer Key or AssetId Compromise

    The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific Asset (see Future Work). In case of compromise, the following actions are recommended:

      -
    • If an Asset identifier is compromised (and not the issuer validating key), the finalize boolean for that Asset should be set to 0 and a new - \(\mathsf{AssetId}\) - generated instead.
      • -
    • If an issuer validating key is compromised, the finalize boolean for all the Assets issued with that key should be set to 0 and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new +
    • If an issuer validating key is compromised, the finalize boolean for all the Assets issued with that key should be set to 1 and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new \(\mathsf{AssetId}\) .
    diff --git a/zip-0227.rst b/zip-0227.rst index 287eceb01..3262914a3 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -59,6 +59,7 @@ Requirements - The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain. - Issuing or changing the attributes of a specific Asset should require cryptographic authorization. - The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset identifier. +- An issuer should be able to issue different Assets in the same transaction. Specification @@ -329,8 +330,7 @@ Security and Privacy Considerations The design of this protocol does not allow for a rotation of the issuer validating key, that would allow for replacing the key of a specific Asset (see Future Work). In case of compromise, the following actions are recommended: -- If an Asset identifier is compromised (and not the issuer validating key), the ``finalize`` boolean for that Asset should be set to `0` and a new :math:`\mathsf{AssetId}` generated instead. -- If an issuer validating key is compromised, the ``finalize`` boolean for all the Assets issued with that key should be set to `0` and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new :math:`\mathsf{AssetId}`. +- If an issuer validating key is compromised, the ``finalize`` boolean for all the Assets issued with that key should be set to `1` and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new :math:`\mathsf{AssetId}`. **Bridging Assets** For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 [#zip-0226]_. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset. From 3fab71291134be8752a627c584267d8d3b63f069 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 30 Jan 2023 20:07:08 +0530 Subject: [PATCH 062/101] edits --- zip-0226.html | 2 +- zip-0226.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 34aedd2fb..9fd070a5f 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -115,7 +115,7 @@
    • \(\mathsf{AssetId} : \mathbb{P*}\) - is the unique random element of the Pallas group 11 that identifies each Asset in the Orchard protocol, as . The byte representation of the Asset identifier is defined as + is the unique random element of the Pallas group 11 that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as \(\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})\) .
    diff --git a/zip-0226.rst b/zip-0226.rst index ead633cad..e4e67d9b6 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -92,7 +92,7 @@ Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, as . The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. +- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. From 2f7d9738bdb95698ba7fc3bc9b39ebc87fe26761 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 31 Jan 2023 11:39:08 +0530 Subject: [PATCH 063/101] minor edit --- zip-0226.html | 30 +++++++++++++++--------------- zip-0226.rst | 2 +- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 9fd070a5f..9e3512195 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -115,7 +115,7 @@
    • \(\mathsf{AssetId} : \mathbb{P*}\) - is the unique random element of the Pallas group 11 that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as + is the unique random element of the Pallas group 11 that identifies each Asset in the Orchard protocol, as defined in ZIP 227 5. The byte representation of the Asset identifier is defined as \(\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})\) .
    @@ -123,15 +123,15 @@ \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 14 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 13. 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 identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 14 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 13. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)
    -

    The nullifier is generated in the same manner as in the Orchard protocol 10.

    -

    The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext 7. It consists of

    +

    The nullifier is generated in the same manner as in the Orchard protocol 10.

    +

    The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext 7. It consists of

    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)

    Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 15 to perform the value commitment, with fixed base points +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 15 to perform the value commitment, with fixed base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) @@ -151,16 +151,16 @@ \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}\) , where the Asset identifier \(\mathsf{AssetId}\) - is computed as defined in ZIP 227 5, and

    + is computed as defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) , as in the Orchard protocol.

    We define \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

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

    +

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

    For a total of \(n\) Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key @@ -179,7 +179,7 @@

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -198,7 +198,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 17, except for a few additions that ensure the security of the Asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 17, except for a few additions that ensure the security of the Asset identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -206,12 +206,12 @@
  • The Asset identifier, \(\mathsf{AssetId}\) , for the note is witnessed once, as an auxiliary input.
    • -
  • In the Old note commitment integrity constraint in the Orchard Action statement 17, +
  • In the Old note commitment integrity constraint in the Orchard Action statement 17, \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, AssetId)}\) .
    • -
  • In the New note commitment integrity constraint in the Orchard Action statement 17, +
  • In the New note commitment integrity constraint in the Orchard Action statement 17, \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, AssetId)}\) @@ -370,7 +370,7 @@

    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.

    • ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    @@ -401,7 +401,7 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 21.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 21.

    Security and Privacy

      diff --git a/zip-0226.rst b/zip-0226.rst index e4e67d9b6..08c337dbd 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -92,7 +92,7 @@ Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. +- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, as defined in ZIP 227 [#zip-0227]_. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. From 4f074e9790d24b9dd5d35ab77ac394fb834d25b9 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 31 Jan 2023 12:08:21 +0530 Subject: [PATCH 064/101] edits based on review meeting --- zip-0226.html | 2 +- zip-0226.rst | 2 +- zip-0227.html | 28 ++++++++++++++-------------- zip-0227.rst | 26 +++++++++++++------------- 4 files changed, 29 insertions(+), 29 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 9e3512195..2a5eb7765 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -184,7 +184,7 @@

      In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

      This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

      Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before.

      -

      Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action:

      +

      Wallets and other clients have a choice to make to ensure the Asset identifier is preserved for the output note of a Split Action:

      1. The Split Input note could be another note of the same Asset identifier that is being spent by this transaction (but not by this Split Input).
      2. The Split Input note could be a different unspent note of the same diff --git a/zip-0226.rst b/zip-0226.rst index 08c337dbd..9431255d0 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -162,7 +162,7 @@ This creates a chain of induction that ensures that the value base points of all Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before. -Wallets and other clients have a choice to make to ensure the Asset type is preserved for the output note of a Split Action: +Wallets and other clients have a choice to make to ensure the Asset identifier is preserved for the output note of a Split Action: 1. The Split Input note could be another note of the same Asset identifier that is being spent by this transaction (but not by this Split Input). 2. The Split Input note could be a different unspent note of the same :math:`\mathsf{AssetId}` (note that the note will not actually be spent). diff --git a/zip-0227.html b/zip-0227.html index d1509f493..b7e20e8bd 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -59,7 +59,7 @@

        Specification

        As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

        Overview

        -

        This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset types, yet only a single issuer (a set of keys) can issue that specific Asset type, as the Asset identifiers are tied to the issuer keys.

        +

        This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset identifiers, yet only a single issuer (a set of keys) can issue that specific Asset identifer, as the Asset identifiers are tied to the issuer keys.

        The protocol was designed with three main properties in mind:

        • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
          • @@ -73,10 +73,10 @@
          1. The issuance authorizing key, denoted as \(\mathsf{isk}\) - , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer.
            2. + , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset identifier, and is only used by the issuer.
          2. The issuance validating key, denoted as \(\mathsf{ik}\) - , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.
            3. + , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.

          The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

            @@ -101,7 +101,7 @@ , is derived using an Asset identifier hash, \(\mathsf{AssetIdHash}\) that is defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve), and used within the output notes.

            -

            The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, +

            The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset identifier. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, \(\mathsf{AssetId}\) as follows:

            \(\mathsf{AssetId} = \mathsf{AssetIdHash(ik, asset\_desc)}\)
            @@ -278,7 +278,7 @@
            • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
                -
              • by setting finalize = 1 from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
                • +
              • by setting finalize = 1 from the first issuance action for that Asset identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
            • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by @@ -305,30 +305,30 @@
              • check that \(\mathsf{asset\_desc}\) - is a string with 0 < byte size <= 512
                • + is a string with 0 < byte size <= 512.
              • retrieve \(\mathsf{AssetId}\) from the first note in the sequence and check that \(\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}\) - is properly derived
                • + is properly derived.
              • check that the \(\mathsf{AssetId}\) - does not exist in the previously_finalized set in the global state
                • + does not exist in the previously_finalized set in the global state.
              • check that every note in the IssueAction contains the same \(\mathsf{AssetId}\) - and also that every note is of type Note and is properly constructed as + and is properly constructed as \(note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) -
                • + .

              If all of the above checks pass, do the following:

              • For each note, compute the note commitment as \(cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) and
                • -
              • add cm to the Merkle tree of note commitments, NoteCommitmentTree
                • +
              • add cm to the Merkle tree of note commitments, NoteCommitmentTree.
              • If finalize = 1, add \(\mathsf{AssetId}\) - to the previously_finalized set in the global state
                • + to the previously_finalized set in the global state.
        @@ -392,7 +392,7 @@

        UTF-8 encoding of the Asset description string.

    T.1c: isFinalized
    -

    1-bit representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    +

    1-bit representation of a boolean flag that is set to 'true' if the Asset identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    T.2 issuerVerificationKey

    @@ -416,7 +416,7 @@ \(\mathsf{AssetId}\) to \(\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}\) - in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    + in order to properly keep track of the total supply for different Asset identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    diff --git a/zip-0227.rst b/zip-0227.rst index 3262914a3..24de7bee6 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -70,7 +70,7 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset types, yet only a single issuer (a set of keys) can issue that specific Asset type, as the Asset identifiers are tied to the issuer keys. +This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset identifiers, yet only a single issuer (a set of keys) can issue that specific Asset identifer, as the Asset identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: @@ -85,9 +85,9 @@ Issuance Keys The ZSA Protocol adds the following two keys to the key components [#protocol-addressesandkeys]_: -1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset type, and is only used by the issuer. +1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset identifier, and is only used by the issuer. -2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset type, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. +2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. @@ -106,7 +106,7 @@ Asset Identifier For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived using an Asset identifier hash, :math:`\mathsf{AssetIdHash}` that is defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve), and used within the output notes. -The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset type. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, :math:`\mathsf{AssetId}` as follows: +The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset identifier. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, :math:`\mathsf{AssetId}` as follows: .. math:: \mathsf{AssetId} = \mathsf{AssetIdHash(ik, asset\_desc)} @@ -206,7 +206,7 @@ Issuers can wrap Assets defined in other chains and issue them at once in a sing - By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any Asset associated to their issuer keys. For example, - - by setting ``finalize = 1`` from the first issuance action for that Asset type, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + - by setting ``finalize = 1`` from the first issuance action for that Asset identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. - Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by @@ -224,16 +224,16 @@ For the IssueBundle: For each `IssueAction` in `IssueBundle`: -- check that :math:`\mathsf{asset\_desc}` is a string with `0 < byte size <= 512` -- retrieve :math:`\mathsf{AssetId}` from the first note in the sequence and check that :math:`\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}` is properly derived -- check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state -- check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetId}` and also that every note is of type `Note` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})` +- check that :math:`\mathsf{asset\_desc}` is a string with `0 < byte size <= 512`. +- retrieve :math:`\mathsf{AssetId}` from the first note in the sequence and check that :math:`\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}` is properly derived. +- check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state. +- check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetId}` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`. If all of the above checks pass, do the following: - For each note, compute the note commitment as :math:`cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` and -- add `cm` to the Merkle tree of note commitments, `NoteCommitmentTree` -- If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set in the global state +- add `cm` to the Merkle tree of note commitments, `NoteCommitmentTree`. +- If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set in the global state. Rationale @@ -315,7 +315,7 @@ UTF-8 encoding of the Asset description string. T.1c: isFinalized ''''''''''''''''' -1-bit representation of a boolean flag that is set to 'true' if the Asset type was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. +1-bit representation of a boolean flag that is set to 'true' if the Asset identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. T.2 issuerVerificationKey @@ -341,7 +341,7 @@ Other Considerations Implementing Zcash Nodes ------------------------ -Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset types. This is useful for wallets and other applications that need to keep track of the total supply of Assets. +Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets. Fee Structures -------------- From 61126211672f281e6ae18fbd15b1ec410e78c8f7 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 31 Jan 2023 12:55:09 +0530 Subject: [PATCH 065/101] editing Security and Privacy Considerations, and Fee Mechanism considerations --- zip-0226.html | 11 ++++++++--- zip-0226.rst | 9 ++++++--- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 2a5eb7765..d1f02c2a7 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -115,7 +115,7 @@
    • \(\mathsf{AssetId} : \mathbb{P*}\) - is the unique random element of the Pallas group 11 that identifies each Asset in the Orchard protocol, as defined in ZIP 227 5. The byte representation of the Asset identifier is defined as + is the unique element of the Pallas group 11 that identifies each Asset in the Orchard protocol, as defined in ZIP 227 5. The byte representation of the Asset identifier is defined as \(\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})\) .
    @@ -401,13 +401,18 @@

    Other Considerations

    Transaction Fees

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 21.

    +

    The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the ZSA protocol upgrade 21.

    Security and Privacy

    • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design.
    • We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state.
      • +
    • Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets. +
        +
      • One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
        • +
      +

    Deployment

    @@ -590,7 +595,7 @@
    - +
    21ZIP 317b: ZSA Extension Proportional Fee MechanismZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs
    diff --git a/zip-0226.rst b/zip-0226.rst index 9431255d0..ff3552175 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -92,7 +92,7 @@ Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, where -- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique random element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, as defined in ZIP 227 [#zip-0227]_. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. +- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, as defined in ZIP 227 [#zip-0227]_. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. @@ -267,7 +267,7 @@ Other Considerations Transaction Fees ---------------- -The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b [#zip-0317b]_. +The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the ZSA protocol upgrade [#zip-0317b]_. Security and Privacy -------------------- @@ -275,6 +275,9 @@ Security and Privacy - Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. - When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design. - We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state. +- Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets. + + - One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients. Deployment ----------- @@ -314,4 +317,4 @@ References .. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ .. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ .. [#generalized-value-commitments] `Comment on Generalized Value Commitments `_ -.. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ \ No newline at end of file +.. [#zip-0317b] `ZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs `_ \ No newline at end of file From 619943fd567172650e672f6df3b68bc6d4bde590 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 1 Feb 2023 18:05:40 +0530 Subject: [PATCH 066/101] Including Asset Base and redefining Asset Identifier throughout the ZIPs --- zip-0226.html | 240 ++++++++++++++++++++++++-------------------------- zip-0226.rst | 125 +++++++++++++------------- zip-0227.html | 83 +++++++++-------- zip-0227.rst | 54 ++++++------ 4 files changed, 250 insertions(+), 252 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index d1f02c2a7..245e40c59 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -51,33 +51,35 @@

    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.

    Overview

    -

    In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field in a note that uniquely represents the identifier of the Asset in question, which we call - \(\mathsf{AssetId^{Orchard}}\) - .

    -

    The Asset identifier will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 9), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    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 + \(\mathsf{AssetId}\) + . This Asset Identifier is stored in Orchard-based ZSA notes as an Asset Base + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + . These terms are formally defined in ZIP 227 5.

    +

    The Asset Identifier (via means of the Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 9), 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}-value^{new}}\) - , must be balanced only with respect to the same Asset identifier. This is specially 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 19 20, we propose to make this happen by changing the value base point, + , must be balanced only with respect to the same Asset Identifier. This is specially 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 19 20, 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 in the transaction. We propose to make the - \(\mathsf{AssetId}\) - identifier an auxiliary input to the proof for each Action statement 17, represented already as a point on the Pallas curve. The circuit then should check that the same - \(\mathsf{AssetId}\) - is used in the old note commitment and the new note commitment 14, and as the base point +

    Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset Identifiers in the transaction. We propose to make the Asset Base + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + an auxiliary input to the proof for each Action statement 17, represented already as a point on the Pallas curve. The circuit then should check that the same + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + is used in the old note commitment and the new note commitment 14, and as the base point \(\mathcal{V}^\mathsf{Orchard}\) - in the value commitment 15. This ensures (1) that the input and output notes are of the same - \(\mathsf{AssetId}\) - , and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures.

    -

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 16 for Custom Assets, as we need to enforce that the - \(\mathsf{AssetId}\) + in the value commitment 15. This ensures (1) that the input and output notes are of the same + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + , and (2) that only actions with the same Asset Base will balance out in the binding and balance signatures.

    +

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 16 for Custom Assets, as we need to enforce that the + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) of the output note of that split Action is the output of a valid - \(\mathsf{AssetIdHash}\) - computation defined in ZIP 227 5.

    + \(\mathsf{ZSAValueBase^{Orchard}}\) + computation defined in ZIP 227 5.

    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 \(\mathsf{valueBalance}\) of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets.

    @@ -85,21 +87,23 @@

    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 identifier of the Asset. Every Asset is defined by the 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 the specific Asset identifier, + , 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, \(\mathsf{AssetId}\) - , is derived as defined in ZIP 227 5.

    + and the Asset Base ( + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + for the Orchard-based ZSA protocol) are derived as defined in ZIP 227 5.

    This - \(\mathsf{AssetId}\) - will be the base point of the value commitment for the specific custom Asset. Note that the - \(\mathsf{AssetId}\) + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + will be the base point of the value commitment for the specific Custom Asset. Note that the + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) of the ZEC Asset will be kept as the original value base point, \(\mathcal{V}^\mathsf{Orchard}\) .

    -

    In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset identifier, +

    In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset Identifier, \(\mathsf{AssetId}\) - , from one shielded protocol to another.

    + and the Asset Base from one shielded protocol to another.

    Note Structure & Commitment

    Let @@ -107,60 +111,58 @@ be the type of a ZSA note, i.e. \(\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}\) .

    -

    A ZSA note differs from an Orchard note 6 by additionally including the identifier of the Asset, - \(\mathsf{AssetId}\) +

    A ZSA note differs from an Orchard note 6 by additionally including the Asset Base, + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) . So a ZSA note is a tuple - \((\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) + \((\mathsf{g_d, pk_d, v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}}})\) , where

    • - \(\mathsf{AssetId} : \mathbb{P*}\) - is the unique element of the Pallas group 11 that identifies each Asset in the Orchard protocol, as defined in ZIP 227 5. The byte representation of the Asset identifier is defined as - \(\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})\) + \(\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P*}\) + is the unique element of the Pallas group 11 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 5. The byte representation of the Asset Base is defined as + \(\mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})\) .

    In this case, the instance of the note commitment scheme, \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) , will differ from \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 14 allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 13. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    -
    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output}\)
    -

    The nullifier is generated in the same manner as in the Orchard protocol 10.

    -

    The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext 7. It consists of

    -
    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)
    + in that for Custom Assets, the Asset Base will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 14 allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 13. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    +
    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output}\)
    +

    The nullifier is generated in the same manner as in the Orchard protocol 10.

    +

    The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 7. It consists of

    +
    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)

    Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 15 to perform the value commitment, with fixed base points +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 15 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.

    -

    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. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes

    -
    \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)
    +

    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. This enables the final balance of the transaction to be securely computed, such that each Asset Identifier is balanced independently, as different Assets are not meant to be mutually fungible. The value commitment then becomes

    +
    \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}} + [\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    where \(\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}\) such that \(\mathsf{v^{old}_{AssetId}}\) and \(\mathsf{v^{new}_{AssetId}}\) - are the values of the old and new notes of identifier + are the values of the old and new notes of Asset Identifier \(\mathsf{AssetId}\) respectively,

    - \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}\) - , where the Asset identifier - \(\mathsf{AssetId}\) - is computed as defined in ZIP 227 5, and

    + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) + is defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) , as in the Orchard protocol.

    We define - \(\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

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

    +

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

    For a total of \(n\) Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key @@ -170,63 +172,59 @@

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} = \sum \mathsf{rcv_{i}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    and use it to verify the bindingSignature on the SIGHASH message.

    Rationale for Value Balance Verification

    -

    The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, +

    The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset of value balance published, that of ZEC, \(\mathsf{v^{balanceOrchard}}\) - . No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    + . No net amount of any other Asset will be revealed, and the number of Assets in the transaction is also hidden. The only exception to this is in the case that an Asset is burnt, as we will see below in the burn mechanism.

    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 only sum to zero per Asset identifier, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

    + , 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

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    -

    This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions cannot be of any Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    -

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    This, however, brings some issues when it comes to adding multiple Asset Identifiers, as the output note of the split Actions cannot contain any Asset Base, but it must be enforced 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). If not, then the prover could essentially input a multiple (or linear combination) of an existing Asset Base, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    +

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before.

    -

    Wallets and other clients have a choice to make to ensure the Asset identifier is preserved for the output note of a Split Action:

    +

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

      -
    1. The Split Input note could be another note of the same Asset identifier that is being spent by this transaction (but not by this Split Input).
      2. -
    2. The Split Input note could be a different unspent note of the same - \(\mathsf{AssetId}\) - (note that the note will not actually be spent).
      3. -
    3. The Split Input note could be an already spent note of the same - \(\mathsf{AssetId}\) - (note that by zeroing the value in the circuit, we prevent double spending).
      4. +
    4. 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).
      5. +
    5. The Split Input note could be a different unspent note containing the same Asset Base (note that the note will not actually be spent).
      6. +
    6. 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).

    The specific circuit changes are presented below.

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 17, except for a few additions that ensure the security of the Asset identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 17, except for a few additions that ensure the security of the Asset Identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

      -
    • The Asset identifier, - \(\mathsf{AssetId}\) +
    • The Asset Base, + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) , for the note is witnessed once, as an auxiliary input.
      • -
    • In the Old note commitment integrity constraint in the Orchard Action statement 17, +
    • In the Old note commitment integrity constraint in the Orchard Action statement 17, \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) is replaced with - \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, AssetId)}\) + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) .
      • -
    • In the New note commitment integrity constraint in the Orchard Action statement 17, +
    • In the New note commitment integrity constraint in the Orchard Action statement 17, \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) is replaced with - \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, AssetId)}\) + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) .
    -

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset identifier, as represented in the notes:

    +

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base, as represented in the notes:

    • The fixed-base multiplication constraints 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 value base equation is the auxiliary input - \(\mathsf{AssetId}\) + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) .
    -

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the Asset identifier for the output note in a Split Action:

    +

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the Asset Base for the output note in a Split Action:

    • @@ -236,7 +234,7 @@
    • Replace the input note value by a generic value, \(\mathsf{v}'\) , as - \(\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, AssetId)}\) + \(\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\)
    @@ -298,47 +296,39 @@

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

    +

    The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases:

    • -
      The input note in the old note commitment integrity must either include an Asset identifier (ZSA note) or not (ZEC-Orchard note)
      +
      If the Asset Base auxiliary input present but set to + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + = + \(\mathcal{V}^\mathsf{Orchard}\) +
        -
      • -
        -
        If the Asset identifier auxiliary input is set - \(\mathsf{AssetId}\) - = - \(\mathcal{V}^\mathsf{Orchard}\) -
        -
        -
          -
        • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the identifier)
          • -
        • This path also uses the original domain separator for ZEC note commitment
          • -
        -
        -
        -
        • -
      • -
        -
        Else,
        -
        -
          -
        • The NoteCommitment adds the identfier, - \(\mathsf{AssetId}\) - , as a final “chunk” of the Sinsemilla commitment
          • -
        • The NoteCommitment uses a different domain separator for ZSA note commitment
          • -
        -
        -
        -
        • +
      • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the Asset Base)
        • +
      • This path also uses the original domain separator for ZEC note commitment
        • +
      +
      +
      +
      • +
    • +
      +
      Else,
      +
      +
        +
      • The note commitment adds the identfier, + \(\mathsf{AssetId}\) + , as a final “chunk” of the Sinsemilla commitment
        • +
      • The note commitment uses a different domain separator for ZSA note commitment

    Backward Compatibility

    -

    In order to have a "clean" backwards 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: - The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree - 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.

    +

    In order to have a "clean" backwards 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: - The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree - 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.

    Burn Mechanism

    @@ -346,7 +336,7 @@

    In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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.

    First, contrary to the strict transfer transaction, we allow the sender to include a \(\mathsf{valueBalance_{AssetId}}\) - variable for every Asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular + variable for every Asset Identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular \(\mathsf{valueBalance^Orchard}\) that is the default transparent value for the ZEC Asset. We require that for every \(\mathsf{valueBalance_{AssetId}}\) @@ -355,22 +345,22 @@ . This is enforced via a consensus rule.

    For every custom Asset that is burnt, we add to the assetBurn vector the tuple \((\mathsf{valueBalance_{AssetId}, 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.

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

    \(\mathsf{assetBurn = \{ (v^{AssetId}, AssetId)}\ |\ \forall\ \mathsf{AssetId}\ \textit{s.t.}\ \mathsf{v^{AssetId}} \neq 0 \}\)

    -

    The value balances for each Asset identifier in assetBurn represents the amount of that Asset identifier 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 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).

    Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective \(\mathsf{AssetId}\) as the value base point of the Pedersen Commitment. This is done as follows

    \(\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{OrchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}\)

    -

    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 identifiers, will be revealed, except in the case that an Asset is burnt.

    -

    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.

    +

    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.

    +

    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.

    ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    @@ -401,16 +391,16 @@

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

    +

    The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the ZSA protocol upgrade 21.

    Security and Privacy

    • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design.
      • -
    • We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state.
      • +
    • We prevent the "roadblock" attack on the Asset Identifer by ensuring the output notes receive an Asset Base that exists on the global state.
    • Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets.
        -
      • One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
        • +
      • One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
    @@ -475,7 +465,7 @@
    - +
    6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: NotesZcash Protocol Specification, Version 2022.3.8. Section 3.2: Notes
    @@ -483,7 +473,7 @@ 7 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.5: Encodings of Note Plaintexts and Memo Fields + Zcash Protocol Specification, Version 2022.3.8. Section 5.5: Encodings of Note Plaintexts and Memo Fields @@ -491,7 +481,7 @@ 8 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions + Zcash Protocol Specification, Version 2022.3.8. Section 3.7: Action Transfers and their Descriptions @@ -499,7 +489,7 @@ 9 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) + Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard) @@ -507,7 +497,7 @@ 10 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.16: Note Commitments and Nullifiers + Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers @@ -515,7 +505,7 @@ 11 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta + Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta @@ -531,7 +521,7 @@ 13 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla hash function + Zcash Protocol Specification, Version 2022.3.8. Section 5.4.1.9: Sinsemilla hash function @@ -539,7 +529,7 @@ 14 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments + Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments @@ -547,7 +537,7 @@ 15 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) + Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) @@ -555,7 +545,7 @@ 16 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) + Zcash Protocol Specification, Version 2022.3.8. Section 4.8.3: Dummy Notes (Orchard) @@ -563,7 +553,7 @@ 17 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) + Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard) @@ -571,7 +561,7 @@ 18 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. 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) diff --git a/zip-0226.rst b/zip-0226.rst index ff3552175..f2e3d89d6 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -57,15 +57,17 @@ issuance and bridging purposes. Overview ======== -In order to be able to represent different Asset identifiers in Orchard, we need to define a new data field in a note that uniquely represents the identifier of the Asset in question, which we call :math:`\mathsf{AssetId^{Orchard}}`. +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 :math:`\mathsf{AssetId}`. +This Asset Identifier is stored in Orchard-based ZSA notes as an Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`. +These terms are formally defined in ZIP 227 [#zip-0227]_. -The Asset identifier will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset identifier**. This is specially 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. +The Asset Identifier (via means of the Asset Base) will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset Identifier**. This is specially 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 [#initial-zsa-issue]_ [#generalized-value-commitments]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that derives the value commitment, :math:`\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 in the transaction. We propose to make the :math:`\mathsf{AssetId}` identifier an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetId}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetId}`, and (2) that only actions with the same Asset identifier will balance out in the binding and balance signatures. +Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset Identifiers in the transaction. We propose to make the Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`, and (2) that only actions with the same Asset Base will balance out in the binding and balance signatures. -In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes [#protocol-dummynotes]_ for Custom Assets, as we need to enforce that the :math:`\mathsf{AssetId}` of the output note of that split Action is the output of a valid :math:`\mathsf{AssetIdHash}` computation defined in ZIP 227 [#zip-0227]_. +In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes [#protocol-dummynotes]_ for Custom Assets, as we need to enforce that the :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` of the output note of that split Action is the output of a valid :math:`\mathsf{ZSAValueBase^{Orchard}}` computation defined in ZIP 227 [#zip-0227]_. 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 :math:`\mathsf{valueBalance}` of the Asset in question. Burning Assets is useful for many purposes, including bridging of Wrapped Assets and removing supply of Assets. @@ -77,11 +79,11 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived as defined in ZIP 227 [#zip-0227]_. +For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{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, :math:`\mathsf{AssetId}` and the Asset Base (:math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` for the Orchard-based ZSA protocol) are derived as defined in ZIP 227 [#zip-0227]_. -This :math:`\mathsf{AssetId}` will be the base point of the value commitment for the specific custom Asset. Note that the :math:`\mathsf{AssetId}` of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`. +This :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` will be the base point of the value commitment for the specific Custom Asset. Note that the :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`. -In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset identifier, :math:`\mathsf{AssetId}`, from one shielded protocol to another. +In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset Identifier, :math:`\mathsf{AssetId}` and the Asset Base from one shielded protocol to another. Note Structure & Commitment --------------------------- @@ -89,42 +91,42 @@ Note Structure & Commitment Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e. :math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P*}`. -A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the identifier of the Asset, :math:`\mathsf{AssetId}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`, +A ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the Asset Base, :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}}})`, where -- :math:`\mathsf{AssetId} : \mathbb{P*}` is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, as defined in ZIP 227 [#zip-0227]_. The byte representation of the Asset identifier is defined as :math:`\mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetId})`. +- :math:`\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P*}` is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 [#zip-0227]_. The byte representation of the Asset Base is defined as :math:`\mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})`. -In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset identifier will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset identifier as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. +In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset Base will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function [#protocol-concretesinsemillahash]_. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have: -.. math:: \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)} \in \mathsf{NoteCommit^{Orchard}.Output} +.. math:: \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output} The nullifier is generated in the same manner as in the Orchard protocol [#protocol-commitmentsandnullifiers]_. -The ZSA note plaintext also includes the Asset identifier in addition to the components in the Orchard note plaintext [#protocol-notept]_. +The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext [#protocol-notept]_. It consists of -.. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{assetID} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]}) +.. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]}) Value Commitment ---------------- The Orchard Protocol uses a Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, with fixed base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and :math:`\mathcal{R}^{\mathsf{Orchard}}` as the values represent the amount of ZEC being transferred. -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**. This enables the final balance of the transaction to be securely computed, such that each Asset identifier is balanced independently, as Assets with different identifiers are not meant to be mutually fungible. The value commitment then becomes +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**. This enables the final balance of the transaction to be securely computed, such that each Asset Identifier is balanced independently, as different Assets are not meant to be mutually fungible. The value commitment then becomes -.. math:: \mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId},\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}+[\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} +.. math:: \mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}} + [\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} -where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^{old}_{AssetId}}` and :math:`\mathsf{v^{new}_{AssetId}}` are the values of the old and new notes of identifier :math:`\mathsf{AssetId}` respectively, +where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}` such that :math:`\mathsf{v^{old}_{AssetId}}` and :math:`\mathsf{v^{new}_{AssetId}}` are the values of the old and new notes of Asset Identifier :math:`\mathsf{AssetId}` respectively, .. _`value base`: -:math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{AssetId}}:=\mathsf{AssetId}`, where the Asset identifier :math:`\mathsf{AssetId}` is computed as defined in ZIP 227 [#zip-0227]_, and +:math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` is defined in ZIP 227 [#zip-0227]_, and :math:`\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}`, as in the Orchard protocol. -We define :math:`\mathcal{V}^{\mathsf{OrchardZSA}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}` so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 [#zip-0224]_. +We define :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}` so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 [#zip-0224]_. Value Balance Verification -------------------------- @@ -143,9 +145,9 @@ and use it to verify the `bindingSignature` on the `SIGHASH` message. Rationale for Value Balance Verification '''''''''''''''''''''''''''''''''''''''' -The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset identifier of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset identifier will be revealed, and the number of Asset identifiers in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. +The main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so 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 Asset of value balance published, that of ZEC, :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset will be revealed, and the number of Assets in the transaction is also hidden. The only exception to this is in the case that an Asset is *burnt*, as we will see below in the `burn mechanism`_. -As in the Orchard protocol, the binding signature verification key, :math:`\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 only sum to zero **per Asset identifier**, as the Pedersen commitments add up homomorphically only with respect to the same value base point. +As in the Orchard protocol, the binding signature verification key, :math:`\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 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 @@ -153,44 +155,44 @@ Split Notes One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given *dummy spend notes* [#protocol-dummynotes]_, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the *real* spend note. -This, however, brings some issues when it comes to adding multiple Asset identifiers, as the output note of the split Actions *cannot* be of *any* Asset identifier, it must be enforced to be an actual output of a GroupHash computation (in fact we want it to be of the same identifier as the original input note, but the binding signature takes care that the proper balancing is performed). If not, then the prover could essentially input a multiple (or linear combination) of an existing identifier, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. +This, however, brings some issues when it comes to adding multiple Asset Identifiers, as the output note of the split Actions *cannot* contain *any* Asset Base, but it must be enforced 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). If not, then the prover could essentially input a multiple (or linear combination) of an existing Asset Base, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds. In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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 identifier as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof. +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. This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets. Note that we do not care about whether the note identified by a Split Input is owned by the sender, or whether it was nullified before. -Wallets and other clients have a choice to make to ensure the Asset identifier is preserved for the output note of a Split Action: +Wallets and other clients have a choice to make to ensure the Asset Base is preserved for the output note of a Split Action: -1. The Split Input note could be another note of the same Asset identifier that is being spent by this transaction (but not by this Split Input). -2. The Split Input note could be a different unspent note of the same :math:`\mathsf{AssetId}` (note that the note will not actually be spent). -3. The Split Input note could be an already spent note of the same :math:`\mathsf{AssetId}` (note that by zeroing the value in the circuit, we prevent double spending). +1. 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). +2. The Split Input note could be a different unspent note containing the same Asset Base (note that the note will not actually be spent). +3. 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). The specific circuit changes are presented below. Circuit Statement ================= -The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset identifier system. +The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset Identifier system. **Asset Identifier Equality:** the following constraints must be added to ensure that the input and output note are of the same :math:`\mathsf{AssetId}`: -- The Asset identifier, :math:`\mathsf{AssetId}`, for the note is witnessed once, as an auxiliary input. -- In the Old note commitment integrity constraint in the Orchard Action statement [#protocol-actionstatement]_, :math:`\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}` is replaced with :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, AssetId)}`. -- In the New note commitment integrity constraint in the Orchard Action statement [#protocol-actionstatement]_, :math:`\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}` is replaced with :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, AssetId)}`. +- The Asset Base, :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}`, for the note is witnessed once, as an auxiliary input. +- In the Old note commitment integrity constraint in the Orchard Action statement [#protocol-actionstatement]_, :math:`\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}` is replaced with :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}`. +- In the New note commitment integrity constraint in the Orchard Action statement [#protocol-actionstatement]_, :math:`\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}` is replaced with :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}`. -**Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset identifier, as represented in the notes: +**Correct Value Commitment:** the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base, as represented in the notes: - The fixed-base multiplication constraints between the value and the value base point of the value commitment, :math:`\mathsf{cv}`, is replaced with a variable-base multiplication between the two. -- The witness to the value base point, as defined in the `value base`_ equation is the auxiliary input :math:`\mathsf{AssetId}`. +- The witness to the value base point, as defined in the `value base`_ equation is the auxiliary input :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}`. -**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the Asset identifier for the output note in a Split Action: +**Enforce Secure Identifier for Split Actions:** the following constraints must be added to prevent senders from changing the Asset Base for the output note in a Split Action: - The Value Commitment Integrity should be changed - - Replace the input note value by a generic value, :math:`\mathsf{v}'`, as :math:`\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, AssetId)}` + - Replace the input note value by a generic value, :math:`\mathsf{v}'`, as :math:`\mathsf{cv^{net}} = \mathsf{ValueCommit_rcv^{OrchardZSA}(v’ - v^new, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}` - Add a boolean ``split`` variable as an auxiliary witness. This variable is to be activated ``split = 1`` if the Action in question is a split and ``split = 0`` if the Action is actually spending an input note: - If ``split = 1`` then set :math:`\mathsf{v}' = 0` otherwise :math:`\mathsf{v}'=\mathsf{v^{old}}` from the auxiliary input. - The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes): @@ -203,20 +205,21 @@ the input and output note are of the same :math:`\mathsf{AssetId}`: The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. -- The input note in the old note commitment integrity must either include an Asset identifier (ZSA note) or not (ZEC-Orchard note) - - If the Asset identifier auxiliary input is set :math:`\mathsf{AssetId}` = :math:`\mathcal{V}^\mathsf{Orchard}` - - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the identifier) - - This path also uses the original domain separator for ZEC note commitment - - Else, - - The NoteCommitment adds the identfier, :math:`\mathsf{AssetId}`, as a final “chunk” of the Sinsemilla commitment - - The NoteCommitment uses a different domain separator for ZSA note commitment +The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases: + +- If the Asset Base auxiliary input present but set to :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` = :math:`\mathcal{V}^\mathsf{Orchard}` + - NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the Asset Base) + - This path also uses the original domain separator for ZEC note commitment +- Else, + - The note commitment adds the identfier, :math:`\mathsf{AssetId}`, as a final “chunk” of the Sinsemilla commitment + - The note commitment uses a different domain separator for ZSA note commitment Backward Compatibility ---------------------- In order to have a "clean" backwards 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: -- The input notes with an Asset identifer denote the custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an identifier, denote the ZEC notes, and generate a note commitment that does not include the Asset identifier, in order to maintain the referencability to the Merkle tree +- The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree - 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. @@ -227,23 +230,23 @@ The burn mechanism may be needed for off-boarding the Wrapped Assets from the ch In essence, the burn mechanism is a transparent / revealing extension to the transfer protocol that enables a specific amount of any Asset identifier to be sent into “oblivion”. Our burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given 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. -First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{AssetId}}` variable for every Asset identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC Asset. +First, contrary to the strict transfer transaction, we allow the sender to include a :math:`\mathsf{valueBalance_{AssetId}}` variable for every Asset Identifier that is being burnt. As we will show in the transaction structure, this is separate from the regular :math:`\mathsf{valueBalance^Orchard}` that is the default transparent value for the ZEC Asset. We require that for every :math:`\mathsf{valueBalance_{AssetId}}` provided as above by the sender, :math:`\mathsf{valueBalance_{AssetId}} \neq 0`. This is enforced via a consensus rule. -For every custom Asset that is burnt, we add to the `assetBurn` vector the tuple :math:`(\mathsf{valueBalance_{AssetId}, 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. +For every custom Asset that is burnt, we add to the `assetBurn` vector the tuple :math:`(\mathsf{valueBalance_{AssetId}, 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. :math:`\mathsf{assetBurn = \{ (v^{AssetId}, AssetId)}\ |\ \forall\ \mathsf{AssetId}\ \textit{s.t.}\ \mathsf{v^{AssetId}} \neq 0 \}` -The value balances for each Asset identifier in `assetBurn` represents the amount of that Asset identifier 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 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). Finally, the validator needs to verify the Balance and Binding Signature by adding the value balances for all Assets, as committed using their respective :math:`\mathsf{AssetId}` as the value base point of the Pedersen Commitment. This is done as follows :math:`\mathsf{bvk = (\sum cv_i^{net})} - \mathsf{ ValueCommit_0^{Orchard}(v^{balanceOrchard})} - \sum_{\forall \mathsf{AssetId}\textit{ s.t. }\mathsf{v^{AssetId}\neq 0}} \mathsf{ValueCommit_0^{OrchardZSA}(v^{AssetId}, AssetId) } = \sum \mathsf{rcv_{i,j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` -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 identifiers, will be revealed, except in the case that an Asset is burnt. +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. -**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. +**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. ZSA Transaction Structure ========================= @@ -274,10 +277,10 @@ Security and Privacy - Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. - When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design. -- We prevent the "roadblock" attack on the Asset identifer by ensuring the output notes receive an Asset identifier that exists on the global state. +- We prevent the "roadblock" attack on the Asset Identifer by ensuring the output notes receive an Asset Base that exists on the global state. - Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets. - - One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients. + - One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients. Deployment ----------- @@ -302,19 +305,19 @@ References .. [#zip-0224] `ZIP 224: Orchard `_ .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ -.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes `_ -.. [#protocol-notept] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ -.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#protocol-binding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.14: Balance and Binding Signature (Orchard) `_ -.. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.16: Note Commitments and Nullifiers `_ -.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#protocol-notes] `Zcash Protocol Specification, Version 2022.3.8. Section 3.2: Notes `_ +.. [#protocol-notept] `Zcash Protocol Specification, Version 2022.3.8. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ +.. [#protocol-actions] `Zcash Protocol Specification, Version 2022.3.8. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-binding] `Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta `_ .. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ -.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla hash function `_ -.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments `_ -.. [#protocol-concretevaluecommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ -.. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.8.3: Dummy Notes (Orchard) `_ -.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ -.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ +.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.1.9: Sinsemilla hash function `_ +.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments `_ +.. [#protocol-concretevaluecommit] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ +.. [#protocol-dummynotes] `Zcash Protocol Specification, Version 2022.3.8. Section 4.8.3: Dummy Notes (Orchard) `_ +.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard) `_ +.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ .. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ .. [#generalized-value-commitments] `Comment on Generalized Value Commitments `_ .. [#zip-0317b] `ZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs `_ \ No newline at end of file diff --git a/zip-0227.html b/zip-0227.html index b7e20e8bd..be4167654 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -27,7 +27,7 @@

    The terms "Asset", "custom Asset", and "Wrapped Asset" in this document are to be interpreted as described in ZIP 226 4.

    We define the following additional terms:

      -
    • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset identifier.
      • +
    • Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset Identifier.
    • Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.
    @@ -52,19 +52,19 @@
  • Any user of the Zcash block chain can issue custom Assets on chain.
  • The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain.
  • Issuing or changing the attributes of a specific Asset should require cryptographic authorization.
    • -
  • The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset identifier.
    • +
  • The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset Identifier.
  • An issuer should be able to issue different Assets in the same transaction.

    • Specification

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    Overview

    -

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset identifiers, yet only a single issuer (a set of keys) can issue that specific Asset identifer, as the Asset identifiers are tied to the issuer keys.

    +

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifer, as the Asset Identifiers are tied to the issuer keys.

    The protocol was designed with three main properties in mind:

    • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
      • -
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom Assets.
      • -
    • Every issuance action contains the finalize boolean that defines whether that specific custom Asset can have further tokens issued or not.
      • +
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple Custom Assets.
      • +
    • Every issuance action contains the finalize boolean that defines whether that specific Custom Asset can have further tokens issued or not.

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    @@ -73,10 +73,10 @@
    1. The issuance authorizing key, denoted as \(\mathsf{isk}\) - , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset identifier, and is only used by the issuer.
      2. + , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset Identifier, and is only used by the issuer.
    2. The issuance validating key, denoted as \(\mathsf{ik}\) - , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.
      3. + , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

      @@ -94,31 +94,38 @@

      This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    -

    For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, +

    For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair + \((\mathsf{ik}, \mathsf{asset\_desc})\) + , where + \(\mathsf{ik}\) + is the issuance key and \(\mathsf{asset\_desc}\) - , which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, - \(\mathsf{AssetId}\) - , is derived using an Asset identifier hash, - \(\mathsf{AssetIdHash}\) - that is defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve), and used within the output notes.

    -

    The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset identifier. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, - \(\mathsf{AssetId}\) - as follows:

    -
    \(\mathsf{AssetId} = \mathsf{AssetIdHash(ik, asset\_desc)}\)
    -

    where

    + is a byte string.

    +

    A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive a specific Asset Base within each such shielded protocol (for example + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) + for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.

    +

    Let

    • \(\mathsf{asset\_desc}\) - is the Asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance.
      • + be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance.
    • \(\mathsf{ik}\) - is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above.
      • + be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH. +
    +

    Define + \(\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))\) + , where

    +
      +
    • + \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := [0x00, \mathsf{length}(\mathsf{ik})] || \mathsf{ik} || \mathsf{asset\_desc}\!\) + .
    -

    In the case of the Orchard protocol, we define

    -
    \(\mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)}\)
    -

    where - \(\mathsf{GroupHash^{\mathbb{P}}}\) - is the Group Hash into the group of points on the Pallas curve defined in the protocol specification 10.

    +

    In the case of Orchard, we define + \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) + where + \(\mathsf{GroupHash}^\mathbb{P}\) + is defined as in 10.

    Global Issuance State

    Issuance requires the following additions to the global state:

    @@ -241,18 +248,16 @@ \(\mathsf{asset\_desc}\) as 512 byte-string.
  • compute - \(\mathsf{AssetId}\) - as - \(\mathsf{AssetIdHash(ik, asset\_desc)}\) + \(\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))\)
    • -
  • set the finalize boolean as desired (if more more issuance actions are to be created for this Asset identifier, set finalize = 0, otherwise set finalize = 1)
    • +
  • set the finalize boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set finalize = 0, otherwise set finalize = 1)
  • For each recipient \(i\) :
      -
    • generate a ZSA output note as - \(\mathsf{note}_i =(\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetId}, \mathsf{rcm}_i)\) -
      • +
    • generate a ZSA output note that includes the Asset Base. For an Orchard-based ZSA note this is + \(\mathsf{note}_i = (\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetBase^{Orchard}}, \mathsf{rcm}_i)\!\) + .
  • encode the IssueAction into the vector vIssueActions of the bundle
    • @@ -278,7 +283,7 @@
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
        -
      • by setting finalize = 1 from the first issuance action for that Asset identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • +
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
    • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by @@ -392,7 +397,7 @@

      UTF-8 encoding of the Asset description string.

    T.1c: isFinalized
    -

    1-bit representation of a boolean flag that is set to 'true' if the Asset identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    +

    1-bit representation of a boolean flag that is set to 'true' if the Asset Identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    T.2 issuerVerificationKey

    @@ -416,7 +421,7 @@ \(\mathsf{AssetId}\) to \(\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}\) - in order to properly keep track of the total supply for different Asset identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    + in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    @@ -424,7 +429,7 @@

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying \(\mathsf{ik}\) - of a given Asset, in case the original one was compromised, without having to change the Asset identifier altogether.

    + of a given Asset, in case the original one was compromised, without having to change the Asset Identifier altogether.

    Test Vectors

    @@ -510,7 +515,7 @@ 9 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys + Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys @@ -518,7 +523,7 @@ 10 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta + Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta @@ -526,7 +531,7 @@ 11 - Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. 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) diff --git a/zip-0227.rst b/zip-0227.rst index 24de7bee6..45e5edcf4 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -27,7 +27,7 @@ The terms "Asset", "custom Asset", and "Wrapped Asset" in this document are to b We define the following additional terms: -- Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset identifier. +- Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset Identifier. - Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction. Abstract @@ -58,7 +58,7 @@ Requirements - Any user of the Zcash block chain can issue custom Assets on chain. - The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain. - Issuing or changing the attributes of a specific Asset should require cryptographic authorization. -- The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset identifier. +- The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset Identifier. - An issuer should be able to issue different Assets in the same transaction. @@ -70,13 +70,13 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset identifiers, yet only a single issuer (a set of keys) can issue that specific Asset identifer, as the Asset identifiers are tied to the issuer keys. +This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifer, as the Asset Identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: - At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. -- In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple custom Assets. -- Every issuance action contains the ``finalize`` boolean that defines whether that specific custom Asset can have further tokens issued or not. +- In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple Custom Assets. +- Every issuance action contains the ``finalize`` boolean that defines whether that specific Custom Asset can have further tokens issued or not. The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. @@ -85,9 +85,9 @@ Issuance Keys The ZSA Protocol adds the following two keys to the key components [#protocol-addressesandkeys]_: -1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset identifier, and is only used by the issuer. +1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset Identifier, and is only used by the issuer. -2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. +2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. @@ -104,22 +104,22 @@ This allows the issuer to use the same wallet it usually uses to transfer Assets Asset Identifier ---------------- -For every new Asset, there must be a new and unique identifier of the Asset. Every Asset is defined by the Asset description, :math:`\mathsf{asset\_desc}`, which is a global byte string (valid across all -future- Zcash shielded protocols). From this Asset description, the specific Asset identifier, :math:`\mathsf{AssetId}`, is derived using an Asset identifier hash, :math:`\mathsf{AssetIdHash}` that is defined by the specific protocol (e.g. for now Orchard-style, using Pallas curve), and used within the output notes. +For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair :math:`(\mathsf{ik}, \mathsf{asset\_desc})`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string. -The main requirement for the Asset identifier is for it to be collision-free, as two different issuers MUST not be able to issue the same Asset identifier. One way to achieve this is to make the identifier dependent on the issuer keys, as the issuer keys are unique to each issuer. We achieve this by deriving the Asset identifier, :math:`\mathsf{AssetId}` as follows: +A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive a specific Asset Base within each such shielded protocol (for example :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes. -.. math:: \mathsf{AssetId} = \mathsf{AssetIdHash(ik, asset\_desc)} +Let -where - -- :math:`\mathsf{asset\_desc}` is the Asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. -- :math:`\mathsf{ik}` is the issuance validating key of the issuer, used to verify the signature on the transaction SIGHASH and is defined above. +- :math:`\mathsf{asset\_desc}` be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. +- :math:`\mathsf{ik}` be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH. -In the case of the Orchard protocol, we define +Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`, +where -.. math:: \mathsf{AssetIdHash^{Orchard}(ik, asset\_desc)} := \mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv",} \mathsf{ik}\texttt{||}\mathsf{asset\_desc} \texttt{)} +- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := [0x00, \mathsf{length}(\mathsf{ik})] || \mathsf{ik} || \mathsf{asset\_desc}\!`. -where :math:`\mathsf{GroupHash^{\mathbb{P}}}` is the Group Hash into the group of points on the Pallas curve defined in the protocol specification [#protocol-concretegrouphashpallasandvesta]_. +In the case of Orchard, we define :math:`\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})` +where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. Global Issuance State --------------------- @@ -177,11 +177,11 @@ The issuer program performs the following operations For all actions `IssueAction`: - encode :math:`\mathsf{asset\_desc}` as 512 byte-string. -- compute :math:`\mathsf{AssetId}` as :math:`\mathsf{AssetIdHash(ik, asset\_desc)}` -- set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) +- compute :math:`\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))` +- set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) - For each recipient :math:`i`: - - generate a ZSA output note as :math:`\mathsf{note}_i =(\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetId}, \mathsf{rcm}_i)` + - generate a ZSA output note that includes the Asset Base. For an Orchard-based ZSA note this is :math:`\mathsf{note}_i = (\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetBase^{Orchard}}, \mathsf{rcm}_i)\!`. - encode the `IssueAction` into the vector `vIssueActions` of the bundle @@ -206,7 +206,7 @@ Issuers can wrap Assets defined in other chains and issue them at once in a sing - By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any Asset associated to their issuer keys. For example, - - by setting ``finalize = 1`` from the first issuance action for that Asset identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + - by setting ``finalize = 1`` from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. - Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by @@ -315,7 +315,7 @@ UTF-8 encoding of the Asset description string. T.1c: isFinalized ''''''''''''''''' -1-bit representation of a boolean flag that is set to 'true' if the Asset identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. +1-bit representation of a boolean flag that is set to 'true' if the Asset Identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. T.2 issuerVerificationKey @@ -341,7 +341,7 @@ Other Considerations Implementing Zcash Nodes ------------------------ -Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets. +Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping `issuanceSupplyInfoMap` from :math:`\mathsf{AssetId}` to :math:`\mathsf{issuanceSupplyInfoMap := (totalSupply, finalize)}` in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets. Fee Structures -------------- @@ -351,7 +351,7 @@ The fee mechanism described in this ZIP will follow the mechanism described in Z Future Work ----------- -In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying :math:`\mathsf{ik}` of a given Asset, in case the original one was compromised, without having to change the Asset identifier altogether. +In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying :math:`\mathsf{ik}` of a given Asset, in case the original one was compromised, without having to change the Asset Identifier altogether. Test Vectors ============ @@ -380,6 +380,6 @@ References .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ -.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys `_ -.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ -.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ \ No newline at end of file +.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys `_ +.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ +.. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ \ No newline at end of file From 5ad0d7a47a326af61b87a302c30393916b75279c Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Fri, 3 Feb 2023 02:03:19 +0530 Subject: [PATCH 067/101] Including Asset Digest throughout the ZIPs --- zip-0226.html | 6 +++--- zip-0226.rst | 6 +++--- zip-0227.html | 18 ++++++++++++++---- zip-0227.rst | 13 +++++++++---- 4 files changed, 29 insertions(+), 14 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 245e40c59..419ba6bd7 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -56,7 +56,7 @@ . This Asset Identifier is stored in Orchard-based ZSA notes as an Asset Base \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) . These terms are formally defined in ZIP 227 5.

    -

    The Asset Identifier (via means of the Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 9), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 9), 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}-value^{new}}\) @@ -91,7 +91,7 @@ \(\mathsf{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, \(\mathsf{AssetId}\) - and the Asset Base ( + , the Asset Digest, and the Asset Base ( \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) for the Orchard-based ZSA protocol) are derived as defined in ZIP 227 5.

    This @@ -103,7 +103,7 @@ .

    In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset Identifier, \(\mathsf{AssetId}\) - and the Asset Base from one shielded protocol to another.

    + , the Asset Digest, and the Asset Base from one shielded protocol to another.

    Note Structure & Commitment

    Let diff --git a/zip-0226.rst b/zip-0226.rst index f2e3d89d6..886a6a4ec 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -61,7 +61,7 @@ In order to be able to represent different Assets, we need to define a data fiel This Asset Identifier is stored in Orchard-based ZSA notes as an Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`. These terms are formally defined in ZIP 227 [#zip-0227]_. -The Asset Identifier (via means of the Asset Base) will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset Identifier**. This is specially 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. +The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset Identifier**. This is specially 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 [#initial-zsa-issue]_ [#generalized-value-commitments]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that derives the value commitment, :math:`\mathsf{cv^{net}}`, of the *net value* in an Orchard Action. @@ -79,11 +79,11 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Asset Identifiers ----------------- -For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{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, :math:`\mathsf{AssetId}` and the Asset Base (:math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` for the Orchard-based ZSA protocol) are derived as defined in ZIP 227 [#zip-0227]_. +For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{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, :math:`\mathsf{AssetId}` , the Asset Digest, and the Asset Base (:math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` for the Orchard-based ZSA protocol) are derived as defined in ZIP 227 [#zip-0227]_. This :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` will be the base point of the value commitment for the specific Custom Asset. Note that the :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`. -In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset Identifier, :math:`\mathsf{AssetId}` and the Asset Base from one shielded protocol to another. +In future network and protocol upgrades, the same Asset description string can be carried on, with potentially a mapping into a different shielded protocol. In that case, the turnstile should know how to transform the Asset Identifier, :math:`\mathsf{AssetId}`, the Asset Digest, and the Asset Base from one shielded protocol to another. Note Structure & Commitment --------------------------- diff --git a/zip-0227.html b/zip-0227.html index be4167654..63f614a18 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -101,7 +101,11 @@ is the issuance key and \(\mathsf{asset\_desc}\) is a byte string.

    -

    A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive a specific Asset Base within each such shielded protocol (for example +

    A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, + \(\mathsf{AssetDigest}\) + , which is simply is a + \(\mathsf{BLAKE2b-512}\) + hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.

    Let

    @@ -114,13 +118,16 @@ be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

    Define - \(\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))\) + \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))\) , where

    • \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := [0x00, \mathsf{length}(\mathsf{ik})] || \mathsf{ik} || \mathsf{asset\_desc}\!\) .
    +

    Define + \(\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})\) + , where

    In the case of Orchard, we define \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) where @@ -248,7 +255,10 @@ \(\mathsf{asset\_desc}\) as 512 byte-string.

  • compute - \(\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))\) + \(\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))\) +
    • +
  • compute + \(\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})\)
  • set the finalize boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set finalize = 0, otherwise set finalize = 1)
  • For each recipient @@ -384,7 +394,7 @@

    Note value encoded as little-endian 8-byte representation of u64 raw value.

    • T.1a.3: asset
    -

    Asset ID encoded as 32-byte representation of Pallas point.

    +

    Asset Base encoded as 32-byte representation of Pallas point.

    T.1a.4: rho

    Nullifier encoded as 32-byte representation of Pallas point.

    diff --git a/zip-0227.rst b/zip-0227.rst index 45e5edcf4..527b98490 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -106,18 +106,22 @@ Asset Identifier For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair :math:`(\mathsf{ik}, \mathsf{asset\_desc})`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string. -A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive a specific Asset Base within each such shielded protocol (for example :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes. +A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is simply is a :math:`\mathsf{BLAKE2b-512}` hash of the Asset Identifier. +From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes. Let - :math:`\mathsf{asset\_desc}` be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. - :math:`\mathsf{ik}` be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH. -Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`, +Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`, where - :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := [0x00, \mathsf{length}(\mathsf{ik})] || \mathsf{ik} || \mathsf{asset\_desc}\!`. +Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})`, +where + In the case of Orchard, we define :math:`\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. @@ -177,7 +181,8 @@ The issuer program performs the following operations For all actions `IssueAction`: - encode :math:`\mathsf{asset\_desc}` as 512 byte-string. -- compute :math:`\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))` +- compute :math:`\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))` +- compute :math:`\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})` - set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) - For each recipient :math:`i`: @@ -299,7 +304,7 @@ Note value encoded as little-endian 8-byte representation of u64 raw value. T.1a.3: asset ............. -Asset ID encoded as 32-byte representation of Pallas point. +Asset Base encoded as 32-byte representation of Pallas point. T.1a.4: rho ........... From 6760bbfa3a4a7fbb0eaf0925219404d07b0d5e9e Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Fri, 3 Feb 2023 10:33:21 +0530 Subject: [PATCH 068/101] Update zip-0226.rst Co-authored-by: Daira Hopwood --- zip-0226.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0226.rst b/zip-0226.rst index 886a6a4ec..3ed45224d 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -58,7 +58,7 @@ issuance and bridging purposes. 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 :math:`\mathsf{AssetId}`. -This Asset Identifier is stored in Orchard-based ZSA notes as an Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`. +This Asset Identifier maps to an Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` that is stored in Orchard-based ZSA notes. These terms are formally defined in ZIP 227 [#zip-0227]_. The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset Identifier**. This is specially 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. From a3a762fda5e21385808ba4246ea3daa1690706c4 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Fri, 3 Feb 2023 10:48:44 +0530 Subject: [PATCH 069/101] adding Daira's suggested comments and edits --- zip-0226.html | 6 +++--- zip-0226.rst | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 419ba6bd7..740dc0708 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -66,7 +66,7 @@ , 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 in the transaction. We propose to make the Asset Base +

    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 \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) an auxiliary input to the proof for each Action statement 17, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) @@ -74,7 +74,7 @@ \(\mathcal{V}^\mathsf{Orchard}\) in the value commitment 15. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - , and (2) that only actions with the same Asset Base will balance out in the binding and balance signatures.

    + , 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 16 for Custom Assets, as we need to enforce that the \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) of the output note of that split Action is the output of a valid @@ -400,7 +400,7 @@

  • We prevent the "roadblock" attack on the Asset Identifer by ensuring the output notes receive an Asset Base that exists on the global state.
  • Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets.
      -
    • One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
      • +
    • One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
    • diff --git a/zip-0226.rst b/zip-0226.rst index 3ed45224d..5884e6667 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -65,7 +65,7 @@ The Asset Identifier (via means of theAsset Digest and Asset Base) will be used As was initially proposed by Jack Grigg and Daira Hopwood [#initial-zsa-issue]_ [#generalized-value-commitments]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that derives the value commitment, :math:`\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 in the transaction. We propose to make the Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}`, and (2) that only actions with the same Asset Base will balance out in the binding and balance signatures. +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 :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` an auxiliary input to the proof for each Action statement [#protocol-actionstatement]_, represented already as a point on the Pallas curve. The circuit then should check that the same :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` is used in the old note commitment and the new note commitment [#protocol-concretesinsemillacommit]_, **and** as the base point :math:`\mathcal{V}^\mathsf{Orchard}` in the value commitment [#protocol-concretevaluecommit]_. This ensures (1) that the input and output notes are of the same :math:`\mathsf{AssetBase}^{\mathsf{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 [#protocol-dummynotes]_ for Custom Assets, as we need to enforce that the :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` of the output note of that split Action is the output of a valid :math:`\mathsf{ZSAValueBase^{Orchard}}` computation defined in ZIP 227 [#zip-0227]_. @@ -280,7 +280,7 @@ Security and Privacy - We prevent the "roadblock" attack on the Asset Identifer by ensuring the output notes receive an Asset Base that exists on the global state. - Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets. - - One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients. + - One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients. Deployment ----------- From 6ebba3ffcb1562225d200c7cab81d0e6c3d9d1ab Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Fri, 3 Feb 2023 17:16:07 +0530 Subject: [PATCH 070/101] generating issuance keys independently of the Orchard spending key --- zip-0227.html | 81 +++++++++++++++++++++++++++++++++++++++++---------- zip-0227.rst | 31 +++++++++++++++----- 2 files changed, 90 insertions(+), 22 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 63f614a18..2f23c28e6 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -68,30 +68,57 @@

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    +

    Issuance Authorization Signature Scheme

    +

    The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature 12.

    +

    We define the issuance authorization signature scheme + \(\mathsf{IssueAuthSig}\) + identically to the Orchard spend authorization signature scheme, + \(\mathsf{SpendAuthSig^{\mathsf{Orchard}}\) + , that is, as + \(RedPallas\) + with key re-randomization and with generator + \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Orchard}}\) + 13.

    +

    Issuance Keys

    -

    The ZSA Protocol adds the following two keys to the key components 9:

    +

    The ZSA Protocol adds the following three keys to the key components 9:

      -
    1. The issuance authorizing key, denoted as +
    2. The issuance master key, denoted as + \(\mathsf{sk}_{\mathsf{iss}}\) + , as the name suggests, is the master key that is used to derive the other two keys.
      3. +
    3. The issuance authorizing key is the key that is used to sign the issuance transaction, and is denoted as \(\mathsf{isk}\) - , is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset Identifier, and is only used by the issuer.
      4. + . This key is used to authorize the issuance of a specific Asset Identifier, and is only used by the issuer.
    4. The issuance validating key, denoted as \(\mathsf{ik}\) , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.
    -

    The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 7 and in accordance with ZIP 316 8.

    +

    The issuance master key is generated by choosing a bit sequence uniformly at random from + \(\mathbb{B}^{\mathbb{Y}[32]}\) + , like the Orchard spending key 11. In + \(\mathsf{zcashd}\) + , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 7, as detailed below:

    +
      +
    • Let + \(S\) + be a seed byte sequence of a chosen length, which MUST be at least 32 bytes and at most 252 bytes. Compute the issuance master key + \(\mathsf{sk}_{\mathsf{iss}} := \mathsf{BLAKE2b\text{-}256}(\mathtt{''ZcashIP32Issuance''}, S)\) + .
      • +
    +

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 11, as described below.

      -
    • The issuance authorizing key is derived directly from the spending key, - \(\mathsf{sk}\) +
    • The issuance authorizing key is derived from the issuance master key, + \(\mathsf{sk}_{\mathsf{iss}}\) , as a private signature key:
    -
    \(\mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])}\)
    +
    \(\mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{PRF}^{\mathsf{expand}}_{\mathsf{sk}_{\mathsf{iss}}} ([\mathsf{0x0a}]))\)
    • The issuance validating key is derived from the issuance authorizing key, \(\mathsf{isk}\) , as a public verification key:
    -
    \(\mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)}\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +
    \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)
    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair @@ -132,7 +159,7 @@ \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 10.

    + is defined as in 10.

    Global Issuance State

    Issuance requires the following additions to the global state:

    @@ -207,7 +234,7 @@ \(\mathsf{isk}\) , that validates the issuance . -

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 11.

    +

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 14.

    @@ -291,7 +318,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -423,7 +450,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -434,7 +461,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -537,10 +564,34 @@

    - +
    + + + +
    11Zcash Protocol Specification, Version 2022.3.8. Section 4.2.3: Orchard Key Components
    + + + + + + + +
    12Zcash Protocol Specification, Version 2022.3.8. Section 4.15: Spend Authorization Signature (Sapling and Orchard)
    + + + + + + + +
    13Zcash Protocol Specification, Version 2022.3.8. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)
    + + + + diff --git a/zip-0227.rst b/zip-0227.rst index 527b98490..49b9b36ee 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -80,24 +80,38 @@ The protocol was designed with three main properties in mind: The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +Issuance Authorization Signature Scheme +--------------------------------------- + +The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature [#protocol-spendauthsig]_. + +We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` identically to the Orchard spend authorization signature scheme, :math:`\mathsf{SpendAuthSig^{\mathsf{Orchard}}`, that is, as :math:`RedPallas` with key re-randomization and with generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Orchard}}` [#protocol-concretespendauthsig]_. + Issuance Keys ------------- -The ZSA Protocol adds the following two keys to the key components [#protocol-addressesandkeys]_: +The ZSA Protocol adds the following three keys to the key components [#protocol-addressesandkeys]_: + +1. The issuance master key, denoted as :math:`\mathsf{sk}_{\mathsf{iss}}`, as the name suggests, is the master key that is used to derive the other two keys. + +2. The issuance authorizing key is the key that is used to sign the issuance transaction, and is denoted as :math:`\mathsf{isk}`. This key is used to authorize the issuance of a specific Asset Identifier, and is only used by the issuer. + +3. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. -1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key that is used to sign the issuance transaction. This key is used to authorize the issuance of a specific Asset Identifier, and is only used by the issuer. +The issuance master key is generated by choosing a bit sequence uniformly at random from :math:`\mathbb{B}^{\mathbb{Y}[32]}`, like the Orchard spending key [#protocol-orchardkeycomponents]_. +In :math:`\mathsf{zcashd}`, this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 [#zip-0032]_, as detailed below: -2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. +- Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 bytes and at most 252 bytes. Compute the issuance master key :math:`\mathsf{sk}_{\mathsf{iss}} := \mathsf{BLAKE2b\text{-}256}(\mathtt{''ZcashIP32Issuance''}, S)`. -The two keys are derived in an analogous manner to the spend authorizing key and spend validating key, using the same signature scheme, as described in ZIP 32 [#zip-0032]_ and in accordance with ZIP 316 [#zip-0316]_. +The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key [#protocol-orchardkeycomponents]_, as described below. -- The issuance authorizing key is derived directly from the spending key, :math:`\mathsf{sk}`, as a private signature key: +- The issuance authorizing key is derived from the issuance master key, :math:`\mathsf{sk}_{\mathsf{iss}}`, as a private signature key: -.. math:: \mathsf{isk := ToScalar^{Orchard}(︀ PRF^{expand}_{sk} ([0x0a])} +.. math:: \mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{PRF}^{\mathsf{expand}}_{\mathsf{sk}_{\mathsf{iss}}} ([\mathsf{0x0a}])) - The issuance validating key is derived from the issuance authorizing key, :math:`\mathsf{isk}`, as a public verification key: -.. math:: \mathsf{ik := SpendAuthSig^{Orchard}.DerivePublic(isk)} +.. math:: \mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk}) This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. @@ -387,4 +401,7 @@ References .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ .. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys `_ .. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ +.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.3.8. Section 4.2.3: Orchard Key Components `_ +.. [#protocol-spendauthsig] `Zcash Protocol Specification, Version 2022.3.8. Section 4.15: Spend Authorization Signature (Sapling and Orchard) `_ +.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) `_ .. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ \ No newline at end of file From 1494e0e4955d655ccdf83e40083c4823fe690ef8 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 13 Feb 2023 10:47:19 +0530 Subject: [PATCH 071/101] editing IssueAuthSig, plus other edits --- zip-0227.html | 42 +++++++++++++++++++++++------------------- zip-0227.rst | 10 ++++++---- 2 files changed, 29 insertions(+), 23 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 2f23c28e6..d379c772b 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -72,16 +72,20 @@

    The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature 12.

    We define the issuance authorization signature scheme \(\mathsf{IssueAuthSig}\) - identically to the Orchard spend authorization signature scheme, - \(\mathsf{SpendAuthSig^{\mathsf{Orchard}}\) - , that is, as - \(RedPallas\) + similar to the Orchard spend authorization signature scheme, + \(\mathsf{SpendAuthSig}^{\mathsf{Orchard}}\) + 13. Specifically, we instantiate + \(\mathsf{IssueAuthSig}\) + as + \(\mathsf{RedPallas}\) with key re-randomization and with generator - \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Orchard}}\) - 13.

    + \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})\) + where + \(\mathsf{GroupHash}^\mathbb{P}\) + is defined as in 10.

    Issuance Keys

    -

    The ZSA Protocol adds the following three keys to the key components 9:

    +

    The ZSA Protocol adds the following three keys to the key components 9:

    1. The issuance master key, denoted as \(\mathsf{sk}_{\mathsf{iss}}\) @@ -95,9 +99,9 @@

    The issuance master key is generated by choosing a bit sequence uniformly at random from \(\mathbb{B}^{\mathbb{Y}[32]}\) - , like the Orchard spending key 11. In + , like the Orchard spending key 11. In \(\mathsf{zcashd}\) - , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 7, as detailed below:

    + , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 7, as detailed below:

    • Let \(S\) @@ -105,7 +109,7 @@ \(\mathsf{sk}_{\mathsf{iss}} := \mathsf{BLAKE2b\text{-}256}(\mathtt{''ZcashIP32Issuance''}, S)\) .
    -

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 11, as described below.

    +

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 11, as described below.

    • The issuance authorizing key is derived from the issuance master key, \(\mathsf{sk}_{\mathsf{iss}}\) @@ -118,7 +122,7 @@ , as a public verification key:
    \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    Asset Identifier

    For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair @@ -131,7 +135,7 @@

    A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, \(\mathsf{AssetDigest}\) , which is simply is a - \(\mathsf{BLAKE2b-512}\) + \(\mathsf{BLAKE2b-256}\) hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.

    @@ -145,11 +149,11 @@ be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

    Define - \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))\) + \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))\) , where

    • - \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := [0x00, \mathsf{length}(\mathsf{ik})] || \mathsf{ik} || \mathsf{asset\_desc}\!\) + \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!\) .

    Define @@ -159,7 +163,7 @@ \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 10.

    + is defined as in 10.

    Global Issuance State

    Issuance requires the following additions to the global state:

    @@ -234,7 +238,7 @@ \(\mathsf{isk}\) , that validates the issuance . -

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 14.

    +

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 14.

    14 Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    @@ -318,7 +322,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -450,7 +454,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -461,7 +465,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying diff --git a/zip-0227.rst b/zip-0227.rst index 49b9b36ee..1199179e0 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -85,7 +85,9 @@ Issuance Authorization Signature Scheme The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature [#protocol-spendauthsig]_. -We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` identically to the Orchard spend authorization signature scheme, :math:`\mathsf{SpendAuthSig^{\mathsf{Orchard}}`, that is, as :math:`RedPallas` with key re-randomization and with generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Orchard}}` [#protocol-concretespendauthsig]_. +We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` similar to the Orchard spend authorization signature scheme, :math:`\mathsf{SpendAuthSig}^{\mathsf{Orchard}}` [#protocol-concretespendauthsig]_. +Specifically, we instantiate :math:`\mathsf{IssueAuthSig}` as :math:`\mathsf{RedPallas}` with key re-randomization and with generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. + Issuance Keys ------------- @@ -120,7 +122,7 @@ Asset Identifier For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair :math:`(\mathsf{ik}, \mathsf{asset\_desc})`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string. -A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is simply is a :math:`\mathsf{BLAKE2b-512}` hash of the Asset Identifier. +A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is simply is a :math:`\mathsf{BLAKE2b-256}` hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes. Let @@ -128,10 +130,10 @@ Let - :math:`\mathsf{asset\_desc}` be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. - :math:`\mathsf{ik}` be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH. -Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`, +Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`, where -- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := [0x00, \mathsf{length}(\mathsf{ik})] || \mathsf{ik} || \mathsf{asset\_desc}\!`. +- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!`. Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})`, where From 087afea0b303bbaf733463d4735b6a91e5d9092f Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 13 Feb 2023 16:14:21 +0530 Subject: [PATCH 072/101] adding diagram for ZSA key components --- key_components_zsa.png | Bin 0 -> 61722 bytes key_components_zsa.svg | 270 +++++++++++++++++++++++++++++++++++++++++ zip-0227.html | 5 + zip-0227.rst | 12 +- 4 files changed, 286 insertions(+), 1 deletion(-) create mode 100644 key_components_zsa.png create mode 100644 key_components_zsa.svg diff --git a/key_components_zsa.png b/key_components_zsa.png new file mode 100644 index 0000000000000000000000000000000000000000..aa9fa5d21d48885d21a987130a4504a92b74614e GIT binary patch literal 61722 zcmeGES5%YT^F9s-klqEPOBGbAgdU1?P>O<5q_-d)X#wdN0R^dwM4AYKG%1l9N*+*( zgd#maC?X&&p$7>e|M)zg@7a6$p8fV(EV8n8n|;sBp1J0_^WvVl5i z1OP7a0RWWEbTs5|md8nZ_R7aKsp2-{^{Qz&C%sEiHAa+D4~mb^n&^? zQ$&S7P<}{xCCYGx(?EyKK>xnZgWD^~!nQge?{I8d>M?ejux@Hb#>N%cHG&`;s2%JM z=GP*Qa6HGofVtu2<)so*6gd)t!m$6Z-OwvGSGleKUwg_z&G)~LWr_@nDgQNNZ_dYT z|8>tAzdj}``d|Ba|Gm!tI^QY1{p^38UmGUS{NL2CD4GA)*OKr5P5l4&qj(ov7!aRg zEQRvpauIVebFn?(xrCwyQ-;LP#CzrRlNKDXs<^%$b0O3v-#9s|D`;9I|1Jusj?J;4_y1=PFK&m=en$kY-Gl|-wZN3XkEnM z0?JD&m3OHftXzJiE)cD1v30!QaLORCM^-;3=2_yrI#Vm#Z+<&Jk)Rp`=|hCnwLVlX z6$_;nWg0CFr^B(}@}uRO%f(o&CQTVmvdYjahU)4E!|a@0<^yJ@;za#<+`vmTPSh6w z0pnF28aiIqD2fUI1cufJ5+Z=F%;uB;sujyWeU%W!m;K%zo(UQ#yMc`W-0Z9hC@Plw znI!_?<|-IbAc9_%b@usB@(fEk8I*4+JUkX@lMqPx?C#u7(6YYn-pb)Me=GetDY<(E1cHp{IEHLXS)vE( zm7aOaSgUc1cWCbT;_=0$>Zo^igD7j-t{=#oQt!|%kYY6I;+-dW8xRSpFXgTRhfD8q z{M1Q;#K$aj1|W@J0^w71ymXO*X<*EB`R+^OKW-!%?Nw}DnEhRSeTMNddiEP1K$OfR zb8S~J0ia#csY64H^$*6ty?4yv6z=a9Y@`mfx?AEa8l4p3tMvaA*=DXNx!6$iKJo(d zvr%gAGAIBR7W@2DjZIK~W-e<3qGz(H18yd~%%Yb1Adm)^k`g7#PjL_Qv(P^N29gnQ``PqagI@wSUh`HSiu;DRxhTaUpWB$ETJ%Al#*bXKRmTp z|AL0`c6rzbb3LnLUepc~3w3UWv;rC<$>q0n+vVecDB}Y0x#;}OdO0!F zdc)I^4{{t`aw=c11mjy0gkb28P}of^+vDJs+j_xF;iA!o+f>!;l-x9?5*}=t=BHO3 z=YIu$WB8gZtck-iR_89|$#0|Dp`%`Wdz3307o~{N5%iKFk^*VlvtOh)z|=kw-f9i4%HbCB+eye`YS<$&Mz3xzhQ)KG%gh=*D~+W_!-doq>Bs8+d)US zzlpErU!7cL%3!drcq?D@inN2 z6Jcc=nyv+Ka6BS7HxYk8M{f=>V!Ph^{86Icn30e^E0B~VbbrT`{a5d&@_tknJ*UYK7eJIC{d&BVV0)l*@jdxHeQTP66k}${j2^4z z(e-1UJlz9p-D#bjea80|g~zn)vX|Yr1LocMwOKnT(tLwDr|7sLcDqlL?s4AQKIU)# z1D}=LP#vM6DVtVXJ3tc)+u9(q~>`}L4nv=tO9#J_7U4y|O_QZ#g z{-?C{(H?R0N~daI&2lQD!bt;dkY}T5>3ocs9bV6F{@;TNf~YS7G>^tgy)@~(m++je zwtr$h_}v+6x{Z<-mx_bujzxNc5^H9Pch^sfiY6B4t8kcB?ZDSv!?Ucl zN>vg%8JoR1_uv0?rthXD`M8iK;$KytG;p~JMEy9fpyI#sn2-_N3^!^t73)9HE~AW7 z^Peq@cwauSs^Ajz5799bUdx=YN(Z}SfYrGkj~-+Vns z195>tBs>)r@Z`^%D@*okPuvUr1L+nl$4@pa#{=JAefs+cP)IN^{_ls7t5C%s$&3!~ z3-aKF#|(a}vZ9dZb4M2^DDMfg!C)JsTo|kL)GPmyA?ZJ^jRowMJBR56v`6Sc$Xvq> zk@?azMh9B+;n@uK?$omf|C}u5!AYHW&eOUcE)%a}m^Z%nK{+=Sw2INl0P2%A=aFy; zw($#o49N@$(0yMEdq3#R_=T8W;NLO+s{z!B>>^NVi)$ZN|6aYxaEUcRQglAgD7Mdd zdeu7{6<k9le?r8MNoT$pW7sttL5@S@FFhqKtR)ywWq~`90 z**MuKa(9x;TR5{U^Uzz+h9!QZDOx|3P%D>O~sW3bmdG@rpdx`vWkm>b}H z=Yq605FC@BbjQc~fkIMrb-}j_cW?~d4P5b%-HAAal#SSkQQizEdxZ#2*c>oK!6{J*jWDtaNjlevW!8y9VgwD{^nb7f4Ze5ux~~g zGvLAn+#8ZRB=w+O1P$!_x^su_X_0Zr@u!nJTKVnSGtDTpVNI72>Q=*QZbA23Hf;39 z@OP`pF6bN(hVqNl4L8Y+MS{(+aWcW_6)-_+2h$F6I2{MN@=Ka(Oh{GbkN;@4P0AB0 zzWkr9b2^)n*^gvAhYyYdvW$WAMe-gVo7v6G@2su#ga3xUGC+94FNoz8KyfI(c*B2G z@5w&|hMlLpy6UHJaCio+&<|`c!R_k_Dmpbdp~ha^J0L|`(T3aT3=GpB%QmW($S(xa z!=pXy0MR2D3*RpkCKMgrmn}25VRz}4{g{s+_zUO_K5a@3A#|wr^6#`6w}hm}6y0T~ zD|T7OOK$gXS27XU0GCVE<|AHY#)L|*v~1UzfZWVY8Kl7I z^aD!%W53MfMA)tl&-9xn(hMExO3f-ZhORrxm%>@n_}$TbcGX6#=rf3y=V8;itJ*H8JYOqcZsW@;Z_nvY$0)Yf z4BM@}e{^7zAS1S2R}`|~JYb7EEx>=d>ruRfvcuPBYnMueoZuyx)6ju#B&rl{M2IeP z{Hv`R5KpU`7iL40a81>pW@) z5ebqJv2qD&OlMDGTVo!2q8n7X7|VL2ekrH&5Mh)TDQ+EzOvo@=JY;3KiUZLvl|G~Y zCKhMdu)-1+$4#%q=Jwn@kjhYhE+%LsHZG^ZsXKAE$nbZj5Nu~V71_;L(;~cqP?Pl{ z3UQsMZ*a+IzARV?g7PYkd<_5njbZo9@vlWb?JHen9{X#W3$!b;p^GRA;A1xp(8`DN zKx#QZ_ly}j?g8e9Jr+%C8EOPot)}zOYD1*5e68Y+@QqivB8rZd=fr-nWu9IFul9gk z{Z>s$HdL?-48F9<}k zY?Rd0cBRW#Q6z@I3navjL@dZ=zs69BrfL|py4%PE{{A}m>PrcAq<43u_ZV@|BBQQ* zC8)sSrF3utf}8j1Vd%)V*tQ1#@rb%FSc62>*dI44Zu;U;`Eg2IobZBRK&l6dXd{}c z8dQ(ye$y6D&_5W>no=kl1!-r5;SVt};e|5+=5yR3^$2Gy_PB3*sQ`{;(gi=@rtbTp zjm5HhbpCdIJo`qCAoOUXjU!=pEU6kp+$q>~Dn2~hIxaHp8eJ9L#;jqJ^}8lW!g0U* ztinzZH$;rH*0!-)O3goh9mXj)8c*MQ-f?&s0U>1}EIz|6Brln`ORRSkwU9u;PIUuk z7ZhnVHro=Zi0*YPZCezC$S)y!w;s$O{=!(!3yc$6kjZ#Oic6LEw96XtaKviOqfR8t zmWmAN_!NEFL@<$o!1)P`^QgVZjq*Ge(K10CHpFW5Vb!o#*spn~(tl9Xq6;xT25~({ z(L#^iFnR-BNJr!AoVI1E9!@%)Prr#dOI&J8@~oNg>;^Xr?lla=nup_Uy*~09$nF6_ zHP=oR_kRZ2v=bbun-3}XDJzZ>b=YvmYWu=N!aoxlTj(GN_~iD0P1INTwp)#b#_b0l zJ5Lwe9!x|k!#~m&+vHM1_m3lsMk6)1;e19s;GAo96QH*dE|0bLj0-m`#1TcaaAYra zoRM3xjWxxbHRx7kG;+q(kpGe@0WrJ-fyPbXP;@&lQWQPqd(I3-(IInRlFeF&NaBb}Azxgo1XVQxnErlx5ko*D$ktiL4tPPNC(gwhfweXbL3;Fm;Duq^6YA$DirH zTEy-;)yrLxzP@T6;v{+WYH}$m)A1hHG8huqfs8#=&$6SIIt1$uFn&&xU~(Nes7K7~ zfapJeO)PL97>&3oD)n0+YIL-XKniZo=N2E64`(G`u9O4wXaTd7| zo@MUhM|UYy6O0?SyBMWDp&yR1&Mc0}=5}~t7G>IZw)(VA~Vl)B8XL}@4yfF;_iif|j$js|f4Qv&ft3V;l68S8+<6@x_f5tbHg zWNE*^Wv~~G2+|}5BJ98vOLHn&f^@l`yxwu){`0VDiKXT-7%>x-8Rt5Kz4h4ubQUMl zF_ZV|MTLJwt%b&LyL5}bQz~`4Aq>q10P>sjy7HSq`!(+o z3O@XkIo$G%UDzdxovJbqsBTL{@tE-sUI;3Pazy)oX70zB8 zyC+QWaH~l-62(Q#_{K@IS(n>yY1kOb-w03d%00w+@DgZ|m|}6xTED(K&`m!fW%$xN zJ3j^o_AEX=brI1v)Q}xs(wSsS}>s3yg%j|in%@C zbxWWT^H4GcbQy$46;pRjJQ#X;Bm0^{n*29U^z=|9aYdB>7QEzZa=dA2Y`8^r<*8k- zoA4z8pl`1@TCE`+XJx14K!y_bgoZ=^Xmg#A++@tom=ym8*SC$?XW_|h1=)pmd?6c;bxMu zHvp05^L%Z_AV%GQyBhBPBCdQL-w6d^uq0J?S`F}}{Oe!U)F;Id5rUwuV21U#EyG{T z7+!bqVZ6J76J$9As|Byj<(l}|r7!49u{*%_osjl2R%@PJdj>l&kd_km%L#&)1+qQJ zL(2>2evc_e^f%@!i)caL*Y-+ee>t}m-qV59T~z>P7xcWP-Wq=J%QO2NF%lv(Rdzj- zeLow~ZM*SjR!#l6Tem@Ed3k!6!H%Yd$fX**Y$p957=#p!z z?c!d^Q)TL|yV0}nQ|R84!CDVvS(Z2&fj98q-SMpLQEw9i&2|puU2+i{X2dIN*qq@V z>E*@(gKaKDf)<>0`7txS3_&G~MP?G5xsDiHVbD zdd({#8TgGwj(Cu) z%LRSF{Vi>I4Jk)}svp9lj^dTyxU+;jT3?POc&iO$s?xXipkjT%yRwug)>W&|VYTnR zlz_efOG{Q#7s_T`7X^DLkgSY5+I3VIRN)u!*YVVhOD7`{yJkI^+2N^X-M0HCK>pd^ zNy9bWutLfOnl#hm?O!B9aa2rZw6hz~236);!TShT(-K7lZv#;hsC(Hrco)MQJhFJ9 zB`#A3TB#qNKk6;h+on< zD!cRC?}!e=eqKPSN3+t((Qds1zWr;awYItTgK~WB3PI*SLcS$Z**%E+ASW`LnQMa= z2|P2Vd$Z|I@ed;~-MtzzU|&cf(tI)RF$pqGEN&3C3mq`LjO@%jEnHoiHdz}b)L0J^ zv|x5lIx}`ixvd(N?1-e9LTVpNMSh;A*StF2L!9b{P-pMZE8u45KG9khF1y^!Z&_&{l>&$(lq*#aDW;mdvKy z>o^1&^ylWI)1hgpc&q4}-QaTD&OS`s($}ZVA$V_axRgkk+PbmJ7g)?Nrub7!JWPf* zn(dU*(KlydF6`9;B9{O|SK1XC13|eF@_{#32$mK#=C_Xm0>?|zxvoSjC{yVw`1||$ zplxsU*S@gW&F2+1>BEp1W>p$5>?gIsb(9nI-Mq(466av&!Uo(LJ$&fv=RdJK*kelQ zJiE~P{a@Hv>3YS&ot{z>rFnV{ff^Wv#K=jHCEZ~o-d^U1-d^QaxbljcZ=DLVvE!pr z>#6_CGn%W@B!aWP6BYwF4gYbY0u%EYhPfNwuv&?AD(gy1ISR*qP9`UN2?)Jbsx8dX z=>wmoC7JpWM&vgnK3?v!x_UCZWuk>7(^{UB3y766ruw9l)758WR((V1iH78wUr4fY zbW;D?P6!zRJ#R+d(h&9HC)v30X8@9^hGy)#Sxb7OMO~}9w~o6U_H1_+m(|n+ZAG>#6fvca~Msd4)^z_Yd`xR4lN=@RE<9cPh!oJ8rx&hWBtn&{C-5H!uZ zCgR&^ACf-PT0p#z@FHfc*N~0}+Ls3G@S-lyCe@`lx^hOZs4fb<*dYX}ZFkYtID2&p zCTxUE7Xp}2vp8P0ZERjhhtXPrl#1c>?%e^O0Z@PqJEe@?mY+LY3CllrP}AzIW93SC zwDwO@(t^!0DCUuQ6#i8Ws2)imQn*weD~mF@*PLs{vvJndz~kBc)OmOwEkl4OfipP7 zp^7CLuCxsn`c8(PeL&%>T>%!vLKPw}(g#^0gN3LEeVVcE8I=O4!Q{i6?#odO89F(q ze(o=MDD#mhVJ@21nc-;|J&O9g_t~8!)uq=Or7GO`>J?of5VaH5BZz5(jtm}nENRNB zCr6j^GA{+=H~1YYu3=;0Fh|Cnhc5eC$iBhSPhJb1P7G&a$j+~+R7C&*7chifJ-Yg` zdT8V~t++KTw`WJQ(wKH*K*cuj>+~r9!4uV>R+tQ6QN%--v$pO@34$bYqP~|fuw6~b z3Pa04-+MdvG^7uAP?hLK#v{BueZHm7IEYT9Nc3@xrVN~G2IHy0;g?rB`*-p+uDnAJ zLGhCrd;EHc*KG-w-<7*qphzbNF>xz4~lbZTdeM|~F;)r==sCn-BXv8sW7kL?!U-wXrs z#ueGvyl0w7AYzDFRWaN*0Dm+gqx_PNqeEXSZus`2IBL`5`Z3PRa3KzDSt+(g=B})U zR~0$tJ+Mf^-8A#7k>G5rpt>sNx_4;tpIkU8?8gx9v1B%NA@}+E-KWRAK@b&q9i<98 zj_$Kb!&7Fix0mHa5vtsY1$wHi?ecJ~UvVur&n~~*<_hE8gUwQ6FI0dC=GhyKwsFgy zgQY1ZNCLU`bIShgiKn2}Ig3{{8f|iSrcYLa{pw*YO{_%AV_qo zAD1s)w$Ct5hZ%nb7k$d36@YyY-c&Z}UybqL6!H6EmPK6Dy)YFskP)BcRz>wPN!T4Q zsI8k}xa~=1qD_)0Kc0QROoABXWTry1`#$&Obi1q&oJ)^4>9}e5_l*;~cckklX z4kKg2;|ireke`5q)Jf%=)w{Jch6g^s^ns$;_<7Gevx!yk)q_Q&(gJypTh-W?DaPD? z!+e99+xF;jZr?gKY~plh{_KZ-dPrK!rxA~MU20(p^Sy}YdwFj|oa8{IBDkNym#IPU z!OWDLkSqMgJaPi_BZJV_xDNOGU!{d}ot!MPRye%c2zq8;DipC7Oe@%ZIeNi*Yn15Z zli4{8Nv_%DGLw4JPXqJqNT%6gOn2dvw>%LlQZCVcpsP0&Y=kp&SzOBf??&Gou$5H6 zA*OzFb_ZTgk`~C~$cuc7=)Uu5GpkBbq4WQ^0NiOWU`7K9b8|q3RBP|bi9!#3KVCbJ zM1;j4n$~3c>mqcg(t2d#>F?`DaP-}YHxY}L@+b&UHc`h76vmKhObQsqnkpKOnKaXq`iQeK6gxbwLly{66`Ib zjC86xe}#>GnByNGF!ESfdsoH!es>Y$z$o2mJ)u)RK zL+qfL87)W<-sfENa#Z|=@oFb*&@Uyx2S%?~D!-A}B5)udL$nt#jMUf#;s){xbXosL zdI3jQe=^(4t*LypsK4G%E6{pa&p~2It*I}ph13z&LZfA&+U>s7@RknpTqOwq0bbD| zwP}jgr$en%GgNh&450Y7vCd(5(S)pprJRD9e)hT_mWl`lNbv@CNz$V`=IuS6R`yYj zMx#a6nk_8JOfJ*It5yJQSj{VN?|t7hM7KWOfTLjpZq=cE ze*g27CZaxzl@K~64Xxd*VF;W-&mtin<$S#53m%V;r;jG z1{jKx(_8BqN3xgd1%QOw7gEVUE^lMS=a2z8DEbcfXpL#%J`QeQf71u&PA`p z;+Fo3>ndlZrD1|LJA0Os!M{s*$Ld7i?D1V7zQp>ZN$-=PaXaKQ%oLfMl6CF*U#`ix zdmg$!fz{v&Oy|?AT=o!(hJ!&C+-78ONM4}b@-JWI=_PW`n>Vevt`CX(44M`_Kq zX3Z%1>5>=!m;O>#p~}j`6-m6hyb$1%dc;&UN@l!_L;odLq!?GD{JdNkm(ghk0;gXP za=*K*O<3#s&>Ngc$N%l*MO#$G{Qr?;G@(i6|BpuVFHPwGF^c|wbD++`+9^aa|DX&h z-4k4qW52rf;&lrBY*gOSqX6X;R`HcceMs@-59=3y^~gBG9lN-xobtL4bq2@>ASm-G zw=YvN4TUv2rZ%+1OXl=HLz*GoKMVaw!t&0hWN!QlgmWbj6Yu~Kh1mEIlhAlZn9Ws` z!d<-k>~bs<|KwW{DuTk}+c+Lg#gGwQFv3!f@lae8`$6K>p&-16fwq9%h)UEv-Wh&kxi9t2Ws1=0JDB}Gro z=kdY~TumVfNapa7k$)d2wAeC5cfzZZ=%{R$t7OEwcT!h|97%RRjcnidY{}Oq=sT~+RXjZph++XpasEF~LLiHP_80)b8ul9O8DI*Izjq>9Rq6y*|YjJj7 zeJ^OV-$Z5ORXUX%+8Wk56jxl-hp&rH=*Ik!VC)_3(^$4anqalsN?&pOWyEEDOCmoE z+dJS4)k~_3JZ%rO|ITnYoKZ6}`-T=mo?#wXH}Vsu-92ES((#DbdS7{ud3oktE!i`X z8|UN9Z|N|9N(Vq1)oj!PUF;bw%+~jtPN9F^WW>=oUV)HB{eZ%~0EJ$EWCey;$)Zf= z0g;2%qI)!T3KnSGg;C5j$!x5VolA6zj`^R3rme7X%iS z|BWMK2zJtBgsLZklmUna*S$IY!R`z6a9KKi*=U=m;jU#=2+A4?jOsj?{DXYE5Mxc7 zf9>A`7bF8rp#`v7=5r2Puix*xVlRGdqm9D(rZ&MQ9I+u7k}B55;+8K~H=Z_u3{u4j z29WOuatjrs<|`{j`7!Edx*mbubJq{*{J*M8RbJ`M-dWkG2-)M!IQS(6q$r|23C2r; z=5PMXGu)JAP&Dq(L(3wa6IKxZ?b2}<>wQduWhIw2{{c;Gz?UjnLkR9x00{~l1P=l& zNdGsAhCIqB4^4>IrlQhnKYT2!5ulm7HB&J$oPBw?03QD=Ztps&74ILviCo0SMkW7G zHh;3phk}6otP6BZTHvLJr~6sH6a6*hQObGU$UjGF7C~ecqA;Zi55^m*|8Ftxzk=Dr z&@{;Igthbq-)pgvlkJ58*yN6~F~8Ino`4G(Y_J498`^KYSbD4z32w zPz>#=#74&M|7jo(34NvoKF1Di!?z`dC~Gb`c!9(qk*HnHwvG_oJ9 z>RNc!Kgs>=Z^*LETCWnMo18EH@2>pcFBW|%gzYjHjMddW*|bsd_&Rp+cUJ>9#c1~s za&;D#ghNH(d{?j8<$qN^o6OVl_XL;5r&54+>u>pWU+kHyn5g^J$ruIoTvSsWQOPR7 zO9TV5|L!K`wQ&NCcZ(3E7=G4GEuA#xQy7pcEn%+d!DOEyNK>yK6r7wd_U}fnjUVNX zD}$S{ncMo`7CYo#nzS^A3WYSmSCiSL0 zo_oHfoTX6x)I0pI3T0g;_xlKhUm#}yv3r9}if=x8@M)C^RR}1QA8e?+p87WiX#8cx zdT(y!o=elQjUbA)SrEP1Jm7|{$5^`@->0HbrdV8BS^rmh<5aSVTax*Y%hiCT^8vo2 zAIv_3Ke~(eKN78L&m%1*=l>O5w05F~!}2C@Ug&h4%=ELElPbv;Oa^yL($1QGESd?HzAQN&nZjaV9Ak@)W($@zQjjIRo?1fjaBj|PN$ zOXWsfP8OakjrxB%W1~45HD`IcIgCEv%aEJafcy@Sx;}Q#bIda4bZ1fO$#>6DJ=NrZ zO_vaT{VR;%li1~-RTUR&SRw3#sBzSep-XC2#Yq^R6k4U(7@+`fijS%;dP-|MAJ$@3 zW<>VJcih24R8hw`UxAK^-{vY6GAvrF_pe5I8xDt95TDxj)yRL+li53qC zHRL@^a2GoP!jy*t;cw`a%=n(9B9<`eCn*DNUS2Nfs&1hdGJfC+itPuQ$7P7PYC&co zTnCwc`{`Wnff@fATPiZM zsv_=3y5Y5ExBHnC%Q}$atfnByount$HlxDa(OzdV}n=C=pA_X%n5`x}#t6bu1_6>@p#rhfP>3i&FdocOg9ZyCJ=MH~S zYto^KpC1aac_Y~V#QFI(inmJ?cO@;<_9|#vesIq!A0N5xU*z7~3|U(e^nRWaDn<4O zoM2_X+2GBDm`KvJm^wzlPFJv%cpwn7sDDNJ$Z^=O9x=KTnm@P0yKM6?4#!;c=onu* zx%db63!Bqk>MA<^WcAZ9PsDXEW4lh|n&6u9jrQ(vY&Cm+!}S5cUMr#-v#hL4nN(3^ z@36RZ`5T$vJ6-+MM>fbg`JI?3hHTC^hCavd)~_i1=t;TT4%g~bw(=UOiwrnYxVdGU zyOwm~b$IJ;$kN0F4V$c6;NP7LV!EA)EwIkaN532(+AaKK&y$*AI5Av&smtjY?*NIr z<-1~?XD8H7!*}Iv=&6E&%=-N(X^PK*pVc}S!*7R$?GZ3B))jo@<&FMb9)JjFG_9Eb zVIAey;82l2wz}KC*|>l|Ql#5>kinw(fUHmnQqxB>8{}5-R zYd?m(<$i&V?Oi#-`J(KXS5bcVItwgqVi_M{9$WJGrywl6!|cPFF+x1QuvSBh z;SeDFBi-{Oa2sJKU;#IdyzU~gmxPe>n}}ty{f^mq-GNy_(&_%wIf%V5hs`@@=b>-A zu*qXE8%?ck#|c}U?Hd^4+LabNRw@-5{{OY4vWU@=D_*9J+%iKE7-VdpI+JoD*B0hYluWe z9{Lp$hP|5aC>%(l*)cusXqG%Tv>AB@Lk>X^t20z_z8-gUf&2^t1%6Q)O;&Vn;K0i_ zzmsTMr!k#q{QdVbLLb9he`qhn=yJ^4F{oboZGU{kjE#*e^dzv4JR&|>3OJA$2tbU!96Yp^_+yFR=)B)ag8w8wJAq>GjaE zA$Y>O$Iff554)naDSRoUCXQP*88!5IXo5W#p8(eGxMec3vGg6yZCP|m1)6i@`iFc%o9em0A-LHUWVz~@ zj&YMIliPu83XZYN4&0yl(XH0Js_iv3L}Rs#M>56;GO z|0q#~zRFZ|^EL@$(Tm;hWLP7O5EUS6D_53TJhUVFNnIqNmf07RsWu~(ip zBZ}v~hIg?%;06UBD$g@I9Yvt>VG0D%CbHi8gi^JWWDva0AT5mC%-cj33(T2;}t ziLKzCwb0hhT(iIZL-ejn4%1sxQ;BE@kSZ0dobXvEUUU(lg~P_B`$fg^6?8Rzcf>jY z^}nIC0Oz$^mHZfDXBH8sLnra@d>#W)fXl>NRWhrC{{Vx6#CQb<@x+K_50{{XhXs3G zCmug=*iaWcNO5tSH6v>0(lV;5LN*w0!DSm5vy7Xh0hdz>h2Z1#r}^ok-vl`%dCI&E zmI?YqrcyNwGt*O?y|hEt8)n!k5c=GqX}K?d;~#mLRPZrdCWTS-eb%@hsOCL}Qe&LO zO&UFYm`UNXa|h=H%*=+u(JRmQ0J=6%)wjClB#PW)oSJ;CpTJ5rjtzc{F7`?Cf z0HB^m3kJ2sP| zr!B~OJmH3T+xAJ|GDPvD)9&5a4^#~~4|S)vldrJUAWupgR0!irtx}dP>>LX!n@3HH zhc;FV7P5Qrn1&R3(!oGBd3HZ;+m!N}GkfX7&@YiPNIOneh1>q*>E-KeGhMx37UGZ7 zC@&s^35K~QGmVe+JKMQyuM%icT#4=nB`APLfx`Zg3*gHU)`X*5CiztI;@jxkm(e5*ZvaIs z`fIp;E)SUm;>p8UkNs{ys?8Av4?7NYRcQ3oa`+IOXtDAy|E3DDF;QUhDPtZ!b$nkk z^xP*a^hDhA)KIqq;l{Fpo$ZeIqJylyy;k-eYuLJ1D_b5M*w<_$ve4!L-`eCw3ej^L zk4nU40H#HlDnE5u<+knWSL+$@nPHp~GRqxrakLhX^>Ndq*{SIIeFR;Ee3Cr@WI_dZ zYt+mW)6^4SW~Qve?%Ug>s%}Yk*|K6W2e!JRj^Zs(Ce;^|R$JG&*W*6;dhI`1mV@qO z4?_7k^Dig)*JM9B>E@kZd>z!%d`9`lPWSu1**9s`#4&1RvI@52g+e2}O>d?_}MxTjUse>*={{1NT>fitsJwK?gKyH=3`Ef6|?T|ZojF+QzZDsDML8k~= z;n#mdl0(ZudYTX6h1g;%evj7F%tw#vPRZBdAFy&trW480<=R%LaW>=E)KAO`3v|(< zrAa-z&5gy=?xuwiKU2%v$bNs!b+rV2WWlhz9iXX1a= z(eWC>^zLNy@u<{a4+7@z1&&!L#8!M(gln@Wr9EV|Q13&T4_`0(186EfTt|Mi^S{#+ zC?BNNlu#7dP5>HAbK7Nm|AxMHy^gHci8;*8pdsv>x2rRsXx5u|Rlie2m@NTZA$_e<>Ny`isja z6u)W0{v|B_ZVD^uvEseV>Bm9q)-Derqz;60&djEntg^Pn_4jr%a;I-%o!Qct2n#V$ z5YpXFMmtDc!JIk;TL4WN{N|!3c<8da2ifJtQRMe+MYR$rA>A*7Y_NX1G-hT-%A4ZO zgCB%@6?^`KfopQ|{5EXgpV9hxx5qlk9Lh85g?*o4>%shVFuAuQSy^EbinkH1CXQfc zp5Rw8#Oc{5#&asq$FfWy*?gMG2Z=$iWaF+jQGEAG@LwQy%;J0WN~Uo4=3UX&61ur}pSIWDfU*$Pv9adr1At}M z@}kmhKepAs~icoT&dT{%fJcN3WadbFMSep9Pd%#+>sWX3nO6p!(w zwT}zdA$VSF>}$l*J(qdz2&##+c7g{)8>JU^CY!zgZAwY#;w`tZNo_ZSYpagIdSPRg z^6+CtGo?19+33@3h`>1ajP|wAOP_Dl54HDli;h$@%l5}5u(lD7M5Pb}0SHOKQ9FfIW78-0rMe*es^V?9SGM~tP|K!P~VJ61MVY6R% zkx#J~6KSB;sjHG@V>YQoF%q>8P}qs`BpiSA=gl=o?u`bT?VpM_@wO65NdX^D3JOeB zB~wHD;(9-zK$0Fu80)epCV<;{8q3J&#rJwe zs5kw`NX9Gb#i#qL4*R${STW071BCjorEF>PGKY5ZL`{oLk*fU)&Jd{Y7rP6}U!00d zh6ERs)5FY)pTQ`y(ryis%g76fggc|VPO$7Ri(TQ=S`NpP0=n|T;rOP{p+?_OC*>zS zq-=4j5A37m7f#Js%Ua)7VGm2l&)KSqb;@Gz)o*d?nLMCmn)~*v?pj%C2_Aj0BgfhH zrHZoHfl(_9p-rrXhkti^ZpDiKZLxkCP3S+~pZ#mWIS#+DbzJEC2l;PUSY{km2IcRJ ziXIG#S66&8T(YnJuyIGhVMo>ncqTzP-yW4Ur-+j@?SHgypTU`mx_1QGV)p_18H)Gb zciY{zpo2be7Kp3(2bVu^*-VMA?AqYboo8n!w`gQO-qwRJtQ>YnWDf<@?pj5ARNQws zUt8qzh<6fteEsQ@4u>tA=J3u=w)%o&vsvEoduhxgy2ei)(z^`M!vNcZPqMNtnV)Zb znVK#Q?>gb;Z=I)WT7^+Ky|~2E_3n&Nb6L)%`~ESBk$&@_)@P=0B1wTSJN=JbW#@%j zX#(i%{@^Sj3;F=-3O%em3yI0U7p*unJvpsCAjO0bX)>TLei0g~ZMb`{fYeHOljT1% z@fo)m)B~vqUa zjV0Y|uhVb&`^KnvlhSQ42SdEIQygnakmqq*lvq$EqJrwP-FUavlKrL7C|Hi9%T zDse83Raxx9Q7a+H$$H^#-ikrl4EYv*G$mAjL1fx?j9D3P?Y+NY_A7DQ*QE6d`Bwz~ z`(1!QH~h3P71ENpXx9AbX0rq9kDYHzLz7NNI~3>Bs4nZH^hYDj)gW;pC3s6h4u5CF z=osdh*C!8sPd7P0L!>a`_*YifZ;PS3N&&~ZS}`hGzP|_iCa-+YH_Fp2@dP)EHQo4) zr^v~9%J#|@cntZ{WyHug{Fp2$=#$0RvH6qFW$%BUdf4Z)jT9>l6kh=42<3$nkFMsQ z5xx}o&pZ~75^a3N4t2Ly3-D!2cf>v!itJ1?KeBcCQ`PN!hfI2YV@k4jv|2IS;(Yju zM{igDbtUuzY?F9Y>YFtV?mLBe8TN)xvQV|vDZKuQN*A7_uZ+cM({}x$u9#DVJATsS z#?h2F|AA~#_>hJ%1!+CV!Pm&8&t$l1ukr)VqO5{^hGowdR%Q<+gD;et^zLgnPF$B& zi={d{*^JRiTKtNde!tD>X&{$bCyXLF?#eH(k{NieXK+w_R8EiktJXyMD~P!tNUz}? z30>E3Bmil+ZGO%mSfo{F$_kj`MPD{kXZpkTRx)K1Gs^GA@-t}qdcb5k{K`}_BLBtF zmpr@exRkln)9Sl)vJV9^&!T*N7|WHUw$1&k8N3w5SO2MI3{ZC+&|kDY`+lYup8+VA z2z{OZCt(C6$+ydNMSUZ?;pfy+ehWP$lfQwYsdBAh=fzfxoZ0RZUqeK9)UaRay@uYD zBRp{=jWTK8(mr*Kmrptrc5V;1oU$Sl0VZDgmFhUAduHDXR^L0W+Ss7zZ;kq*bw_Y> zsdE1d>F>F1qbF-8GCM|{tw4x={DP+PM4E918LTm;jamKarHU77(n;!tIA=KvA!K7- zi;nY`$@MK#yetoLHf@bq0v<;@>l!_6`GtFK@_pkKG%>5;hNM)iVQc1H2*a5qp?W7I z0j7E9`lqlLhzdr@X<*UZ*=>kQ#9J?ZAJXnwV2x#L@DIGV?i!A(G50Raj0dEdHuuwe z7rVn*7~|10xpd6%RM{7QZosFUBQN8zxjD6Z?{;H2;9(Ym1f>(TD)kQ3wYU%Uv7t#&n*TFY4b7UiPg)SPDr4HQ@Y1Ww~kV=SA z%{?7;h_efrK%ouLGCGmZ(Sm}q_yPUz&=}-O!~Qu|OA?lIAqn+fZ^T~Uua#*BQbu1J z3_pF1=w|bN+A`&3jJ@qlvtz%pW(Q5(rKNk`RV4P{NnF$AR(W_ud=n$q_kj<(GPJNk z)T+=l13fu7Y5bD9d}8J<5YWi{vSP4IO^%Nu!OHPt-k&e=t!Lg6D6hgyC1h@BD15Ae)$03i z;XxitS!T3+FE0s9@cqHo-Zqx9@G{gReTpw<`~RrJg@_e|T<&ZxWo;xrJ?D zanHrFC~`V#3qF3lPFUOuYU;^8jCI)Bw4&Fus$wqRo~$!y?!N4pZ2V>)bbQYouO}tQ^S63TPskL`Ph3+Bhk7)Mv|5)j4j9&#V!gV`P=N;wX0TDty*i&xfqOG=;Ud48{>pO6z6nHcbGS+hQhSR2uaj{W_YDlVB+}YX6%=1lyq>3BnHs`QcnyJ1Xmiq zuYOu$PdlqMNITgc#fg+*vw`>Y7ft#U&lEiwO^I4@2HKj%pdA-&J555*Is zYi6>a?V+43)l#l=dlh6nVE9px{)6gLE>GboM3nQLADLOy*XvltULFy$0WnLtsU_6r z!>#l>8i2>@DA_p?8pSeDhTk(yNT4*$puSIkbP*wedHOl$Qt|{MStz*+DwdVqrnL+{$OS1!LL#eH6ke>+l9JnWU_8C>@VRTN#?JZV=k(R7G3f%6*Ed8dmDJ}i6 z_MG_1rljYlgYk0V4&cf>@(aek3fy8U9dRuV89!0aKSf@-`QDzg{)zPNzkMQui5DB6Zn?)?GAw&28M;&kmD}7|+C>t&gi$VlJAa}}PzsyYl?_JXguJX}cs^RI()%_2|Q;nq} zjMtWJ{-XV(HNR1{V{oC!2erdb?oTy1JiR>m)GX;&B>`)C;;s$A^>@|}^dw##y5?eo zB$G&zYJAg@`kBU^{^XM~iTGXg50DQGv z;T!LcIQ-rrykE5xBU^}n(+!LEN-&LrsMshbO zBV{efcjuQD6~UhEe&yJjyB6kE1#pd*5b0|ny3bhvRH_qR4l%$)2OoV9ex14K0_&jjDLL3uM*I=xQ zbZPhIDmvD_?$Hf8D>{O(*(QWTb=s~;94i+`SfSx&2LX%QU+N2&+Au#!yOM>f#UhKN z*F-+d4SvCjSPh8ZLBg!Zl*OB=ZUag3m`^#@81!YyhN}PqM z9lAy|gtCQ=vxjh`xtIyy%>Zb%pZtW55>Y8Oe{y64G$vmF@Wy8#PakqOTxzx>czrr7 zDt`G*sdODFUhzg>T72|HGmA;eo&7=kTJfg?*@O-mWik>{EbXtBm|TUkU!U1Lh*z?S z`t&Dd)-Bgcuo2S?ijA2+7y*x%{0C zo<i>*}b(W#t79y z)vI^DU8~ zztyCG+^hb5&^-CMruFOU5pMB#JI=R17#D^TAgkuQFND8MfyWui->CU41naHd0if*=kN!_je@S9jfOj)Xa(zXfjk z%PBl#hQ*IM-(E!eHJojwOGT%J?62a><`E1 znH;mp8Cg{>;5+8Yspv}Ej|HDTD(NMzqRF?ti}Mb3ikS3Jxf0OlNOG`LnD*n{KY1(u{+-4AhLc&ceXif;iA5!2_LyR zs^&EHUz%jwh1imn@`$IaYE-%Lr9i&qGE0<=k;l~Jz+VrkWXQ@KoijxDhKIcd`>1ff zZ7KA5m|=K5Vp_@mh?wWM46t57&@_G?ODRPkiLn-TMUNZ>of*g0nwLX+`pfCvx+OlB zs%=SptrOeGe6mubSjnEjl<#?Z+H${e<+tpn(p=cfNTn7BQ$P^%Ib~wd6)O+`af&Zj zqm1|#w#P}#=Yv|8xOkj6Wt~{?6nutzc-5^tMIaQYdfwJeZ?O$=1p}8`NJIhd5zM6B z%6#Z%0Xqk7Bh*G_y6vgrLt?=9^$TM?!k?Q)i|r9H`t2hP%(;jx7i+L6X>iEZ78WDRDAI``tzU_yUWI0r|n6iyzshLuVEw$v$CXUmtgv;|vz1*uH`2B>J| zr#cnoKgrjw05q~v&d_mYrD5kS>iN8wFbjeQo!6U;uRp*tv(?vtI7r(!Z?^1Osi35Gn|o<8#hQOSU2J6Emx>H{64~gnfSR8t3?oY(YesJ zsVcof?ltlfEiuPvn28+R_&JMSsadWgi=_U!`DcZ*hleB*nZ()fBgKbKyE*V4nDUrU z>3gw=V%C(W5x$!v_m(>!G@-Otk03=A$K`|0hUCTmbhA8m?*n^ZcvN)ttaHA~WI2_w zh#C$ndk_o3;8olGoNZ(Qk|fN;{h)kCo||-ct{&_P%`zH}qXW%%4!W|~7C%1tMm0wz zL~lNmQ>rKhy4rCDJG>Q`_y4%!CPX+(j~8eOp2>j&Y*G^tbb64D1bKd!R;u_oXJT6C zJ*`*UeP52RdmfZg%xc8vby;2r~;l0=b+YEo}^N7_x<_Daa z{;WC?cu7;@X_R8VTepMR(9F~tGl`dtk`F^p1AZgNq8Z#Qc1GvU*wg7Jm}2yvQ3)SO zx=FI>|8fK$rHw@+^Yp**%Pd&yE-%5hz&`9NZ(N@+Rkh$3kab9ZVSulFEyKhq)$2-d z3!qyTSho4Y?tK)fzK!P1THK5zagof!xE63%$#YoA!_ZXaz9Mu_%8HLS@4)zir_t*_ zlX@e{wS;xjCDaDGv|r{21w@h@Zp$~XNq@K&CZg>(%Ovg0JobIv$f-z4cTZjp%aFBk z8w9!g2pe!^E56^mt3tqL3zfo^(m3aq1cayB=MONCjFe>FInq5ws5KuZ;*_?MInsS_ z0TYu-2u|S9kKT^8L$Ib*ot>P+P}-U;_u2nkkIUa*GGG(MOIKqeMe4TjbTKtq0(qTC zN>k}G?M){78H6+{o01NQ9X-z8M=)mv+VRk8Cv!aGI92>7XVDR zg`hWCW-1e&a}_XcKXZu$_k|xLWE6BFR^XdHqC+0Wn=7MEfYl$Y+LzsLYv_%G6sqHy zD7}tbzqynq$qdlX#m1PPvfU@P8=awqCA3F@mbqOL;{ z@7H1f68ubvCzKBL@bDg7K{Jo9FlpT>!k_f$#DLxMVB12+gDuqdsIwfIH~7=Av$MYJ zh)KNXp2BL41(u;?BgerWv%sA)u0Fdxu_}nZ8Lc@xse}Tx#B9D~I-e}<1^x`>d-9tZ zlJ5$RdeDA1cmTodj1!O@I-*S!jC;g<@AK;P$NFr-4O}79E#w{7Ye{DMyhu$IadmW= ztH5dIMcv%U+KaW7-NU+r&nXSg+CeN=w^mX`OV6RCaDh0#JEu(^XEa~-Uiz6cHW$q! zc@ML`{QIWFY1s)f;qK_NLdpOj>{aKNXq|)WVAX9yXCubGQ0NTVeX3GQ88t&RQ_be( zZ&67bNnevXsiLB^ugOySvRav`G!r(R#u#!>lXV0A6t_ z*?{piJVUHfDYXErhn&M3g$=pGVoKeUktgABC1tYN^Rje-bi5&S?$C0%^npbVx7;P^kkrUKFR!1kk|<-D z2Z};5mD&VSzhnB7`$v<1C%6qBw*(JWZCMm$3~vg#Sz%t89bFM>uW=gPF* zxLeG(IUqRgrN4Z~<#m>zP%TEihj&;jt~bLGRz$l=W~PD@zx)N}raSJJBtWm|A_}l% z*}cB_#5A^1!fooe9!QY#ksuSKUsx(dt_Lp))GcNRRwX%2c>TU-W~=4VlVx}zSSZQjGHE3610&PbC znMZK_4%e~-%UW?<@#UKugxl47YCrv!QZKiF;pW%O88-nA`Wqk7rG2*!F3ReI!PneA zGLn)L$RVf3ClV@OEVWsncS!F%8d)xp5P_a*>oSn&1vTc`ecE z(>v&|@A%E#>od>9Q^AB7O2Y6R{6U=3Ce*OvZzxjh+$F@g{GhHV$aVj1Ry^2Y>;;a9 zJ1W80vL$+3YO3l(uZiBFaGu=}F+_`gk%<|w`{N4+*e6l@@$E(1>4=2FfEkHPZs>3O zI#ZM;mc>L%s$CoQM_sd{{1HL3-E&k+&X=nL^O0Ms&MyddunOR?6*7}(7eL=a45nXVjDEw)p7G9Ugv&T4gLMre~ zI1X%1%UmqYjqsPQdr)$5K>l4yzNye7%Q)zk76kx`PUhA=n^uFhjuk3dN(4xD~b0C_NHd{7A)WEOkw1<2E2((^K*1k1ZF;O|b zbl`?hEt~*thNExPI)q)a&pql50rOh`!2R>b;4~H+a7xw%c?|gc-q!au3{&|L=SEpK zXEjpyX>m7f>iDGy6~IT^9&{!sz}>yq=}b0)0i?PoXC>P3-Ugsp$(Qyh=ewzw=Z820 zIi3ogZt{Fpv_PX%?7DsSnE20kHeWqk?y1?DI)SN4+^IS!$=ry??$CD{>R{0T95HZ~ z5pic46fHco4i}`XE&u{3y@Sr^{IUEeePgybG>d5MHH-=;S#U?#`{*8a&OSz+hX4?F z!4>^{H$0!*Sj#qA337XOm}0Xz?brwqX^IJFX}43hE@W(RC>UBy|rK|T?FUW@?rmVfS3E)P&G<_-adLt$!kZ@GPJ!f&g{4=oislyvqvH;wxy4Z9-`Rl5VoQO+h_InB?@$VxyG?XZ*a&U|^`ZwV@`-R0%Vjo+ zbDytnmxQ8fk#&-ekG54Ir`!P*FZ~bw@bpTb)MCN_+dYD_>l-?>iO`0kmYTn$q2gRX znwC=%l22$#csP(FBlnfNzoh-U_*FiG?W0?xr+;}%$!9>2s60&;eIhT&iLy!h)Tm*e z*=6!Qao}K1>K2Cjy<7c_e?jv!00^IA1!+N6YQ35v8Uz~@r}g23%jC4YJ5kmgmXhj0 zQ0aXY|BIa0VFNfHtnp|{K>`7!TZ@-g4f8rLPbe#7bjLYo+D2whcF>XDsHjTBqrdom zPGVr%tflm5rAZCF_F3`|m(?aJ5ychaH<8g(uJSn^CuI2^Bc2v$gXqE9|Fb(l@Q-2x z>4w?i5yiqA64h@pY3_4f$uPXqs$6!o$bM3RNE2D9D)+p&Xdn|L2H*&Z74U!G#|OMm z*pz5N)Jans=k^y5<&>yCRJv+M3!>G3>Bf@-{TPPH>mPf8PlxX6fikH;u>I4|KhLce zGLb7|=>AYY&(^ID>X_4T6h0*!X0fqHbH9t7aPqGhQGx{fUr2tt88Z!S3e7iYdH&Cs zpaWx42?QTuTA_Y3(h~6}O6nCpsm48BHun7XPdV<1JGn|1E#;bRP`(`DoM|6v8wtVV z$DbWR2&ez07ZqayKCN*)G?D2Z-OdPucorAKdGnk`MRSPEh0*ld{4L5TL0Ga8UrBQ_ z`z{dU3)<{FVyWCC^`D330m_5^2J#L)0sT6Tj$LrId;}Qcn5?6rRn{&xL1ZuzpOUw_ zik2cI=+I^u8uUO86G*Dc>TdkYV!#51yJ{HWhCS^1%8RID&!xJ#!$woWz4y~d&OHk7 zaQW6shW)y)Vz1}oyXPM~5LeA>Fg#?iMZ^3*gqHUua^ZS!p?7#<@Z290u9lHG>_+h*m_2uj2R3=-&hr7s`mref?bZCLDSG-15hAM>h7)YNBMBQw- zY%0Aan};^ZW)E6W4~D^=?E438C4L8~et`!~HLouT$&B<4h)nVJwvnlo z3qpSlv>XHYz9DxM7Bcw0JO3eo{2jDCNwwHSHECIYFFXUWuFK|gSI^oMe2!{#9e#s7 z{LO(mCr>Pr-699?kmgGhG=CKtTd^SZPh$^G67+X0B<_KBajx;iFupWg@^y({5w9oZ zUQIN3&c`PX<(Z5C!E^gy(y-((E}pJ#y2hT*6twzEz&Yu$W;4-zzF3|$7>~V7yDW;7 zfwort!_IRAkR5XXcL{)mAs&3ZJ2n&dK9~~!g@d_0R;BArm$3>g;Mdnv2NZ3$byRM{ zK6JmUEn|P$1O0XNzt-h#fjpULHx?9Hr&zuRVbJX<{fA~lR|sUT{J_(Av&3R_)EJ{R z5GtaDa@nZ8Z-QOZ`!A=?dR#&_#ms%1&T}q%kusr9n$&vVDI4MfKCuf}Pi`$-3~mj6 z(9QRABsjzgCLnzIUs!-;^qJ>>r|X$DFzG&BgK_*6o8qwPtPQ|JP7Q}3M;@7+*#Xf= zeHV_-tBK9J@2~lEeri>W)aG8Sr>}VJj{8K03$>oiMS1!jmi$_f+3{oxmXN*uJpp4_ zxH)V$5i>+xldT6mhW_i!O5}H_} z$@R~v&;}&$=Y&DK1c8bC^{ewR$D^%Xg6Zuhf?dMx?|{d*4K=0m=hf}?05t5O_VznJ z({7fD*l&U`COXVbeK#Viuz7laU41ssi(DTa#kClzv_Jdizd7i(JWxXgT1oZ$cGoW@ zlbt6)vGo|>;A<|2AQyv6Z~j&_NUi{OFbQ&y3Gpn}EZ!`EA zw>f~d?%(PSPpbC^%h|_+_pu)m5qP7V0Nr?%(sf(?%Ot3l2dWNNf%lg9{CSVblYh1J5`H{^3uX$=Lt}N@WAsz5g~O ztPqBs{1aG!e~r!&;K?$-FZ;Ko#3TXG-V?wd_}iCqnt$5^$cym5?E`)Pf8U}W0H6D3 zEI|LeKH;C$TI~F{eY<~ZYy5vXDE}uv;h%4N_7kZ60ZgOPKea&qPTc?ESN}Z+0Rrfs ziXrdI;{I3W`aeJN-$&xF*^nmJ0^W1+aT=ie_UG@9!Ts|CDJR`u`=a@e^Z)k&W@fv; zwhmlD{x2K-=NBCjz$EqZ1pirkf35yMKl0zr`ah1&|A_(p@5}K&kIw(k2K0Y%Yx&RS z_RlZ>kGs+Tt^v)2UdoIMWEs%|1zm8d2|nZe#`agb+sE>9eOu~G;Dz}E6W_!t#DNmi zGt>ySu-!pseJA6QOYqmiiU|Pcfv9WHA7dU<5_1Vd1S`E9oHLi)0&{}tj&)E0^)0;r zrGD=x11Dc~7C?BFvy`=T`lzkbeR^QN!?#DP@^*zRO0Yksom(1(35h|YO(NQ&_pPaul*v0 zxZ^{2ltpk~l!d1C+-I%lAMhzL05E45bRh^_DQfz+({m-$Ds)twT%cX-Ycw%}*?5lT z(Gp!M5erX_t{Fta{xl+eXnHoyu2oOApg`A*9Zi216gp*KSoO2&xhP~s$~;RjVT{aT z`68O{@KV{$%juQ#Y*rGz$J;Dv+yxA&RpjZEOV!^=t+xX%M^IA2crjWrOlq{z22X?b zx|Jq4WL9QR>{UQ3WZ!&Bq_p4mzMh0 zq7CwL-k@)q%6X(0B)d}LnQzk|gIR(2kfMSe$0d}i;2XG^UJH;r2H@a(8axnj~Eiw3U$SyFL}cR%+G+wI}j~V7tz-A!mYl zMAJ7u}jryYuBOyYud4yZJb=^N!LO3>x=a4$+%(6^tsT{gLLpPiSy?MifO;qXH z<+wl;9$DA*aYYJsdt!RMZQ*No-25^uBpV(E8$kqFH_UVV{nDwI27n{eon^!hy5c!} z@@4I3+tmq5;qGT{FJjs?oM68|Nuj*a!c7d7??oH}zq8igYr%*p{NR=i=ljgkru}#M zaQ?ZQfHUDwU~8}g$tmw0k3mi4qu)ka$KeG5dQgXy&cWG`${XKJ11*nj9~@nK?*X(B z^jjA&mmW0eZ#Q)4fhoS>qXIu&v4>70pv%gc>a z&ZaqmE&??|3y5T%*o~DBwa`OL@8uA%kKFrzB_yf5j=h_&MlwcPe8(;TDH|FOXZ#z%n8$R}b;8@{1GTrdD*mk;UAanVNdtuXWqkza;Zj zfrxK=TY)`AV#a%OCg3&(|Lj8ATi*c3)DBElu2THRj#XSnf2Zs4%%JspAJoQK1e{Nu z?GyTx`vepZ2Djc={r=S=RkrvVJC=?zA4>>hOYh(7q>d2~q|~?n6T;qIY=ADk-m9XQ z>08!*kG*^Nk~aHt1srgc$l~_VX{#E|J_p`E<(m3;)#&~4kt+uGe3zSYCA~LWyK27j z%*++eX{6l0nqH>Am@hEUw)aNM$bnn^&qoq~M;r&8-Ii;-^?NsPuCvUh@AMmTCM61K z2`Am7-ylS8dAANuBym&S7J$jq|F7r;)1T-Ce_a@CNDkqKl86ctSpp2)QL#bFiy8TD zCF=EYH9NW&x~phi@XLQiCiDQ^Kb_a$X)J2=-*C@~1JB&iFvXm8SdvzJifv?l-a7w!GC?-{Ma>Fr9c^{mpE_O4DAfXgbE*%;&}0!fU;VTgIhF7v?%?S|6AZoF%yoqEEO6X9Ec9|rOGwD zcnGk0t>O7y(X6P9Orw0qM&-ZD{b!M9105s%bWNDK?1D32WDV5pZ}g2g68U|fFMd4> zZ=~wp2ci!q`y$cryq;zmst5uN z4Gd;(;B~jXuy!Y4u*W0g@78&It_FzR14Z~p5%w>k8qCb}@qn_(wPfQq9^}roVQzvl z%gD_V(Y=a7-0VK7FTv-3{Po-hAP+UnkCSG?^(;?k3$2hc)yDgzCJVC`lcx zue#T^D#l|P_xUZISC{U;bR3xGbkUA^11+Ao7P`%Y362m99>O0z2FkthnDg0wArI+g6g;sL9Pw+ld6plKb*`t z0=S+P4+++}MrdkpW>=xlP9nB4n#*n3y}i`tr_otuiyQzpH7y~N^rw#ppZy})A9ZXa zPhUDjs}TN;{;GVOam@+LI5l{rx8Jy4-)toiVAkR`T??GH?jv|Cm6L^YBF@X3&UI({ z-_BPu+ks+E@l&q4T+hv~$&ZB(^;v0|nO&yS<*tc$nsvenw7*yzI%{Jd>d?$hk3Amg zA2BGQcq)i#R~V@wlvC^XtOAgB<7`quCqkSpJ2tWKLAK%(mj;ceowCedI>w_tY(;zr zUPF!B`=aU|ZNk0Q?ng`b1o6`CwC8GjN6Zj6=lIBIl^pGa;R8y!rrEU_;D)&=TE6!D zc}>(4JCe*S^!diOjb0>|+=_qS1fVh=&KBQ!+`xmS30cy{_uBhW+YRb`fTJ*!0B%f& zYE}5;JQ+e{kT1VOidE+uZjeImzIdCkGP|gYBY&_pX%9)Bx}-q0us+Z2qaD5|Zvz5- zV}PxA*iub7qnUr!@qFeO6Z2G6oc{h{kyXG%d9^NJ+WYEF!-(_SBm|@BHoe})re0S% zOz>-O!j8bZ$$G&>xT~51#xvsy5xMKa-@H8Dg_+0Yv0+#iiPY>UJ z;DFKdF>5g0ny)@=Hnufn0@P$Bm;}sGPU|DpA>kL2a}sLeZ^qHB)Zj*$FLW!CI}H1% zpk+KrNR|4PVe;trhvfU1osd(~f}Km8p#@iVOV7^Sv(r$SFE0Zi_ zkd$JKfxWjgba-0oc+-aDRxI(8Ypk)dSMOIvDg_`m4y4S2Pr%GzF35Jq5g&F^i8&g&_Z|X{-~)`KzRgYKtz+IPiq+Pfkj3j$ zi~wTL6^)luq^o;S6TA8yPwOHgFGh9pXaO86XwuuDv_(y6Y;PNYBYLBSBG_a3((=fu9J7Cbt?Ppq)a0$g=D# zzsxbj@JG!o0+14|ThaqJ`qbZqSG@SEy??^ZXXSvDNV}>iC7y+1) zO1pL#4-YWsl^RI+>(pWOPW8F|mKXKq>AJ&`L&9{1Ogu>r;F?r314|Rgh>-zo&>W*N zhG!0rQ2wK9q~6&A)!K=*YR|eMZT>R((eXD8!@cVmsjd1~h$EPtoW-)%*RtSW$c(hw zr3Z5}S*36(MXcRHXO2S>e#S;$wl5t}+2k#6>}zVVx1At04bi%RP}!CMg*+EcR_Kdg zzzPe&YRqlSJ;1z+=E>H|e9~kyQo#GN2#^%umBe%gB1-iy_NZ0OxgoaUcvKdz6{!M2 zb%-!XSckS)ADY#-9ZlFv*p+q^%S>a4d^1N!TqjU8l4@rOy_$W2XP^P`vY$vW5bK+6 z_Zg_>KUG{jbN1@*d*R91GHa+CMcUIWPs9-C+ zoCx#OK2tW={`hKlmbok<)H1;z-yt_I{hCRmayP|C$`$Jy#)1ZtQQ-$r$Z^Pd!^HZOs6}n{&{4-2*%tttyk8RD)m?qJT!}!A! zd(EL(K)#g(yrF_G`1#qHUm2_UAgS%P#+kUa%*9BFG;S6%P3#|_B_%)JIcp2>ukAT^ zECG>4ZwjHOi9o@*x5Ez4b{AB9lF*;zSn)?BDJBV&WELoc8*vV~fh;l}Oa$u<0Ub$j zI7EBl_f!zxR<-hwbC%RDE9Q33b*@%p71atY6H*iqqp#u zo~`!*U5T$C{c4RbZRLC2dA~el>XF{Z2sW;U8iIWut*pup<8e-<;yP@%;g#3kI6PUx zGCO8=_FC=iNZRiU9^s>GW|@4yK-FbIiUj*GnI`e&)D9a*Fg_K~-Fdt;e;cvz}w(R2zthuwa(XQJ}#JTCJ}V(r0szK)cK1S?`WK$$BS zjWe@Zz|z2HnyerIR<2RIOKmHJ0m40~qFaG#aQ&zgXWG{Pgu74DNfH-_QdJjU3Oy9J zQ};kQaPGd882!S&BFR(Yc#;jfh>%?K%QDjH%w2Y4>3$>lB!Pja#X`&cQ_Gz=;%X zvmP(a#6~Rr@+K$JW5;aiA=0MNya1Q>QK&Db?=5W)Alo@cd>WYpve$pXIBLU*d&J;_ zK!kbVt-es*3eb3)ZeAX-I@50feI^360iep*@=MPCg9b}9*~=V%8hA${J8l*M=;WI# zL+8@F^Q$WMZyhsuaFPL%Tl3)9yxZty{;wAXcwv)qIvpms=<&kVi5B;G-G2By ziz!`9OzV=6%MS~h0Se8b_{?+Q{LHK*ZhwO` z!$%laR6o6$DbgB|8T=sWsR7zGN%&f{FITq%dIs4Cg5yd+DOx_HjDX$EQ&>A}B-Fd8 z$Hv3?%CI(^AhsyzMwsXA+@J`XE&g>}31{8~uc3*=*|+B(3t^XZq`Z5yVHvpe1!J&g z+qRhP;r;dqXy8%8N+VcA$l?YaM5i(lI*j~!7xLa+;F7#RUmhY4{;vHDgzA3i47Oj# zhdo123rWsR(5kkgdld}!@d!K7Xi0>d*2spt z2Q{)B=FA>v;N}O(7==Zq4Km<9t%*B|SUc)~>2;djG~o4G*G|*{l`EE!v7Y-<_XVXM zHb@ttH={Q%AeJ;fckmR1Hz+zE@psz02Up)bOW7Kl!Zp(9m-RTo``(C*Sn@Q;&f|-@ zaaCfUGmi5P%OTspWM~25s?sZEn1;OHW`Hqwwjg~v?N1bcFZ_V{MVweGfvKM@%7tgS zXq+cx#PR?oN3Ee_h^3gSdCs}sya<~o;%`s5N(kONL>As@K6AOjclTH=uMC}7Xp!RtM>7>_K;G74E{>vXS)V;R~ze%OVRN<+wsMLXy$DG%2AA-~)g_}wqr zzhi_?DX-s2*MiUSriU=r&u`q&JWnV+ zmZ2@}Pe_SW`7XRV7fKoEQofK|cOafIZ~l$N=>og*^9bve+2kgGRssKL<*Mo$Nc|z- zELZ(jPNCm(LD`$^7BJ^4D`y_Q*W%mOPW%rnb5nY?jSZ$h~N*54o_5+ZeETOwWf~p`H<~z z<^@Av(G6jmrWAVH^EdA1s`Oe&Bwr?66E?{?%&i67FKl#IWniT(NN%Zs&b zB6+#THUfv9kPeY0qC(g}6*r+^pwcHq%E>`KG{m(4JSvv{sL4CxROtc8(Fs z+Hv4nh(R^`)xqrD%dcW(lO$8Gl02vhzW8+LL`pYlxdlt*F_<@4j6IDMDq?Sk6-Is# zjWAw+6LmZLxbMqK1)clMQB&P&E!Vp5%Xu=%^toGdHXic$3p3HL&6%30u!twqG^j0n z!S0qT>%S5g>&a;^gH?TE&Sg)qXdcYx9U!Slk%DDDbA`~nBm6mF2(+{d@ymS6io=qy zvun(35H~;MpGI~&{TLIf61AY^7ux?4sM(CmkjK(TlA({r&m&A@m{Jko?5r*A9tyQE z80061bi^l3xtslLL^0os6TBt7=CDX&YDCyO%!P4)`<~Y|Uy&hYYF{KVtps;+bH8>_ z0IwQLis^fx2`bhOS&+WLG1h%5>DAa8qX}}&;`fRIR^g-_RdQy6S54kcAK+9$!uzE*K+)rowE{2NI4CnEEY}Tkb zDMBD~xu*MuKuvV-mbD;K(RBDg)I%D6`bdfFzLp4{VDa9FgM?lwpaRYjz}en0NI>0x zicPX3&>crCli;E-VXq3x7TDqq0mL`xbk(isTqtvg z{?^n|trZ}Ia)`iI%J-) z%}0V1`dxVlD3u->glL;3vYw;An@k9jqdPhMFD!uGx5LQp)w*vHG$cUr8$ovm>v=9x zoi?>lH27S%+WhtwIX?MyfQd$&yO570z`Iuu@mtzaV)B(i_nHeX@$L1dOG zJkIOTL!Bv`6*w>y&-g3kvj|8qz8qO@O6G+$<`DKH&$XDmu4Ahpsn-df*bj={d^xfb zWguPD`U+~C9P`3{rwSH&+%ZFya{6x286;n-e;oj@ItF4ZQ@w=Yit&jYY}*e`bXH%t zpR8Bf&Q#CEb#|GGFyEsUq$C3iJ=rkj9d`y|fZ_yi67t6mw|aTkDqGZc(XwdlL+&yj zwyljE6NHQ98l8Y&qhi4x0P3M3$ITlLTaxy!=JuwUjr0jmKe>^(6 z0-}B8FCfIWM7^CkMV5F~QavU09?cXxSFtQ19I0`^G8kjK} z64H1)M5QJ7xM(@6Y%-)C(c#j=g?dwh2Br3qkn}HnxV`RDqe(Rr@2_QCy-)+H3l>U7 zn1teQ2(%tZ)LgtF7;;ccEkI{|l+k~bR^F9U$oRd6ELMw)hTs)3-fV;t1ylrSvB9uD>CesQ<*aUHt^$agFk4NXTQWUSpglA{VdI zOp_k~srijjs*iUbTolGNhzhq)TVXSgej586ir{#x@;WFk*6}Ra_$4eJsU$3{lr4yF zy7FFYd4S8(Tdt!kn~ys}hKw7JLgT6Z_Nw*;0Uarw8rGY+^|VBK?f#cvS^6a(^k%_b zj^s^wk`~T@N=R;b1n+d-8~1%3-OZU2cqd^^NAhHcI1XSN$H@*~$11?#gZ?prXrs(4kUUW}C+%YDZJFVVy z$M~t*u3h(gp3%`xMg`Bg@$p9X5%HE%+{N%c#!)dyM_G5!`x8knrQs1kV2O=9IBtad zH766-=h>5Oaa$bXyKJW(sg$jLt&`6tj!*ki`yRy{u~}{6CF=v3nKT8y&^)sVFySsW z+el{TXFqt@)`81)Zb~B%8GqP(dK(zh=jwHk;?}ypYIZW&V0!$@XJto2e?Bw0ckw5X zoftW)XsoesV$CXQJFc2p%rb&x4_jI6^~~VgE>)R6^6eRPW%D9X&Y11jaFtyAZvK{E z_U07U22)c6n+YYS$n2)Mzcy7}X?$3-L^>9s1%%+ag7^4rup zPH?DRJGugDLH6qQS?GZ>Y#lADt!VAkz9&}PQArnAsQU!lu=!9iYUtDLm=ku*Gqt!svwtj2&>&KB*6}K57S_g+Iv2CiuOMzsZhC zs4)0h*Vqy`JQyWEz0jf-Om@rGORoK+&SPa1nuoYQHRjj>9(2g27qkEV0qjxlZPUl~6ZVh5Q-?uD*e9}o7Wuw+huh>P@KNNh3h@LWCW z$o7+B(>?SU602u|ZzUz-=VBhK1P}93;#SWJQ2)jX&rMzRN_=kehxx~jPh4BOf(pgq)H z6&YWb)Y4>}WbVHnI(SOmdae1hHH1Atr7s`RmSz>mZ1+ddxU1G%Ul~=s(W16Q$unQ& zP;jxe#4u#80HBJY$FB6!Z%&XSdDejwQ=%&gHuE8X)F9l>k)BHy#F|S2C-X9{ga{Vj~y5O5=C+5plee9=@1yi(ca2Q31rG^UN~t(Mq^xtB)2YghFK> zP!vm0hym;7P0^k@wYtQ^G=P~6_E%Tc9HMG)dYQf0 z!gq=EM-T5OLJE_#U!@!zvOO+Kb`}6hzCFBo-0KyGjs$#!MRk1KXA|%q`@Qp7geQe~ z#13)JD@_pvL7=XpP?w6fPAT>WqHh_s=AxDp-K!~yy&NUd;%0W$OC~wxBbMNBye@z! z8d+#>^N#a0=)Gi8+OC*d^~{G84I@Ei)ud~4)WFxp9`Kp3(3CxA3S7ouEDoNfLw@OO z!FpA<5cgvAfuUgW+VSj3d;}92{?Ad7XAUgX!P=wCPtdqKvRmBGlyy1 zv5O7Zu~*F*@9BZ494j&IgzBVKA0ktw3>Np10I7~V<>6e);AnH)9vzWEbAXZH;f=w{%apa}Ze<4HD^ zMJ(B_L0-Pi)h9cackGuLElG6uuNmijJZM`%VQfGQM4-o0r9~|}Hmgd-C;qKlpBd}T zlUjQUU$S!_JV>?beq5t|w!fg0ou((gXQ_(0REAKlwbMI6jayZpq=FJG)UjQUSK+Uu zbe$a#HT?Zj0S)I-50bC+C5FF{^dl+?YRZ&>_UK-%vfLb<7|~%&bEhA-A06U9$SWAH z?o+GxWgD?JHUq)YPrfTZzAB#JO$2Qkci_N#Y)+Y~4%rmoE^@FR# z*PaPNx!3&VN&BQjLweE=G^yDj&+)EQg4s$m@8(U#?eqA7Xtsj&h{nBPmw2V<^>M2M z%9ynI9j?zmc$5*Q?mzny+b=Vt%tJEq8Cu`n-1?Bv-GD)w&HJ|Icb_gAMjwUjc6@N3 z@1GO}Q&GwI=3r9TzUoM!I%X{qp;|@8BX3)w7Ah)5nt*`G6F60Wi8FK&(c5};fJ=4L zpEe&~hz~EejdBW%{#7>*_zZyp%02t>uOwWrKRuYRsSJV$%0_W86eypc1hlPU7Rp<$j+3DUUr2&2JhWR^6k+-7`k>sh;duwF@=CbdI+wob497Ct0m%auyhif?wLFQF*F*^9a^bGvpoLKW9~h2w%{f!Y4eFrW zjeB3>bHUdz8#nRf%gE9i$*sku!%3)CM!mEH=%)xIfNAV}P_`K0yp=K9{SWTmGAgR? z{TrscL_)ejB&8b!=~B8wVUR{@=n_FeN$HXnNg29D>7h$vXc%&6hUPiy_xoS#_uS9# z#k20U?iaUfjW3uv`5rr1N zC~j^5xc2JenyWB3(UOOpY4ng@Sfj>*_zt~(EMMf>i9~6d@od(2hfD93!~D^M+`Lp{ zzG_EQD5}NqaRNYlSocC9T&4C3e-S5TRriGruQa`m!+T}vk# z#nQ-9Qup`_sBeirYYj0BMv@xRds1ByT>@aSV-C}S(**|{=SDT zus+om>%mc#6xNU zwR3Bf1YFqDn2aItVL;*WmG{)ES;p^BEmBcvCxH z&|_E7K*r4J^K{3OgmIpQl$WhG&51cr9tqM|fsoan5}G)I%xjP4ljpT>54C2lW*?j@ zzj$rhw8@}7{&94f`*lvy?KY-Ki(eWcrP3bX*p8V!utyFpu#K8-1(#iG*xMlZDuUXx6 zV@{jn>3+JU%hv8haP#2cyp62UVxME9#2Bx5y7k~ii0wSiH8=Q2*T$!9T z@Kx5U0QWYLa#s)wfcw4AQ85BelIk`PhOCWbp11j>&!mMTgQaGsjV~g8a?d$ho0;a_*@o(_M#-dIf)5uX(%`yG}6M5agE4{3j}Wq+0e zf<-!us|ueM05BE)qJ}lS28JeoPQk!3^|M{!x7+B_YGU52KoQM7P@O*6!|%5_tyeJ~ zU)Ao!Zhb+UigILKVT8}hthy>bJDU1i`p>;EpSJK0K5J`At}QQhoU27fVfrg{$UnzG z#l*n)v;e=jdF{g3m}rxbW+NbY(PqhKkuHf`$W(PftVzMehaa1cLcJeDGD2U6hqY`O z^l^fe6qa?_fP5SgpP{+yiR0lbo6N9>Pu8Wm}i07kUJP^IjYvMg6$ z5ICjcL2V?nT}yNzcJMYWi<~@89ob?&xGTSOUq?9z01Z1&N&4C7kII)eQw%!e5LB0Z z;RJ#~ciorhbfTloR}e1+YGf_$)nXnbr)61zXcY51cG72Vp96s>H`J|YQqWa3b&mD| zg-;KZNEo7@PXx9lGZX8C0@%7sIZ6(pwbVHSM`aW_8|QTeQ>eX#e%Ja16c}%wL3eQl z=a{JvH8R`Bpd!K$E?k!3I~EP>RK-hsY{O?a9`$?&`kvBd6tawdblO4?4jeDh3U*I^ zEV%evR?0)9w`Qk*v)zgZiS2C}UF{ZICwvF2xBrumEkLANwf<{g;wan&^2MXJDD9>j zieSIK6@AwFNZKZcG?Apzw3^iVqV<%AELR<4$y*4*#lyYYq#?B3ZaY?F7Syx0x~h&Y zA&foi!gT6a#yYPsRAUtJDXmrzB1rKSP)JC7O zb49$a%FTQ&Glroc7Joh)OHPb40xiG>RG(qYfKMekkZKH6JpF*WFwIBjyzm976;VIj z3V8D64Vh^CGk^Jl?;}UaIyev%5Z^1(z|OFpUqvie$c2>P*7|_$#jq~?REQhzp6R67 zL~CAN7@>h?mit0WwK$S4m^c!4BiVLteIa*#z9s9n*4lFfwT~Uo^@{AgAwA{ZGI2Pe z)SnPP$LbX+_M%~I^tffNvP{3Ji;`aW6o&_pKL=_*P)yhSg3&I*#CVVR;iBRtTjdIT zLE;kJoEE5@nkYfDDVKUwMKKAGT{m9w*bikLkmV+3&Zk)>5|oUowlQ6|s`1Jv@8PdO z!VCKoN^ih+7q4!Zjkj#Rn> zDo|KE_v{xZK~2GBE$-yvTqUfv$aZUi(etwehx3lgDd&UNvWj;JrF-zPE#HrBd+hah z9h*5BGiEyIuHc_Bi($X2E5xs3`b46$?&i{~vE~EK$VRUH$2O+I%Sv{jyIk^-f{$&v zWuzTNn0iSpTiGkf-ZEBl2=}5aTO0-PWFL!<4X*=Ui`gO-7YQ2S9BEk0*3an!3wazl zP1aM$kp(Yd*_#%CNl4~L=fvAk?z@bU#Dn^y)DPGZD2l{7J6~%UC)CC0QYm4Pl%y3m z8jAiLQ_s*JE-cJ|MA-chHo>0A00EY#QCd`lIykFLp6(f6(~j*nGDG9Erin_%UAVX& z*~9WgbeB^c=c);bbFNWf%>`4Bt~QEY#W&jSr`3NstZ)!=nXTqzTvhw^L4Hf~j8Q=% zt?gX1@KQx2+}{`6>41+-`slb)d0RS2!Y#8oC*Atf1xM$mof%uzld;CDdlFfFbh$Yp zZ{}|*sb&d7nuCeWGMsZ#eLHN!CsuscxaUs7(mEJaWVg|m2dt!e`6@!%e^FvmGD4* z3+GPJFnKQBdq7?#dEn;c|FP0bNE+@mR+*PDL@F;=M9K6yY5$lI8!>qBl0_JYpZ9Bg zT-nI)eAH1XV4a& z(v)HmGLMNe3?o^yRN|dmFf_TX=~J9=?YHI}?FKN%K)alN3^!T!{6l+P-Wh9@r_+|# z3&AyMS#j&BmN>zbIRjPdG@V{`_tJpWQ)sh?{Yz-WuT|xFX_>dG1#3Wyh5R{%6?DQ! z`b*JjZ6&tbK~|)opF`1ygIy&})xl>L`Qy|=rCetE;KLm!oQj=dAMUd4xUjjamPq8stE*_X)WUIMEzY}prh8f5EUTb0SYeMiVqDU* zLI*JSuMKg(IKqpk@)Hq3T-M>Y?RxtY-Gi()F}nn106tFn^1SQ)qVP<0mz*Du#LPW*7+%iJ_#9UE8~>p-gxxY?(00gW{&CrEZ7@~ zj$3-%BEPZZUESA#-oYei2#&36N=QoEQ`;73PsDv<7mwA0CmX2KuSs^;diSoJcy&M0 z(sFxaZFi(Os7E?t4(87=^S_@l0YZU3nsYG6j zVb8yQcudJtN#$kIF6(|MvxN;b!7n|zz1+1OpcgH5>OQAw8@Qy+FAC^+awnB(xlu%s zzgUlyxjz14T2iKx!nEL)b>6Y>8~BR`<*M2LyRu>io}g(GzsawxXK$=AJN1ezaXjQ? z`yeVtM~#LY+#dB>o`|#Xp>2Xr+I8*u)~SJ)O0^7UES}v4%r<-)te)Kq{neQkZNuXN ze%X7t-=o;V7p*Z4ln6aKX+FM^IZO^8g=mGx?^A`ZV@HzUK??_r`cAJM?}br2-Y+5& zVli`k{}u6Or+KU~tsI3`E;Xo{G*_luNS-GS^`d|UejZScOTJLg<|Hb91x=>tZc%6;Ul{oP#P zW@L0G))==^-!Z`Epp|H4J+qaVAfm}amPKY?rI-I?o0~d~Rs?8sYRi6Bo~@HO(&lwl zMuiHYgl;r*=3lHt@=-}To6RyRTp8>&z#AlI{1c_eGjsX9je|LEU$1HE8Eq?Hoz)}O zvcb3dHE^B+?e@D*h5G7D&I?7#JjUlK4T7-N z!%90|O@PT>=bWIe?MH=KTP21B|YW=1vpjk%u1;{^R20+()pXO}z zqpcje8{1*U*!XU;9d=WmCsMO@#bNy(8V+#h1s6JeP^r)((8243o?&OtmB5Lv_lXb5 ze^M94_5}2wh>xd8Ta>>v6tU!LBh~fNx9A!yZi;s0 zmoHYaAH7`x+tww|@^38w6SCo={{3PwHh363!wWP`aiRz|$4so-1T&WL9@AO(trdnB z(uksYvy#baoKfd~fmGjj?1K`a(`(P3;9FmesIoaEs0;ynR@l2oy?66XzB~Pul@By_ zDAJM*DEpjdGq+9}ogBZmIPg~GwPgYgKc6DfT9t7aC%P3na*oVi=p;PlQV-PJ7AWOt zxC&MqXO6#qwH;3ORIhmX<{}z?JX?iY=n^BOGfW&9|CRsavHovRou_I)pe7{AHG|WJ z;cS$#x^cNf2sYu~gY+=YgP)D<+X9k#30deEuW~Eo zC6Ct)H9!gaTK47D@r9*q(Ey&g8jRKcsggF`kD=*(Eb9fh!=K)Ad!M|0|D@+4rSDWs z(j}NMR}qj9c#47k;mHzQ4MuBklTCZ#xf0Bv8wa!o7g)O^jqwEDsc8P*_OC=c+82XE zy3{FCns~-kpvGb;k+Qe0E6X>9PSJmwr6z!mXPsxGCVg*$(#6v_WP^*kZxm7JuMez2 zLpityP0hrdUjBdDath9X5nnV=EXC9#Y*Z%`bm|qU8{Vo@xG!E2v(j4t1w4NSRDl6m zi>?DH{($Qf2A`l!^+K0uAvfZ{lZU!?nwUO|utmOq2Xy&8%O1!_dGTA07Hu)&`0(Tg z#j$6a8G>1+So6s~K8l?GP|m&u@_S?hFFQK=1dH8{Lrj0qz~_p9!}O=l5q9%8gF5wp zTZgu_fPN7?FnEc;>M(F0HvCSNMIBa3PaiVXPAbcuj|WwnLGei2b;_D zEe)W*b9G-f%{O`j6`_n~ZNY#$)j$!nO z_CBiE?7@}7Xmwawp3m+$$5-dlqes~cmoIQlbg7Ri2jM@lZ#$Y7+lUWXsv?_*AHM#l zq4eGF*MKAPLs~x9W-d!qyexK3cxy2I~jWC*rS3_eN?Wm&Y{-pv`mb^2Kl z|KWNo!_VdUO}c<1UgW$lE8te6p40zQ<pEgio_qB#C6LCzUUic`~Bx#zaOsG`J)Wz8jLoN=a)W;^ZWrXdFn7Y zK^Yg(4Q)cJM~g&rs=16X^B5s_YCNMTbT%StyYuCiw3y~A4xFob^@B2nFwc2FMA1e6 zb-)2E((DL&_t+V8jZ44tT8+WyFV z*+*W-)qcAW4)+D{LY^5;fVY5YPiL^x zP;tt}o5!4AK?tf(OZ*w#{`X=~>VnRqwPWAnoM<@hw{8@jELJhhffr*2r?)ka`!`M( z>c;8Cqu~*4amd#xd%>K=yPi7tOg^<^MpN?pT$9M0BVGb#jGZO;lKrCRM@TRlal=*T zSk1FPf~J-LRD4tb($+EBaZe8Z^K5F+6mr^RT76*>xVc~}J!S4o2Yk$DYn@DM>Yx_< zkuoW+gFxcoSjKyGQgr3Cy+tqFz*f}%yHoeIRPtlpcDs{_#{n`f{J>hWUQYP*pwnh4 zxI+PPtJo^4^Y@l?zi%lBp$PAczX>r9m65XzXy@hf%=MTfw;!)2bT+NAemliAQei8Z zuCF&I>-x-BEPcLAiq0oQ|a$o99NWG)u#iw_rY9`Y<2R5h)C zjSGMs;It67tRmE-$N2wBG69ezdk<6sO%go=b?1JOQ5kU!pKUYsXUov%;rc9Xm~AKv z9>^Is=cGSNU&sNlW;6Vdif}6h|IaKVM6aHQ=vJc5V?AJEv3i)B{arM?1UnMlAN>w> z0lNvcHDrOiQt&aI82Q5~Ydf}`Q~q)e&(xserWO!T#qb(Vxoghzd>)V|HFj}olq4{_4Hxq-!}WP zFaIKxJbjAy8;)hA^zlECB?TqF5qQr3Mc}Ch_H>oQe-U_Wf2ZYF{zc&F|Bb-Y^)CX? zCqe)rCF)-U9!?qn?u0DoU%VUq;j6DUvw6yqPQ z`J)Q|b!PtiCI2bE`~`Qw}?j?yoR=*jKu8)4IaIW~~~RnPkvl zRL+Ro_m9{DUYD_E!3z-2trpN|4&P8~l=v}7!1dN?gD-R78q*{7`q(Gv+@4HU<1(3n zBNlYH;_#j#F=RSKIRp%A{klNI`{!9dCMfwAjy{I)cEopl>)3d|S8iJS5<=*075&lM zHu@vD(7#^Oexb#-Z#Hd23J+8^?R?+B(zcbfzNqQz*Fud{sdOfm1>1wFdMbfyIuJCo zn%eEf$v(EAKZegQSUab)<6qFbTwqxXQ3JHbZuGgwb9kQv=d^a~V9VE_NS2ubxVN5x zNXxGoCOc2Nl~0eQyskE}s9wGE0C#IW7&2v${_eOh+gVWZGUW!xhpJ%~Cd+A#|94m> zV6&o@5;SFKz&WQInJ)|56Isj%^cK&i6S;GK(`(YZ5hpnHa^=&$@Alc_vbO%FLKiKI z`7FNnix9&_|97Yi*Rh!RDU%-pGDzHfn!^YGqCjE+O zq(!%cqm$8(Q9|XHKyAmB*O^eZ-yTu6&$2Gam?2~R*&oZm$pTF68yiq0 zswjG?p`Ko~ZL| z_80B99JsDt^m zsD%X`Ra4myi3J^lep%SL&si>76>60xHQ6UbZVZ~bpW)WK-}nxXwK;QypobCl40;nvs_6*MAF#{h1g8=-D#6E+6ex6 z2UO&L4xRLXuft{yDn;2xY4$`+Bn4ZX#W>gYxv;q;k#%mDmi53=+LiY$B+)!sY($(4 zS3rM}l%xUkznzulg@uI{*i>F8gET*VEIl<_1{^fAf09<)#*M~}R5&Z&zV6%EZCDRN z;XoA z-~G1w9Az)m5L#yU@7YqZNbb!9ji4iu6z+*RpgZ#chozoo*6TW=>QP^+tEqw|_nvsq zZli=Gg^KDk{&Bnu?15FWJucm0k!7&iS)M`!$ktpPmhJaktBY~GN%k9gf)Bcju@pX4KKpurt+E=hKk6{n66JD}y5%B#%e*;<9dswGd5e{Q zpm*Z|uS3xeuwP)5Oz@bjad6h4`h4D{K7xu6mu?okG3$|CWE(Al!jV4nt?(acAhO>q z#d@GAJRh=G$8+Y|HkDbE_1tzl6^-}cnLef~%UPhQ(ocJTv^BmHc$KI<6D!EbckXGY zi&wq_0;XQfiGf#HKeHw22}dY=I-s5mf1&~Q@+X*&AE5 zx*T66?>;pf6&|Of%%O0kH2edIBL`^nbE8fDMJypno67O6Z&QHlo*={sSin{2s*9FX z%M`R`sO0w)s@(q*{KD-R%95<;2TXwh5N7%$Ks~lIjU=htfrxfQg>#DhStMf^fJ`v$ zKs=#bC_@qm&}{A2vlR+e1+U*)n&-+KQe?Sb{2wPQdJ}^Xt%_nef)ii zGDUhJ=s1w<)tADTL=AC<3xV%|Z3JioQbgRUm(1yDpJCAt9H;(31>Dqvg1pH>kyvN? z6}6<2Fktt2$WA8k7W)sUrwundY z9u@6}0NG6H;=i*AV#XlMn92zW|mt-j-1atWGv8 znaAXJjJ9{Tas2W7J8Aa0AWaQPE4Q)sv~M}u(Ki7h&Dvk4DWcvL)CcY!MzYx}uHGl+ z=knoZ)=VhUQhAbUjOj+!VIi5MEBhSJ7G6$Vpt*Af&5-r?7c`xQwexvpL=D2U)q5hCqQcdp(L7PMO(k0(-=f#W=RKOQtvbX zY=t;Xg*CfVio%eg4y0L-acpB~Tr8mG@YYWr(ZVc)F4;*Js7C)p&$V ztKLW8q`(f$;Im6qr*E&@b?OzUzYU7cr$t4n0W5a$Iqsx6``2lB;qO(@YhUgjVk0c{ z6Ox5^53gFP<(?Mw>3qa05fpU9cQQ7f`JgHK?v9YW&%C*gZmZGTwe2FvO}!K6&J@rg z>8M~I2Yp5;vkMW+7ZvI%7phSfD#$j~-fU2oJ9Q@igWXBiV)%CN~-gbv5)} z$4&>wh2D7V!W(BGf#r@QP7G?}bt9>w93kA)Fj{f(JPAN<981`|`qAH!9lqm${`vk0 zZ7Qk;V}T>UZpq^C8c`myh&D%>yrn)to`(AYZ2_C!6Unf1B)K+I6o|WT*;xuOx?UQa zTFEY1b^5pC@l&3o`Vcq#fCcxvEvR*#w#hC_o4+~mO~(wtltPu-K&T%%xte|^uEHEi zbfc>vC_~Xx+RMNVP(E*ITS3%XOie*Wm;=1QC{3g?;6dCR*!$7_BdUYC=HX$tm|9$x zqi2DBbMk@%buUK9z`=Zx-e)L8?`9iOmxWPN6@1!dFzCIIl@1byW8#Kb-m0@g129W% zh$T(uRh2`HJr=)2ioY?vgE!0!WYJwluwtZM)vtK1y@& zSvb8q{GZj{u+^EO_A9SwIYxO1K1%6=0r+ryJYN3WZ_;X61D3TB5BJ~*K9CqIOxzoT zm(kP0qtC!p9%ttk;zI~HMdLBQ6ftdz?@4svmabpE6~0W6 zpxR8R@udSZq^zgXgv#ENh`KnZ78`(JZ~Uqo2)R?A^=xgne87WxExN>C-L5Pcl0Sb_ zD>Vls_wdZ*H_K|jSc3s~$T@syZiRa2#&ii!9=nlUJtQMk-BH5TTrum*7I&~F9F-22 zu0%I9T7^)hYY>CT1Bt2%chWLa-6FNhqE0_xs;X?hOHeT7!c~9bLR!mbsNVtUpt|tf zhVHs8Iq9HV&OkA<(SbHjzL)SO>ISiCc+5p{b53?)mMNMcYCBWCKlJ`@-0kUfpk!?k z9m(qK*9{|%2{L$sBS)v*&|Vuw7X$=w6BYa&$Y7A7cxtn~WkkM**xAFSMY(~3K}*!D zX}4ih@&+=ocoMRTKK>;z;?^tKqfN^vhg8c0Dd`~wzLw%ZL2@{!6FIFRbdP|Lm5>I2 z?zs5=v|-Xmc(}z;MGk4$^orl}V-NOTIVfU7&E4wAnUQbYj*l+Umde z6K~I;>>?af;C254(6HuB_C%hq`jolHs-L5R!g%v^%zHV73d;`}VLU1~VLNMLW40h3 z9J(gmzCCiFj4(R*ckQF3*~I-o@TkI(N9Yf-%bdX(UCbBi$YP&;UuYXwU^Xo|k!-nsOJId)(O zHcr;b)%YHX*V;adXRrGtff&Ok!2CoZULItsgD#qLPwD4An;D1j7K)TJh^G0^V&A$03sm=}dAP!Qv1Y(6edb9=Qn>$f_P1t!)s(<1aSCHnZ8hNIJPS}V+zv>K3Bxl`)29Oy| zrvNN5$rQGc|EWcxi?Xn5@HJ~}iyI3|4?%y^Vsnl(zMP^W8;$p3y0o`cR4Z5_S)_c9 zvfP=0Fz_wDt5jSU;0er4wfL%6NW-_PfuoDL@*&x15%;a)d4?HYxZ;zD;*h}A9&}f< zmpJ*&d$^TwUcF#*Y&#r*8cd5kKf6`+B|0l^{v3Yy`NX*7R&S?8Cx(_9%iH6)=|j*I zsu5qEuLu**jdJHJ6ZOuNBSd)rK_6WXsG}7$#WRN!DD;AkI02@lGOZ0H8K^7dQe{RT zpB+zitgnsuek`hKQQ7QeHANx#kZs345;4O0D|+{mae%>!i> zN6UMg_?dDlgW6&^VuTH?MT_}FE7P4y;Z9j=F*8D)H8B+7C+9v-8|e;21x@98{ZwVV z?=1^ws;QJ(MsLqB1I%zm;usNiDiCMp<f6F?oCm~=wrNX3E92zdX)}=Uj+Y|QxKB#u`;gg_2_#FB5@-24IB67AZ@?gL zHl{?T8Mn?I=~RAzUVJ&*2Zd=fvteTnO*?G{3(@v&dj%Oai!tQFaw>S92f%Ak!0*Ll z0jQyz;isrmCeAlH^)J&dfCS&gUJo}uo7Yj z7=?TJamBh|mVKUbpG@wsm&iKje`$OVF$GFe0*Es|Im@_xx(%StRd^P^KK~3Ur_gfz zZ2T|~Co6Rr$0ObnEyDJ)ntt;6IdO^Nz5!bcyDP{yTN9Tq-{w8zkKyop-O7n@CgrWU zNEG6P^qK0&v|6YEnNYgu9Z@cNIzRC_ms@btgu9?=)`+;IsKbuDJO?W*$n_p>NAo_%Du6We$1>yc8@1 zAsIOPGkvOavBHo6*i9tC@c7&9G*06CVJ^7sq+$H`jb!$UB>C$*f`i@L;EDruvI<{_ z6RJYof`eJ-5({tzG+5_TELC(JH#C>%1tk;QV60)KJ0xhdTh*B>)1%#>DXD2r9Z;R@ z@^Q)m*Fle240(LFVyTu2(+SGvlpGpiGzH&MrX#ZNfz6jHJPEK_(i9KG?irtPx}kGr zCL!G+FMP2|7Wk1-UAf}1fmtvDV#{C?5~pA7m*U0rq2lD>YmX>iwU2|%a;a&jtOY9^ zP&98Sg$;@uvU2`LNM3m@a0~+->g1>+X|5Z(=lDos1Ci5wg&VGQ6XyxnN^t$m$h#=l z^}xytybo}tJgrpdzV`%tm;FqRKRdbAC3}xqqNl5)32_^I_`(ihv5wG25&aqCsOjJ> z7xi%O8W)gze#inM$fM|D2O%>Gt7I(r(2g5G&d~TlVl@^b)%y%Ha~q*-$JMZf5DaC( zo#Dkb$L$iu=k+73(>l&K#650}{q5i_I)W`%5O?Uj18%dHp|bZadi+ZS%HJ`t0`>Q6z2g1fBv}c?3Yb9U309 z_v#3rbPDA6ou>ec3W4I?XOJm`=bfqcFfMK6!?P2i#PdL`WPtmL#b&;28{yw{)rSZw zYG&9$%r*MwrWg-xWs{TtyiT29{9$7?O&dmlO}ZV$O2BLeR0rY;aNiH4M|^a?b&h~3 zC;C}BDfWISdH%`xZ1~qk`^1SjNqn~|a4g^e+P6n?6|ROnUoAFH45BW5x2v?>d4vT1V zlKC4$K^hH*uFLdC4|^oQ2cYb-Dd&=bH>4#;lcil%D6DT@ZcNH2vALvkr4hw8b zBjoT(*Z5fbcs|gGXfH~={!*)GhhOI7Qjyc~d1=M8_)&b)obb>u@>E zP6b4eQp}#I6DT%;nicSqnYJqS?sep}Mld(LB?~lE8!Agx#_8@x&c*Y$GF{+LlE{zt zlp#q3O`}PA)yyInQJa;&x0_u@PJA|)ot}i1LU+~WDKz96B7*WQ@cI{i?RuCvakpL1LJ9&9`D zD_81p+qva(;RmMcT<_yI=L5C=g2CU9_5*m*>sKO`oMmT8_T!vBd+9h5Wt z%2Q~M)fe*}1CH?HqsIbgVso|R#6t7(IIOmrF?y_rJ13BHJ#<0IbbdAt@rH9UH?tUB zF$BnWS($?@8Vc0dPg+hpk}T&AZ(m;|UbR>xDynCdFuCX0@2!QBuygpg8w=B3eqLraxQYKbeY1tBrLa`w28; zXTEU-!Eh!o?-$+Inf4&Rdm%drv$OeyG}F0@kTn~hNR~3Al|**cZW8>IbobbqD)_K1 zfXPA6bjQ1Ak=BL(uv^l>>%|ie9YF_11?Tuz)T-CikJbWFw{K@8vnD!=4JY%6zJ*D>qE# z>{`4N`yg03pEcu=!uKs3N5HAoKDRhTgwWX}N&hob_GsJ=CGz|$89)e4vUG+<2FuWL z;MgS)q`{JU_Ib2ee%h|rKgLJTshn?s>#9=INYjcArxch}DH~gNU_of(Ej^MqN>991o<}!*1pRdO3gdHefFKNx9|zE4B% z$+Fznvnlj&4StixCEr1^ zoT|H4IQY44OU%+RkV8GMnZn5xNEbd*rk1@~jF;H{H4b$c7mqfayQw?VRO2(DViji; zNxCk=`x&jWalgtW=UJJcbwYD&`PS!GZzF@kP4I3?EOOW=XDUh!Ls$~%>#?%|E<>Es z2QAnH{lzW{8qS8jsK25o?1^|n4s&-EEKC4kjHbF3)WJ-|{kIh5Rq@v|6=*UsVOhfo zCS)GW0HRoMcF%>RPOIB$J}7zEQ|OC~Cik4QEynUfmeEG-eI_}BJwcLk&rec=j=XNw zMH=sf0)arRc`c@c+4tPGvYHi#$vWxNS-MQ$-Nl_&p8LfgmQT1Y1z&D_vYj&lEaXRc zdq;A{NhR`3h~0UBbwuu*IrExF(mAw>0KrP;{K4?b0{>k71R!gV8Ho>m!yg<-A>16# z|Dp}#ilH;N}ndW*A-8-;%n=IueZg@DZ!C%`^vul z6cL!rN-VpISx%EHWrEdI@=k4Y1pLl<@zZ+OO>*iCPNyA`ZE2F);VX(gKJ^e|`xf(| zY(NrsCFe8Bv?!8|)^zQ7C(UiUS7J;ZCjup*8^a;!j^EIJ@ao;kFa+N@vb=n)47MaA zSI{K-e8Nug3Wxy9cPqJDog@U{QAVq*76Lf8hDjvJtWG$7$k~$Fy1Q0SLAXUbA5cdm zSz0^AekYYZ&b!|;EXd9~H}%z)#--_i4U@{9q%9F$^NyZ;{~=)%CC&gVb^NaOWfES( zDdPtnSriQsNORu3Dkpfh()m%kvtD@^$(k62kB|gX^SPg=$f-dNQ~Ff^n>8zhVe$<@ zJISNVyEj#t%TL0E&Im&%zqFAm)xjOKjf|PBnPx28&kxI0v$Wg8g-V5 z98Ziy5RutY^}Bj(^-jr~kDVK$C+NbC%8TQVPv`_qaUaO_;;B*EJW%fyX-Kc4{vi{N z%#|#ekt8YFx7mHC^w#DoK2WHMifPkL;DDCD56b(oqTFdrld#`zqUC{oKy)AN?yHBP z5$8K~scza)c91~50bBa$(?aH#(&;L^UerU(r_{G34XwN%N#nZ}s0haj${^hlPK~O; zGItVQ!d1lB?LQ;mSmy2YJ3Ssk-IUQSuColVJ)`eq! zhif${+kOJMumt1~%`?rUu~Kzv0fbB+)SC$dQw!^?*stHO zdMbQ~lue~mjhxIBtnw#d zopwqn_SEMMHfhHM-GefUZPFUG`Xg1Db~~*c*uyWPaT6sfBo&4JxW-ENOX(V}&+}ho zI9$`g0##}r^#z3wyU6M&e_EA5H$*edmlwu#$f0~V&7&JS1cB~4gM%LrANLf8nm@JPW|;VNLqRNbq7`HX+9AO+VdqBC>K7Da zWB!;5WY5;(~t_;6Lq<`J~?N z*bFt~$=)yK9>#M5T-xCFP1{SS2MpoR!8HIjU~@+l^;c27!IxK$^6u^OyvR7Fe;qBM zj2;>~nsUK|lXd8vch_AkEBD}AJFeKb2oFQlO0-ILeYZs!31ppK?LnV-xp!R&fxMilLU0VE3XLX0A&qZuvJ6yUfZJ#X3nQ(M)4n1P|tPfkt z@+Kc7M2in`w7>Y^wIx*f)B)~7bYL3++h-T4&_^V}kDW{EEYrUhLrOkE*)l2JB0gTG_E@yNm9=c;z|LwT8YXCn{%V3TADkuqQLtijm{_(DRK{yj9e0@Ma93Xo zoEd9e=iZ+=OO96i)}h+k+tjgoVKhfc6rD9)k%I3gV6Lx`Ec2~2)}OXezs9OD(32ZL zPv`MrHwxhP?=WI40}f9UdTq$nV=Aq2e51!(hilXZuT}1S)M4l26#EYADW0jM%4Jum zRt{Y~-V}q+m3*xPVhg&Dn?qQ_4?QTk?&p%!v7JgnKT8$cO|0KUO&eSQ4PQUOQOUGY zQgs)v!0jBdN!BZ+V-xHT#HV44-bjFc!Ln23t|EMk_H|E@q_W;mVVPPEc*&CjK0jmV zPHC=2#;>?-uZI+*QB2uHwAdP|m&SHW?cy3QRVj!`C|;)PNLZ5Iy0Deq!(3)GQ|=pZ zAVk}4H%fl@=@XF4G{i@x;Nk76o=7Wi_2WadZwOY1?X;gDYFWsW=L%)KE-_qM_VtDu zy%{$6psq8><;B4MU$~Qksjw`XeaWPHnIXHvuj@n$t9n>c{BKZ+p-XYn+Le>y)ESD= zDTMCAW%#94D|GLcYmK{d*%7ye%{eM6AGM|;Cbaz9;9g*cHH0#W(ndl#sh7seN*D4- z^J3U*_UBMICl>B;=<#+cbxygAf}l>YC`W9JrqCrN!zuJ6;PBN;(^AEmTY?qQetEKO zu4EJK@9&k)6USR9<1LHDryW-}f31R#jjQ?7y}vylD@rfgU;7D5X}XdG%D#`kG1!^p z*>mX>TYhjuUieBmH_3K(wX{*IeP#+Ozs3LvN$;@SkeonGUJB&3fpaV?*!-5BZ$a{X z=}=JS59Ea)4RSsiNYU9zpC$5Htfn_>eLeL+B5GguuL3zlv!JWT0hhK-sI2cZM1yBe zCk}YaI!heO!vdreL8iH5D>*UJ*$g+)bF61#tMexW?mQio!OoFuY2u@q6CK}4{}dnNN-C_d3bQ<FQjl(gz#Dz9mE4^-wDPOJxG>XJZX| z^-T(+Ym>%qm~K&YsA z8bnQP|6Hf;J{?OA^m*Mm6X)O6MWR-DZjl02GT%q;?H?`2rBDe3Fh-{ofN0t-MptRu zkj75)g5xLsCoz%-FK&I-Cg)GvqkT7L)@SCTQ@B_1GKf~{+S}r%#W^(Tnz?E6EEg4w z1CzED2TH#tA01Lw9)5@O@%vpHLeoSOfs%l++5rit`Fy^cOZv`7TwbN#v>la@pp8=` zgKh6SaH`ZEb~3l|)2q5HBk10GAAF&+=- zzNP&OGa+XEcOE^;?2&f8^zXnX9@$Oz2K!TTy{~0k`C0-hT18>mEu<@*0Ftw9%6ljNF4$X;$Nm@BnUC6Rt3U?cwc2*zrr1)g z)G$ON`AXkX2VKZ=qcPltX`Pz3HT>Cx=xb+v6ygly{f9eD8Lq}{o}3-IAaCpJ?-1Lg zYe{}GG3Kqq92LTVpeH>049sKaK>6f0aCCsWn%#Ww?+1BWI_eU^b_jqf5l5*@q_urY zcYxsV7E!Ro5%urMLAgGBS2|O9*T*TF)9%I#H$$4X-91Jw-Tpph3@P)i0Uw*|g6+~u z%`BNvU0zs>N97gI?@jSX+g14M`^p0DPmj0T+YVQdivoB-Co?ZeahT544He2Crd*<|8%egnA6$BWNWg zfkGSpPUul|5TU{^o}T1 zf&_vTrAP-Q^co96q)LYX3B89V9n5q2p7*@}!1L>K&&j#>WM_6~=CeCH*_+)_Ix{hYKtfP{Yr9<`QRjznI>uJaGj z6{(ODR1oXwrvq;h5QH%j0cB|#@6;$Bp{V_Ogjb4KKr}VgfJSN44ARF#*e=Xke+Eb z?69hY`&ZNE*Ph7Peqey0TJPNWFe&J8$TnJRDVE|sJ2%9%JXVirDG9W2mm0_LJX5dCb01*!$#MJ56_$Q6LqiN?Kwl-&$wci7QZO5qD^a-&jO8UlOe_;1g6 z(|j@vDHkq#$KN!z;7}>0BlnQ^pZ`>JcF3x|YxBRuOirKWKD)!|)7#c<)6+}i1_pG} zKa~(^`Sf1dlK5TZjm^ zmj~z0x4cE(M9fY1^=&>?cRa8ud*wRBhEMpZNg_8e_DK@O=HP#8hYl3m^ujeGOELeT z$xbL{oPSa=W|YGCm;cidwcslpHJ6RBz`xC@)w*G}xN86udC zpu#18w?0q~|D7v$MOYp4xCYg?x!uHaE`y@WC;2h4deTv{mI>ay|Dc9@S{XZ_QTTRv zp4ldV zogT8#A!0aoMe5%;J!FPa$h;N6aC;d3WnzZ4h+qh#x1B^MA}zEZUVj_w+%+qC+eUb( zQ1s3hbo)^Xgj@*~s?dT$Z=V6Vq)|#rE7`Bs`_HmhLUTK;X7Rf+hOvCTBZ8^{{M4Xq z9rq8_=d=;k52ziDjzjelzm|!gPeKMYz&SVd=s}4f1)38PsM7Z$+~n_!lwR$P3fy0q+!Soa6yy_1ZyZQ z&Fq@_a4&H0F5H~H>!}}2dqtLD0PL4rHD`pQI&}&>yE_l6e}Ah5oYI$i|LpaRJ28WA zr`hs-N?WgdG6%)Db@z>wXn*T?{y4WFeoKRaTriH20B#~epq4^75K@PS!LZjD`Ak>q zkPlDm{anhQ%o33PmN3sTk3>qL#8N$&w9FEmmLLBuxxu-Km#$8h6Fl=Pv`V%5fpd_? z!PRR?pa!~Sdh{76CK!6{Q@`NV#gLT3&bdfKvCRyl;k}&A;0BrQ!rE{Lb(QQzg-lME zXpdc+F9=zfM`74&h@>xg{2?<|S=3W}Lq zba>{fwa4j6D)D~N$C|!7*xv=-wQLRVDxOy@9Vi#cA>Gs%xET!~q*A{~;BG=uFgT9gXwL`%lTTxnLp9@f}Oy3Ld2A(mtg04&xs?@7c_u`1G_SzIdg<<2bU2fX&AabMn?H*IwX_~*) zo--Mem@MaehKj-F0|d5{v{ZANf1MoK>eQx&tD@9Mc#IK*lB*KLPUl^UwHr`2x6!2YD*DZBWElzFKWBAhexw;?2M`u-0Q zxb@-bw2YSi%|>7KmzlIX+cIfCqBxazpPe4!k|e8F*uPcJ%nMlU?{;`Y3|a`8de1iN z-DDRK37SUNex7gOwteR6LQU&iZT!kaC~wb}6cuPZdq#L$ql*=kL8~D594fW>_Zr-E zinQ4w;d3VM3fGNI0>fXxtuiab%FfhJN$5VbYFJ+xyo<@i^^0wYag8ZfXD{k3x+4*R zqYSq&OmK*w-vyas?jp?*$w!yi4Hpr#rbB+%J?NdLW>Yn9VvBwg;elIP^k>m4P3DQa zeZBR(qx%8-k=Rn38g5v&8a$rJ*W`Az?#$NB^!{9c$K`I!AaYtK*$g?wj2Ugg6+zKgr(I-aEGoW#?dW ze#6npQO$RCVp)8$G{Fd5$D>#6_>n~K&Naj?-id z67791k(S`0m@KBWsew~r_goFnHWfAiSwYvx#4d1Y-h$_M&1(x^4Wt=xo5USrJvRi1 ziwzlsfmR9^y?5=z$sUW4eJ=}QT(Q$+z7bt;iEExR!-B^TaRJP)(P+Je(N~&Y=vh_A zqnxA4`ksfKZh4%L7=``f;q55*8==2AH`_Grt$GScNEi*E57i9C{ZD2YL`KV;v{+G` zL#|84_i<#FB`dP9@@A>Dw>!R{Gp$tNsHosnEKbEmpt~@T*7KD^{?kg11qo|YY8zg- z$UIf5ow?ybcz)ty;&B36SrSuPH}mOQ7w1j&RZ@#5aOXT?XA=tt#WdiluJgqV#)1#z z${Sykg-kB!Tm_v=_++P*oJyX)1NY3&aV)SSVQyN4{dC+vajU@Dt$mu=QH{1=iG`1Ov>U4o2F_Wz4W_ z7IpcI=?a7_cwl#et3LP^>gU=OxOJzBAwm91_sWT7y9#QoaUb+T47m`@r$u0Ig*)~v(G!oC4nMzr);>q%PftCI6rw#iJfLdJ9y^a65 z-|FKYM5XB$C;EN1-o>^jLQ+BV1){=z7xX(DR_91uuCHHR7nkSEADs{vUCPri)q8Mm z;;~L8EL&=eyubZCLaS?|4hOaHBJi^;v1W#C&8)13_gyEM{#%@S-o@Yz$=JSe>c|sN zv)7$-cgjPzK}=b`vCHem(1N_|?Cm2Zn|i&6^_U07&z{lvuTG>BX6WYtxxZlbPRyE; zHcHvIm#13#$vC)Rz18->*?&Q_Igh7C>iCf*;kr_sR^)#C5hTrc-fSEsdW?T~$qGQlaane@a(RUYYA+x>V^@*tag!_MGSIfT zCP~cst!%oPa3%QLu(RHO>~><1v9yoY1;0o3C(;%}o3jgNmb#FTiI=?P%24aVd6zjC zxT2U}-Z!?(8 z@di#_gHh?#R1UXzP}Y8xO5&2e%d){h$Gt>dtoyeJ$UcqF_~vFi`P%H3H4m@y8pGdzQB-;7G~;vua6N2gsdoJm8`f(8JsvQBq7>-Ac~MSIzqC|- zoPW&Ue*52>uH2R!Sa9ACisBh#EEjI1wQku@x*ba2nB1fDo7;Xy|MRiMQf}GWRyfbW zz@gJGFRjNl;y`}S?tdMS49oHuk<9C<&LnacZ3gCpPPTMvlpGFwg zxU#5M>dkzwfZMAy?BU;PN=~qmT@q!{9L)N#l>#E1n~sZW1O8Ca_M}pq(s`(C=}~sr zW|2kUY{7vg<|%Km|4d%w1<|rpyNj84qZjwu%6$7`tL^NQ#To9&&iq9}cdreh#M^Kt*bA?g7DQ76)!5cenu8b%ztegn49Cqt;h*kPJ%lbjy7iFRP#bTigY4D zDOPO9ICISQ zn>U(2z?_dbx|I^JDK4DaUmEY-is9$`hvJU zMqc}WsC6u-zd32&#XHnAOgQMbZk)@%?xH-#Pk%0;dBfD8p{;JXYHRt17g{{)1xL_d{Uja#AuhY8D(C1kFz4N2P3_H6 zTwvx46jgLb@snt4v3u|KbwTjGYNIN$Jv|61mwv+tMJl1OvDLRJ4&fGOx0At8t>HlM zP0bpIrw__4pxm+7dT`#Xr;A(s@^AbIY@*n}0YrLB&_?URq`fJ7hu!xb(}38t|#VE1C?+hyEcf{DK7iwJm&n^~ipzqB}%tN%!%!%+cBQ2Y?mcGJY3Bqg%@dDxP5VpxkT_ zuJ@ngA|7Zag}*5X_jdTyRioxKDP=~GbQ`lH1T5w|do;ML@Ote|x|n~6%fA&LZ~oM> zJzla}wLf#5x7xcU|LISUGy1|V%eZ2t9g%xVhmo5p;ZIuHK7pamnL0|tRF9{S4s>rN zRZKpDpypH@PEWIPNhsTn)?(@*4o^NU$mY-}=N_oH=uQm-$%V?pt5)Yx+jAdziBZoM zco%0&2X4gAdS?jEew~jszs1`l%y)G%cCnHCuP0qUI zdqC$|=?eavzx|ATs8T!SQF|OzyYCM(Z}-1b&jQ}3a4?Y99iESaK{_mM1yuYbtDepuRTy>a+oV?lI7)R%9fl41y-Yp1+HJE_%RH_^;^* zZTfq$k_q^}`g3zFfMkP;oX(j=5))23-o?>GAfU|Zob5lw6*@Q!7KHy6tK_7j72oj$ z+5{K%Nj3H0K^6g?Gi8{Z}CaP@y!^@EAwBTV<26 zGq+OB8uZwik`2+ju!lXp4pTtaA@u|X9!Tm0zcegdcbv2QON=c#;eK1fi9i&TO^UIo*b zj|K(-6#iZc5WyGOz4#V=el_ip=l(mukYHAH43xjoXEl%Xmgl2Hub{}dORY+;1D!VQ zjU-#z74F|W!32Mvz*7u>qV8%=N|#snT_JtT_G@@J$HE)+6o4G6zaTOAQIHuHk_w*q zvYs4AL_=V&SpWsetXRT-X~^ApFd1)85)DfnX9?1|6oxAWz@U_4K{eu^}Xg4z^lel&qnE15<{o|5n_)Vg z$GvX*hQlPlBT?b6TVwRwtXs}N(&h{HJ`n%x+0)B0X{v9-=Viruo zXDJQX&CNHF3`d4ZVy^x_Ml!(C4*W5LOpR9>S#D3gJX7ZIT;@BRu#V;p4=ygEgO7bfC1JS zXhTm0U*8Lp>G|DGYWk3guUYx@(=CA2Z4j`e*)@>smA_O~B<2mXjdwM9y(x>&HyK<< zKf!FM8c3giwN>EnQbu0@lkDb6=VW;vX&5_9w93ZdvT1H=pzDnR^CYPpsV1pSfpO)U z&(6!gO6%&1?!!&!0<7oz_hR_&m2KOJU(bQSSnqKC=&_Dj&tW{U?EdQ_b8`^1r*vF>Vh8TtX z863oARZ~ML)w5zF^gcRC62nd-r+%qSUrr=tWtuwmRs<}FoA)>wJ(w3J$SZh;4qsjnIx@O5|bsv1`DIp0rhM9A%hk50K0uW;{X5v literal 0 HcmV?d00001 diff --git a/key_components_zsa.svg b/key_components_zsa.svg new file mode 100644 index 000000000..217acc635 --- /dev/null +++ b/key_components_zsa.svg @@ -0,0 +1,270 @@ + + + +image/svg+xmlskissIssuance validating keyIssuance master keyZSA Key ComponentsiskikIssuance authorizing key diff --git a/zip-0227.html b/zip-0227.html index d379c772b..36144e55c 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -123,6 +123,11 @@

    \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    The derivation of these keys are shown in the following diagram:

    +
    + +
    Diagram of Issuance Key Components for the ZSA Protocol
    +

    Asset Identifier

    For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair diff --git a/zip-0227.rst b/zip-0227.rst index 1199179e0..ea82a2745 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -117,6 +117,16 @@ The issuance authorizing key and issuance validating key are derived from the is This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe. +The derivation of these keys are shown in the following diagram: + +.. figure:: key_components_zsa.png + :width: 450px + :align: center + :figclass: align-center + + Diagram of Issuance Key Components for the ZSA Protocol + + Asset Identifier ---------------- @@ -197,7 +207,7 @@ The issuer program performs the following operations For all actions `IssueAction`: - encode :math:`\mathsf{asset\_desc}` as 512 byte-string. -- compute :math:`\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))` +- compute :math:`\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))` - compute :math:`\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})` - set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) - For each recipient :math:`i`: From ad11363b23bcb54418c92b0185c954e447ed1e80 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 13 Feb 2023 16:18:21 +0530 Subject: [PATCH 073/101] renaming to bring in line with other zip images --- ...nents_zsa.png => zip-0227-key-components-zsa.png | Bin ...nents_zsa.svg => zip-0227-key-components-zsa.svg | 0 zip-0227.html | 4 ++-- zip-0227.rst | 2 +- 4 files changed, 3 insertions(+), 3 deletions(-) rename key_components_zsa.png => zip-0227-key-components-zsa.png (100%) rename key_components_zsa.svg => zip-0227-key-components-zsa.svg (100%) diff --git a/key_components_zsa.png b/zip-0227-key-components-zsa.png similarity index 100% rename from key_components_zsa.png rename to zip-0227-key-components-zsa.png diff --git a/key_components_zsa.svg b/zip-0227-key-components-zsa.svg similarity index 100% rename from key_components_zsa.svg rename to zip-0227-key-components-zsa.svg diff --git a/zip-0227.html b/zip-0227.html index 36144e55c..44f419f1c 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -125,7 +125,7 @@

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    The derivation of these keys are shown in the following diagram:

    - +
    Diagram of Issuance Key Components for the ZSA Protocol
    @@ -291,7 +291,7 @@ \(\mathsf{asset\_desc}\) as 512 byte-string.
  • compute - \(\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}512}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))\) + \(\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))\)
  • compute \(\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})\) diff --git a/zip-0227.rst b/zip-0227.rst index ea82a2745..f45310628 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -119,7 +119,7 @@ This allows the issuer to use the same wallet it usually uses to transfer Assets The derivation of these keys are shown in the following diagram: -.. figure:: key_components_zsa.png +.. figure:: zip-0227-key-components-zsa.png :width: 450px :align: center :figclass: align-center From 82325cfbc7eda247e5b8ca1da70adb1f8a860d50 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 13 Feb 2023 19:47:30 +0530 Subject: [PATCH 074/101] adding diagram for asset identifier etc relations --- zip-0227-asset-identifier-relation.png | Bin 0 -> 44943 bytes zip-0227-asset-identifier-relation.svg | 293 +++++++++++++++++++++++++ zip-0227.html | 5 + zip-0227.rst | 10 + 4 files changed, 308 insertions(+) create mode 100644 zip-0227-asset-identifier-relation.png create mode 100644 zip-0227-asset-identifier-relation.svg diff --git a/zip-0227-asset-identifier-relation.png b/zip-0227-asset-identifier-relation.png new file mode 100644 index 0000000000000000000000000000000000000000..d073f7aa80a0ddecd60084dc28a7502c111470b5 GIT binary patch literal 44943 zcmeFY^;=Va+y^{GQQ-?1AR(bhNIU5+0Y^$VsB?68qavcTBSs_5Na+R@Vc^ISqe01S zgv6MPdJgyV-2cGy^UZag3$}~xoPEyw^M1c-pPuV#&`_~Zfj}S{$g`&gAP^-A1iEzN zIwkN-ANLUv_;thMnYlLzbg$~-xD;#c{SSDO*+V*!EggCI|pjRLYZ=luidCuVzhj|<^fZmV2>&x28MH%Pvn$ocHnQ$DIk z(G1j7hYL1p&%-2KuD>(l^P|VT6H_ibSde{xaOK(B>BCL9P6)S%|PXAsX+Sawa@ z&5Is%_#_oJZ5=WDq?aD<6H$nV{}?_;@*oR0#3F(r$vzesU5F)@tL(XbCCoh7rGgqH z91ZSOHK2ira~m7u2|>+;d+>K$fwQJ;pr!UYcs|#bK0bJ8aQ(bZAHx$v*AJXR>8*xT zYE&$E0nVc3B!o;U|jsg|XE)v4T8cvB&&t_FI8 z_OQa(%AB8#)m8`{re3tnC8ztWXo}vnOs@HdIAKUnt+XDNL8OX`TeH+7Plf6)(KxZI zEBfD2KRROT_w%nmd3gAR`5>MUNOWwR@oTHBMs}IPsh>YLh3mM4lEiE<^ypg7{X#R) zGZd4di2(=XG(|@AKhX2XuAjx!FjDARziI3LK!x_Pd}ZSd)U4qu+zbMDdZS8RQ-h;$8m`62)d4{dJNT0E3{8$iDl3YuJG~r8YJ#oW{Drye@evrL|5&@gY%r{OS&& zT$V-BWbv-hc%z?dV67adhdHg9y3^jD9+oDD&yzdznP-0~A?{|W!~&Y4OOIX*4bum! zAoI-3$jdqG>`sPljoXf+D%tMM%4!s5HIyK#Xv3Nsvg-tYoMrR#aM!ss@tS4nsuxQ)MR4{-Zjz$2wH5!>UGwm~juK7+b{wV~zF?ej z`cs91g6LDC8`K^etR7Ec+7GX^BrYTog(xAkMHUKJh&Qod zSFVoy@uE9*MwOb(4bi2@poVJGfFgskyEf`Cxue%~K7-x}toayaHEzjORL;^lcCVdU zG`~(VshlnHUWeDUxs(@@xOM6U2`&pp7JqNXTT?={DIm7boHiW`FbH7c@j6EMn4izlwYRs*X}>kBob2^+XyPkq2Om9MZ(4=1FF#o1xPqKd2ol zhW^m7X((=@%9yReO<$`>^T{)65LMYm+7%&-R){y_S&5^f$XMRP&*s^!8c1|#INEEG zF~MW=cGe=u_e&uiSD+TWsicIm-nqnor!%wTCn&RGra_CM^GIF5zg3%QmJ3+|Gr#A` zPyJ2&2h*4`MyhBQl^2x$gay;q)GFpuI^F~{F#pt7=48hnstz$ncq4~G*4bZuNT?7x z!&%i4RHfXT#t&D2=7cy)i;B`uQvcmbs!GMrceGGl8(F*p+UDWz!C)9H#lwDa>ST19 z)p({4U7F&F97RrvoJ_ zX6xuqGS=DQCU&|^UGlYfBe`*+km1?^nl}|p(96l>Gw-iMbnSkB1y%~qLM?GEyltf+ zEzd3S6rdHwQSc4&-t07aBZgTffifyIWd75nxU0(9~m-p$QgMm_9a}F zCak?q^8@9yAuH(qqSiCH0{!JRT*PqL#90LI7)QLZlaj=*511;x_s|xfu&s4I_z4#h zXt^0O4vF|=k=)ZrkV_J9AD6JU#9u4@nz|5AF_A={HkkRSL@MQdj>o-5$zoatFpbRW zrlt>vxPrHAGGE_wg6?Al(U=mTF&*8wYQY>6fWVk(lthQ71}u{gCFM zCyK7jD*dLV69vdB`1b8#hYj8?hYggX0GO})-BrbBLEmaCv`f<7dI*}vf={_ah5EJN z7j4Q`;UMvHNa&W(e@ayY$2*F|vjao67_ZK|Cj!VMm^sQtkorwrESQGt^a1jHL1lX};C)Yzr^+I6D0&W7m zkPot|--@CuKW*D_B7yDM8?7-ysj#hv8bOf6d3?IJpbu{aI$K|HEoiEb=}r|ekE`^?ic8qHO7q+gJ|`p~TpKQdsNzTO ztT``HL+Nu9lN+UN4Cv6cXJ3&OAu%3;_j=PV!8@hS%{UIW%I)3S2G`0!R%H)M^vahL zA6V1{Hx)RR6xwZ4TxzC+YCnYRb2IqW`#R5=CFKNZMz(j0NMiAnT1tk`A)s~94L zv}Rc!B2!@Ia_vLY>1V?dziUpUGslR zmtMs>KE&}Bnb&-Id8(PA;P>?xg1X^<*7Po8ZedjJnMG2ui0-TlBxtC%;=c6Z55BBFN2yRdDRmp*X!(xTxa-@EiiKp7ycVc?9XPKRvg+^*JQ|^Cw2U+ z&-*Sa&h2}xV8`FJr=fqRt8sK4FU%(&%R2pXm)jJ+-v#b9GQgLz+d_ic?DgJ(zr49| zus;^dXgf~K8~Pkn$sPI{3ISDdLSw59NKD?8&`?g!gRbD6hU!NEg8o+@9!_-mQ|n{F z4N+u-^6!?Rw;H5ipf>(7L5fz1YlHR!oCC?h0 zhN(!U_8tw@@d3yd_sP5*0Md6(iy*{-y6(Mgu1}3h-S)O5ZjLSB{1skr=JNz!vbo}*2 z*^$J;;u?FSsg4I^nhIW{h3HA;ULppG2AkYdMhlq#{o17W&iXzvr54tzL zya4xJ(aPXP78X=$V0p-1|5R}rTNI!~`)xvK-G{E_+MswuA+k4(QX(Z;v-LtVfZX9O`Q|CqsYK5^#?6a<=; zm;aJv6Hw+n!xIiMj0G!8q`a2>0fzLZal#d_N2DhO?4d?5RTZEdmDmG;iV&|h8QiUZ zTUg>McEd_vH4sMiYw+OBdt+QXSXy7Bqolg=urxt3BBzZPIneMlt3 z{_O9;_|!m33g8vuLTia>OubGDS18m_y73{a7BRjM0~h;ZE$iz#-nZrjTHzMa)6-#< zdc5TV$HsvVzEEJl?u-7AmCYf!Em)D7oM2Ej5U7x4q$+#6eYdw>$Dau*Gi6No25lef z_{gzzIq>%z6>`|Y7{9^PaBmq1bToJ#`Y*yJ#5tcw$JPaX8V6=M+I?7NdQ7e#l#c~d zxbXGa_0|fuIe$$77pE3Zz}vMbuR5Yp9OVv5Z{}f_zJ4FE4I7QQ!z+_>2J~ltS;8d` z$5?O}Ttc(#KIHqQOEcttUMiaZ>YE;eKtr-D3`I`BJpr(Fd~r71$vid10Sa`P??0VJF*bOSa4=Hlu<`5dgmSk0yT^C*`-f2>hb7@ncM+3*qj!gnuAzX+5TF zuKAuV>pb@(a>i%r4cEM5tfRg8q)Qv&vd5^+=+O&p_=kgSoyU}*K2uG~tGLP>dE$5) zIKEgD4or~7P~%I@Plx$+9v^yiH3F5gH}@$CSh4vz)?tBLEQQ!yLKTYLp=7-B_7?FB zrRY3W()A4PSIL~0uY54L9*O@A6T^>b_>v-qCOS^JLLcBvj>~=pyLD9LgNw5Z?cn42 zLB8{2`D(PLphtb}^77(;-d@8JFz*!P?W7_8J)bO2Jyic7V>8;@e|}WkT1HHJc6@GY;e`b|_0ifyjAj5t6F{CT!4j56zAX&A#O3};h@)KXBF6vqT(1HC^lEQcy@@DW@;tP zIebl(-H|@bSpJUopL=P~2HH#K`Tg6;yx_xKw;3)-WgJ*X5N%=SZw>M~NGrUFNMJTQHcD-g>XQ!PuAswDvj_7e>W0wuml|XDp#%1*FzzXHQyUMo$L2}KNRy_) z@~@N$fHP+bTuxkUpR3G#$eL8B!F4PC(ot@mM!x6jFQ+7+*w)WTx#~lM&3v`M0PR&c zYYu6j+p9EtD;hS+dD`e?+_?Vl=wE4KQ&TkMl|B?&>up#VKL<;hQ;}9VfT#C}heLSYQ&xWvLS41QK%a`PR1|C(4BYhN^IPv9`TIEawdi3Dyb<~@XK_){}gKMb$;NS+M zA}Vgzit8Y+>X4Q{GqtB*09^ga5Il6#VRui6h1@R!FGNuKj=k%W+(!t^r~}wIOKU4dJbu6+61-dhLQz&3n$qT@0i>Qrp*%MSuxplf3?|l*fur zmqj6bZ=mAY6AZ8m-3P;ETf*zvatsARvvf|FgC6``=UbkHAbvE=EeSs4v=jpsb2^bL zDr|Q1X?(dKcB&BEU=wCv%O3otLm~7$46!^GW?pfdR9)8oyGs5EY2ySAPgwAZ87u$Cuf9RsL;)^N90ia}E^qLCg$?g$oloi0kq`+M;Bd0Z`QqUfdS{6gtx7Nd#) z^Wfh(028bl$BOVOa^z~A1vLkNZ`>fiI&?ua%DT7fr*!{tDZ73&pTs7!(K(!bN;eS) zrV&Duu|pZ4*8~QLI$Ta({$TE#umpkv)Y7!`?FIx6R{yRhx@d#PAyD|XerlMxNim9> zPliWXa`CX(Z&QX7ag>WOc-kj^OeyJVi7D zI>GJu2U_#)t&j^sG4=DQhM_IwJyb~n&=h!ax~P3%eIKo7G4}buvh?=$?mtuDf zxzv|@sM3vq3yxv2H*8{W>0*`7&h#(Ez(6pCmU?nAyuC6SYnuk1tMrD-A1cW!r!o_)>ha2 z=3HZ2ya<(-o8e@Bo$wiIJ>P~JdQe{npd}K6H@&lE5oGC!TSl<8yx>`f<1#(s$+xO9 zlcLynF_fiG9TMG~%+z|BvZG@s(mqjhLD*&{hi}G0;89Vd01Gla@_pn)GI#*+jfxp$XO ziQ(0AMLQabTQ2t$VV~pK65w2+2MeLX-_um5F%QTm5!bkiC|wp~(ak+7VUu0%&XITN zv}cW$j#cJ8*V5|tE8L&H&-PtG0_8VoRmU?1-6BjFe#y0EH+?VQdf4h49i7ls>MSQO zS4H0JZ~pmIt+z)y7sX{I8!T-?OFag#C5P!oSNQlOli_%6#h4%V>ivjDc$VzK8Ujn& zjk((*Cj!i$4pg=l{Uh9_xsGL{cEZ=6-fzYBK5H0>&EKyW+ufB3-p=A&{!@{Lj$9c1P z%Z01CHq$Se^g^%_o~Jy73Lk)MnTh}+wOe+rjb~vfp_SjTERB|3p-6G9VpJ=lbrpY% zrlUFvB2>v{;Oah$vgvHafw_gy{9hkR%!65-g&=30ofmrfe8WmQpB4iDy}I+)!4!f{ z{^x?Tgbc$y0)}sG6^A55Gj?rM@6WxzVbSHkqh`IlzFZKHdUwzSQ1jS+ry&ev9|?!1 zQNJlKYFJkO^yPj-seboGp98er@h(~a*80$p#n2$1m1k^m(O!*l7fr9?O>3nxMI?hz z#&X~~JgMOoidM(A)2d)?c=+*0E}jR<^9uiz?oiSi4g0(`HTe;JcVb*QLKx`=I&`#b zLqF{SVg>(i7N8LTDTSvlBNjl@>jd~jXDo*% zw)gmdO#B^e4kY^z4rS?ScMlJ1yj44)XSrRvx2oa`?dBK$erXSJYw-jL9OaiT1!GT5Kyd`pt%c$E>sEj`S`OIWz|(5TT2EM93b(d%@{O6S55)9+{v zJH@t4n3Zo1U3)>jUI7*n(Iajz%neyoH8*|G8Jjsjd>yoTQEMMs8TK0QOX(cL(mC~P znar%qgQUe>LmYRg*M&~>48tsfrp3ieP4y|rO@@o?x1@)@y*)iS4VftPY-Vq%t^|Ms zPhf!6!ur}BUT9W=*2>M~R6)<*|90<;BK*1x9k)&8qK+eNmaI7CuV zHJgY#7l+PFF?qXg{-L$%2CN=y*F!}=5z&VwbP5#<{`Iric!$DG}IMDdo3tRVv8zw z47zM(i|+j!9bxkJg!~cz8CtAcqB{g5!XAXaamB;dO1Bb~E>b zjnCMk-&ADs?;GB?&t!5oT381S5&HrebfSg%o? z>c;D7Vt!@IHsHQp0_F#wjDn5Y$qD_+PBnj#CK6DNS}e9jWN+9HN$q&@OPGxA?(zeD z9%v4wUS?_dRFP_f@83;Vjz7i5jGfTjtKS-Vz!np4qOI}{FrN7eJzh@m+1f~AE6kS; zbvyD@t_lUNvx$cijoG4OeHuBWLoGyfvr0cF$iYj9S{qSs^YqSo(i*;nY$o26W8iausZ$RQPLN2`!FSjrz3K%tW z?${4;^AZ4*S8q4Wp8YZ21h9Xp0)qwm7HwCf8BIF~)uuhSxvQqmOO#A7l@?3f$d48j1&YaI&0g*WT*nK6Gd7RT5)J8$=-lnjK!QFZYdk?osde@69DS+JyqBJ!>`4 zB;$;*x$V#Y#N@jgMXelZ1xZaoHMStKwS0%Spzf5#kr`?v_DG3WuV=&P^-u%@+j>A? zAph6C29h~3)x`IJoX8hn!mhdHf7IU@UB&KCjlw@Oc;N0XUK-#VuDrsFLl|w2wYQjT zPUX=YliISpxn2`>K%vHW#d^#_qJvyxa3aYJC5e5b`>_2)po;^ zSww<$>Iz!>XykcAwWX;wi^O;(5#KMGgpD28-aW=oke!BD2W^^!QNdQG?alk_YpD7L7HMXj;>%l3XodBFlb#;Tc{?4>I14YHZyfE5H+!$MhELvW|NG95Lv}6X z>|bRQKHH{4xa>oLzJ8EB*+<8!eF_#negN3V6Ox=N5wiZ1hESB#_YX8f&|zO(KBCon zj%OSQN{}6T|BK5}v<;5u7(SdE`KCm(IijrRyIIPKxCyTU4A0!*j3OKwVL!Da)Uosi zG;dH6FSFng(Yol9bUDNtp&@#!+W0v*<#vy)2_mMwKD9?Q1G>fd^H1RwO?qV@U%W#-hTFo5&TWn}EDl$L{cB$KuYylbPY_?u66$YD) z>I{S8Ps@$@LUj%sBr8nyFTeoX@=3_J=6mQ>6>&%z>s`N5HZg2jimbmA`g?@1D_~g| zNegO==;ds>%myB8!2Aa;T{WJ-6pbm+F#cvr%#~uCsm`H$SMy%f{-9g&yt$s}wlKF! zJL+lV)6)C?2r0yNo|yMP%giB=!x8KU^Q0=xg!z4Rt8B>mrwxCI2EvdjYr$bGsqrVVtb@l)H7ylKMZDqaD=QN*!m z1~P0_vtzQOZK2QZtDeiNe9pS-fkQmJ_JIQrO8%~BI$O2Wvb!(ZN4a1n-SsgS+0#2yPSGij|)bzj_e z_(Q>xDA}2G@Xp{kPL8`l{(Su*bl`Q-&?E0{3NyjxulUKjLcy~Ey)wg9F}J#Vv?6t95y zq&#|NAyN4N8Vd+h^|=TfAUiyfAFdVDISouN9AC^PI@#`c%`NWyh^+(2>3WzouED{= z8j$n&_)?3{+Krn0osw~Za53WgI7|abE_kOaV_VgP*0D?g&7KdnubT@ghZmaM5^o4N zy33}(g6u-L>c%Vy6<$E)%6{h$cZo(#rzumi#>*r?(0>D{-a6s$Ppk#x`STXBxoQ}3p6lr11)O&43 zhDl3=U%|$bj;*!O`EAzUg*$!0CU|NUJ9o}#NRSmq5l)t7d6;3;#Tk6K!nj=0e0Xi5 z)WXEoVshx_`_q$S&7PlYTQ450C_dMJc{n81`@B0AZ zX?XWS1{Rgy$@JX65Q8BYRZ?UBS22PwEJl{&Tw0Qln+s^IKC_iH+z? z`#5sQf=qJd?owg=(c}eF8Lu>iLNJ?G2^X@k`NB?h&pqFrH@Ak?=@!P+7Z#8WbYVo< z9$qe3^V&eVH_N|2Ob}$=egSC_{yWQAt^7J-dQ?0PY+fA|NaJ0S4mI`(BL|0V$f2q2 zlaj@C#Cp_xBuU^q7CEj-z z5xIJFT<+uXm!U&%CO9B4sLVm>8$(xAGTFa%eG1G5Y~I}s2L@rIXFU`Y#(7UaU2a;0 z=mIyhErD$;&#=UYlSdtZQbsaT7v5t(fqzT(6+)9+>lb=#tfqpY!2j(@Px_Ncd(nNq z>Ou|&OsPSU_M-oRRT{&WBruo^9b}nbctjX=$7KWH$U2HokClWZB@Rp=8GXJd7QUG8{DKt0q0Ys4<9XHY15lr0w zl|uGA3qedn76&p*GJkYWbQ$-4cLgNQEG=hu#SpVmN4s|nG}oUO!OcYmAM~ffWVNnd zD<7kg+*nT$$aV#EHFEI2T|*0%7B}57(KPhnc!zl=;^cH9FD!K4tfdy1#4w1=U4|k6 zus8$YZpK%vds2{bwE$3Ry>W+{L;xOlr3(Fz0Q)@eok}$Q==92KHUK}yG`WldO}@d0 z5J~qN7}>4INqY5uQ;$=wQ~lbrNr+=v-D98fte#~Ndmcq58W)>^Bk6@JprfM~_%YRW zwpf~gb#|xKk_!q9k_qnw8oKl8LWeL)AS#j%h~v#x-(q1(+wyFV^7sM%CJf~|%`L15 zGiUUYGwTRzQV)|f?P!xU1$<5OtT5M)F?yJUu9m8hkrIucN9Ph)k#MU3y4$&lg&bk0 z8YE(;w20PI1tQ?yk)cB@h(?NQ)A{q+A#y7U;>|~DKxHFU6G#W-{rQOkf(}3X?b6U| zx(?$2tzIFF8$aex7Rf_gTm1anxjwq|!m!Df_SSW$%`R4nY&Y)Gz1q{m?KuBI-syRD zK4(VZ5QgP!s3W7xA>!4mJL5&9=N;tDZ2UweQu93}?pt0Gi>T+@58(=`22N>*z5DV{ z=61UMw*J5|;92rZza{9xq=AYz z$Jxmh<%+M3lsg*IuuBfXM38_qXKf^PxVkw#ljVk60W4#}eA|x61NR;6>cBsfmf6*L z56?~v_a$8V{MH68svkVaUIafdLd6Gl>E#OU>;@bkUWnZs&XW#5bHkm6$VBO(A?eJl ziZ+F_DQ>2H5^+K@K`wt`Fw*@1EH|g`UmoK7d@nWw(`W4@>&tVZ&p9jLC9&ZSg zXbz$`?Z3&&ole5u&V}K6`fsytdeRYbNW{0ihr;VO_}@b>wqf~V_zuP{cJzyG_CXM7 zdzw=A9%%<#dbCeG$_-y@=CBSrcUi1r>)xk7TP`(bTzCepV7Q@@>8_F$BmvaJCxa+Quvnms! z*<{833@eKJPCwy>)mpu-`4LInIo{EN)8@z&)g~z5y-vbU$+$*Jnp(0mC<{YV_Q);v z#;+~shi|k1|J@NfU<;R7^VvS5;63R3@;T_RVYjso9f$Wf)oO4tSeI&8{ z!^IOC8|1GSdhQDhGY0yN>e3BrfrqiVtsBuFpq_v!(h?NaxFeHq__-!J{*&qG7tn=K z^H;OTsKhSt>Qy_%W-eYpDhB?o1c-`mwrf29(xnp3pq~<5WYjddy4d|2*nNYR^~%8{ z4(#WG5{7$-(xv=MRDhv#4{u~N*86*pICv6z&`@j;`Sm|n#FM(eo71md7k$mzNbF+^ zrznOynWbq{R|10re*q#~-h;PgMh~>b%TtV>)x_*z(VAXf(HFL|Pw-ZN+_VV1<-Q$%c} z(^@^k7bVYu2Rc`V)RwzW)}jB0eXjn+Vc&$`ra3LDQ3>k!ajfk=ceDozp)#4^0IrX{@xS!kHV`B9^70KOnD zc7~GO7Zu`82_k{PL1mW9y+L*M!&W<5`#>8D3j1-zRmS7~>^|Jkpg!c-PiV2zn&a#+ zQvr_^LDTB<`Rz-Q>Sd7vrftuBhK7#$FIKKS$V z)876rASgIPo_*$w_YfrHZGeQa(vWMhV9}J;OJr?yZLMX&APl^BTVlBRAJ7O9U(x6> zLw|8}2#vQ!v#9rAT$n-qzP_&6adB-f^$nN%9Vy?1K3UVF0&Fe|JE{HhRm?B`>r=dG#=fD>*z0HI+*ttR_yL& ziVOMoQhusfCmuTqWVkqpgc2kmo{y*r#-zP6Z#|C@v0AVc17s}fg#cARVV|~2$6o}} z0PxeX-%U5v2zU*I4xmw*jm91`Xj`;TaaRc06n+c~SW9QUCLxVyA^p4))MhF|b8cS3CW3i26*x1E*7+|ZI&ohf0Eo;6A1 zF(S5zR+n#uP$}!yrVr&2_FzAE-c@Il^4Y6ZiC9^oKb2bMh+~yC4Hud&^j@#shCc2s zwQHztZP1aQUqIHNwd1q4clS92h{QB$i?0FDMp9y7#>B4+QZ(KGRkhbR>G^j=N+Emv zthPAY@#E$#c^#P3m0KO;?_On^+o1~VExW)RF5gZ*{>R(AksUA&awItK@1b+ zmWF`U*Y@9cHMi3?yOPcmzsBP8R;y9)bW|XaZ7&1FFZ}p6rSI0r-~5O{K=2}Ly&NMR zZ%#zV3^)Im8v&SQgM-faxb@)IEeK=Xlhe?wW9JlF0Y8XsfsYw@9sBoSVBSr8%VJ{U zLs2(z@+*#fL}G}R3w@aae^L~UbRWLn@$X=ZpCuVw>J_lQYQt~J^E5Xu3mIog+gB@i z^e+Gz6u_J!Vmh}vmzjwjzj%{F;7vSxsj}sKU%r7M;omP};Wq4ZIz8{|&aCE3!?<0| zWUOpsbBb_X!q`@t;Oz57O5iI9XghJA@EsHU+=B0m%#xC*PS&$TnFX&1g@2o-Le@1C zf!RRPynviS9JrG`(Sg=6r%f$2tZUcJjyLWh)Y&%tbX)!P{?WHZ$*p16w^k4|fMD!7 zO@7j(cEv;|_z!7&J>!_97qBt|PJmei5@m{tl0X%h8|T=;5+>B){N)M$Ayj0p5*O@ zji=hN7im}qSwE|BUk%;dPECf@4o*gyL9?Cf&6~Pw9&|(OSv-xC( zwy-Dj7CduktDNujOR_|R6HNM!nr8O*YzbB^nP8K#RH3nlO)KrffzdF>`5bv+*QQBy z2*t{#7@(z=FNE8!8$1bn(Y~QKv$9mK$?dQ!w$D@#D4UmDgUCogJ;h(C0eL@g;9WvXJw~E`Hzf` zvd`%U-r(;ZoBsx(#XDPohbvpYyk9HT;dzNJ^N@9iGXlMDH&JGNuoF*ERV5OrMXU~T zT$J2kd!jh@0@=4GFL#S<0+vP~G^Z(5tT)Ps4_)H<*!4+V!I?ibmLW?0vS{fi$LtUl^$&nZurll5cM??NeH zF%0QDP02PPDsc6<+>%{GMqCUXhtatLGvczpl*dM)-&TJJ4iBgu2jDjt=C@6z!pb4FcHvK(%#M&ij>l>X~(&;d#|GQm^Ywbum6b+tqR{j5`t-^YZ(6 zsW=uzMQmuOMtt_?i748Z9>9a}V0qEAKP9 zj+};C;L3l~^`qARv~B@PT|xMISGYd5khF2yWQ9>MzZl`O!;}sy8gzueqhm4*%;h70 z-trsQI#k(@D*)*s_HC?*{ZN+SE6lXEeY$iq&@Vr8DCUbqDHe8XJoMc&s)&xF*T;Qb zvRV`YqTnJl_~MHcQj2%Lj3>W3FyQ#_T1lbgx!v0u-ns$DtL59iz>PFFak`miJxE&@ z9wKf^oE~H<;7`$X+zJn7)w$}0bpKIv*@?Wj3e3aaqq*)hZ3H(SP`b6GQh_9Tv9M*a zhW98KaiOW@I6gKJyRUR>q6}%Z`v-{7k0GbbE@Ztu*I6IV`5aE^BOuqN9Z_>XJiMXQ zW`31D>fyr%U^25Mbk<8=ra;Ax+Kbw^)-yxL#pJA93FD*0yu6FA)M>xUZ)B4xRK!+I zw2B>Tnxz&=mgpF+e*NlVpJ+|}2M!;{16s_3`C1EFfF2w1OPO`r*hFh-VyX%>e8tL^ zXk2vmgS!`*mL1I}dn%c)-fvofA0!&sHfcdv9yxvi+ocqG!gbN|ZP#6R`NUtKb)@bxaOA$c>+VLnr8SHm6CLZ|gxC}_J~E9V6`Bl7cLEJb5Bc|N30OR8~ovwPVHCJ zw&M_~^Ka#-sgvtunZ(dj#HHT<(rASvAJ z55{w6dASIP&@^X_@#m-hO6D()h!Sxre;oEJUyBNL;mBET2cTef{XG^Bqt zvSP8aaeiSG*{2mAXWQjjoe#b3^&bjgn8j70A8`LZ#q0!YYRZ%YX)*(igzQPcsJC`P zHfna6TJI)u;%C4l^iSLP(`$NV`_?cBI!lK)7ma=cFr!N_$KeP||1pSbu?8 zWj&v$TL;nkZp-`D^lDpux!~bz?8ZqlV51GAutF^th1TXrTg0SK>-#B zJ7ax&V(g`=y(1`rD)pY$a6ZXbV`PX21j*(Y?;=Qy2>5%L9rJ05+E3?crRR>8p!f}{TzSN?I;KRZN=t8?yl;@qZGg;Ng zlg(bR(4!I6);yI+fJk=faR8~rl=qowe5cE zPrA^rE&wqCR$B#gl;Mjl1VK#wuisrN7DPu&^lHNop0%pd44oh4g6-ZGeufVf%6|t6 z{=#Ob2nqF`QxpVZK0wKD*82R$xX#w^Z|EEIr=Q-Yj-+OQm!Qt;{1;y8WVv>{P^R;*?{;HXoqSFdvOTt3Ag(ac1(aBosx#yQh(NfQqUq{@(r>~sY zapUF?NkhA@zyJN?@slbv;fec@^str}JZpbp*jtfmPC*NFlb$1?Qq*2WS-tC4*{@&E z3&$W5!OFY4Q`=iKt?xGP`u#huA7qlD*Hj^=f6DLrbOV?1;r{ifg(c9rFUn8S?Sl)7 zE3|K;_+OhfjDLIeTlp2IqsvUV^$kzC2=#*g#{MrZrC08^DV}uaU3L-JNcdy{ z!bnm%-P64E%zhp7gdX%2)c0DgHPxJMQ6TSc$89Q#P$6w*_XLsl`6Y)%@Er1=5CbZK zkzUtENKhtITex&78QQ8H{bob8C^Qc>Ydoi*r z(M3O9P2CJGbAE5RaD!6;eD7h2OWvmBT+eOq;n6p^is^k$3JjQ`n#t0pYTxR4I4bGW=k?p zI8r=`OSTX0p-Q(s4@l#T<>Lb{fqU;3%qvFdo4PtUBlEwOUY2%`xkVPds!Uq`Y4 ztYcNs&pk)LI7Hg(^`{Je$GFw*VHt*RC0y~Ivd&?G@`>+1TR(rJA!3u*yLKIEV}KjK zF~-X3aS~?uDJ1PZwKuD-e8@+qoC<$#N($0swTA7j$w(?O7MH<+7tVGc;>Jpr9XuXS z9+9c$&wQR;=c~(6E?HjqK(pcgiu1{bI3%Bowoc7=G&O2_zFS7&Rzj|6WMp#ZqomEv zr8Xa=(&q$5I!nvB#jlrWohLoY5BZ&(JnlcfDQovR^RZKTnHOW$KgJw-2KpB~znvFn zuJrc)QOxnCctKjbZqYHL}hV1mq3+B z+aFhJlghy}umy;jMfyod3_O+S;WSd%D9=B13EceM-fhnUB5fWHv2zq<_#Aqo$M4@#QNPCg9UL!8;I;#s9# zRnOWCPP{pN>7$AtF(KzKtq9?Xjbpi|>wCtiCUqzzRj< znay^WU+1Mf>JrR(Z(%1dY;~jO?BUywvHdrj*+f!|8`92JbGcq>TWT?s(24ZEAC*Yn zGL|LeX-LXzXG<}iAKM8Q4@^h?;Pkuf4}JKyI$SRHpfuF#L2P$RfsXBYYCJkI88hzf zx3;dji;WlQ88V(+=@97IIj)B8{070rf9F*0KSn3v&A6%1o%4^O_~)@~(l;e0i(d%{ z7>X{uI?InJjIPN4Lv<3iB;!|+%k9&ZIKtQ*AQUSm5jK9GRq^X}vWh}Dbr%cGyZe9t zLT=Ntcf^%TKKyxDN%4jwTweEfuY(xym4LrLXI66!7i<|;bvMeYuS%AjnH_dN)lTn- z;ab{~4xp&(uzKvFq*vp)+UH0!KJmd?{7*XB1X3C z|EH25jB8SJ!Dm?q0q;{%p1q9afKgJM-;=#-6CWQSQ216hJodMV31=i&863tWN@+t& z%js@){@?Zc!~|f+ysOhn{m9TOWk%X~YiwBZNpyD=So{6~lO2DkbX$kG0+w)99rciCZ)dWQ)u$(Z z=WF}=-4Q?1DLvw$*jJ($#ncr3c1$cxoabfj%)#m-BZ>Q!%+uRb__XZhb4R zu&7m0eJ@^HlC`}R2on%cT)UXYwh5kUK*G$--oN&``ti=#Xd-v4+$fn!8k~J+YKm?1 zx0Ho5#&*9*x1}1DQ(7nBoSoCYN?8B z9fW@7THWwt!V;;*Aqnao$iYuY%pLKmto|AZzrfeCR2R0Wr6hj0v2|unAmEC;FwJ@I z3dMRW(my(p)Ax6ss75PBtK}fNYfnzDLPbX-r0$>f4t_GlTaK&`?dG%U#PIHZF$~zn z_3wp#oOoGU$?d5b8QX_1``WNiy26#=FVFcSBy6RF4;WGmx`Ccx3kl`EP<2AOGJ`M(niiX}piWrS7kdBlVTBcArK^AWa} zkld8|fCFh{sRVuIXmrdNG^EYc)ctarjJ!K{D(NlInXnAnDPy<}4>2)FWBm6mA+{qT zN+@q!Tu=_z$wHTwOybyv{-qm6+aTh8u&F~&Y@1e-`<-5VQb3JR*TfsYc^1}iybS5`R6jO+C96+M^VOo?&VS*X!d3( z&*DU6enzl-DR0DE#bezey@T#@rO0Z6FNeIfe}mUu3Ux!Eeja=0%LuWIOJpSSua8ft zq7)JSanR$ENad@~N$C0G*y3P$Q3f|rh)&?0w(JeV+vO2Bo5tMjx8pzw<-?z0MRHs4`i(D<1h~t9*Dj{L4gX?6Ezml{9q{?ExUchZr$9_MF3fT{ck;KN1{5Y6<>xr z+KFJ-He!MfjY6F(hyOl*wXb$S3cB;rwMzTmSJ(me?lR$tNLI%Jvf$Mxr!;y8Qf6w6 z&M5va-i{RTf8Qf6+hdZBWscX3{dv0)J~Z^sSqaU`wy}P{?jtB_9|Z+A zpfFikkMzF3Y|2Gb8D}6K`&w$-Z>>_{LgS((nc%b@xNZ#GM2hg7cmqEO-Mg8UEtu1{W7l>=>x4elw_NWF zIIkrp#fNA!I;a0Wh;CROPpZ7|W)(`5Az@-Jbfeig5vFD6kqGQDv961&G=+3=JfXrGO_UUjbAAhHh zdP)qKb@kU8p3^c*DKhUK|El$C0a@y1GIQW*!6Aa(@VDVn=^C zWczC0N=eChKW5(Fn2SPb+}s$oHt`8E4DaF`nwm-I+<57K2+mW^8*r$%7-1fu>R>FJ znx7vtkU6%ql+lqG^}Md8d2fUNnwmE8^&1_n{E}RQH)CHPDTaP^k)1DulL(N8c${U0 zht}Wta4@5My}L_4{1f@v-X80EHW~JLNG4fbGijh_W*Q?mmDUXXXEO#~X#4qI)ME_S z!89D^8#klpD%~3{@^^)~e6Y$PqsH>`H>~Earr1Ll^t$+OXcm zBHCWcB#}KBQA-Zx6)UrTq81qx}T_`3H@ESI&uN0k-}3MxZNK-)fxR+pp-$I9^EQbL3(ezU+Oev9(NUr+Ei z@Ns#(RXKX7;qN5PV^q5RgF*#)BFOheh46fNbRxB*q{MRs!$4iTS?4n~$Af{`!w)9B zp2*o;s=Qv9%FRa5G*AuN`A!0ctNFs)2K;NW-0jUI>Pqb=0p6wLuUEE0WWYot=XSE@4_OJ1>}fhNz4)`#Aj#p8RS)w{^s~TIit0qt z{CIRK&zu777xbYGgW1vS*w9iGN2k(?(s!zTl+r{3HtV@kMe4}QS1?5+{x{WiWMt+L z9lzgAu9gt;hv812GHQfE1F1pA_$enyO%e{T;g8_4G}i9B~#I#?lECYVl82*JV{PM}&n=XMzzu(vyQhHv}h4{KH4u^vlBa*!zeG$Mx@s%1sXV zR#c<;Gqtu`63m1muPN9J$jJqXjLXWx$44cq(h1O$64||HXoDTrm1Zbp;4mKdl@bG=+ z7QG^zSjve>XWT3?lpg0v8F}bUsKgi@K3=W5EVw2AnjpFnq7_-@}oJMNE1KN z_A943I-@GeGn&0~+CsO5#}JW_w%~Gsw?OSw`6Coj2)Addn`xZ{I-TTo&(q!`=)nbQzs)EVvLOljvf*cXC zpw{>0Aofq+=O(o!5$AXm*KZxp<(DN%ie_*f|L$WIOmJnOmX=pbT50o?m)j&fSEF#8 zX@^ITQPX?^igB^+5DQejqZRg6Z5IZXik@@)ZwcuSMBp`4Kj;PY6e8i^q!i`XkVy99 zLWi&`J@bk#dVh=zE~d@80mD%A`BJRk(*vHyquIHq2oe?D3g2}b1Y$}>>c96-gst=Y zufaqhr7hpmI7Q!&-PT^@ZS1+(GOwkiBn<2}|B!2Yw#CP<6!y!#Z*H!`f|{C27xbtZ zdi;n+8kwW{P3?%}{dz|~TZ!^^+DwUYaTV&lLA%j&2Yy6V2H~eKTJhOuZ(sQtrhpPt zd3x53L`DY2;oh~CY~tSW6}@tT7Vp4RLl6Fb#)_6?4W3T3R^cHwrXprqEw{s)U-C20 z5A{`IJQLAi?p5}WO~qvjFCA5oF#ouI5=n~C6>PxhVw7xbExT`K<^x*U8i=(B#%Y>BR-FZP&&JhAz@*@sqHCf zHQM0kS0MZ$D=2^M`?sh_Ga_+}hZ8?hfjQ?gmYYgxbnp3~Rl4E?^7zE8sF!#C(QHFW zkA&fKwD@O5)Q*qtv}G*$3uf@l+O8z7uBa=uGx%bCk*3^4sP#fQwI_MH#b=#ys{1_)J5)!wEqFb_OXLO}Ev#uA`Qxm1^cI(w`?^s!%2HOjQ^uo%f^m?bLX!~3kHJyJLH#H<{$r?X0&7Ukq%lFoM{^+64ly_ z;=#0PVadh%4-~plv>X|2SK2E|dm%u`L4)y|Dp15rUs)UmG|M4x2VqLIu(fu$*YC6W zzxEk*Iovu&FSZeW{t{SE=qxYi$U+IdKuOtb`WPLvX>1YZARUXNt33}2VcOat#`hZd znu>-8Dyo(!SjgnUBEjpE`?2tHW-0_|nkubTnvqwlcA^RXA+mN*$QCby%Q?jiFj7B$ z;%2n5Dfn6$?G!}a`gz;&EqAiBc&pii2fe&XElcivC=QyG)HFE{T36osWC)c2>6R-?BL#r|} z6t+)ID~rTE_4>^yY54GcqN8SWA@^Koa-^#1n<|JerAK_=@? zKQi^+j*OnL#)M1mNFdOideYI)c&vRp`mHKJh|W+@I6I*nJ#|Bjx~TsBDX(xDe8bu1 z6TeP{Ke#hw1!KvrV*&Y_XuCYtjJ&Jh-Vap3zQt6Bdf#-9Lm7X*pSzasRlMaotKc7k zHzwq=D4$RHF&&(vj7(-FcRFm+l!H!wtEiddLy}W8w~xLI@_QX{K;9{9!dwN78uJa2 zxWSBV3VtW+$5SS#NK@?pB_Ee?9oxpM4zz%aud?I#2_objDB4Hxmw~I~T=pm|if0Qe zfu1F28q*EQk#fV=eqjSEvyg@H%B~;B9gBCZWbWDI2$d_J@Jyvqa597lfx|j7pG~Qa z(D-7V|FZhee4dF_;JK3<|#vjsorn#uCW1lWo=iUe&>?>Hj;L~hg!+Oc0%l+tzo%+ zgrTF|FTk)jaXaprPNH+7;Qm0#u`j8FX0WqkG;w*T#r+Y*Z7hSzS+q8cCe$ z{ltzi0Y4{l0XlfUmF56&qI&+exWHZIm6~ueM49BIBLB zhwyb=aBL>gTQW}AimwV*S7Ho)YQtT*!nN*C4<9Ffs^}7n8la}247k^{&T@Trv&p)p0VQxk;F(rUP z`6T4il}vzw@^=n7?(?1RE8y>5x47tX$L*4jzpfL$xxcc5?N3@h(RMowm34FDjNuxZ z#rXsWr#9!I;w`k>((;oVO{Ds#pBBLd28Kkp8N-u^=;oNH#Y2djM?IgP z){;VIelLBZNE+gApx^ppViAZ~Vm$QpVuFn2p^h_=o;tQC5@{zbHBhQZ)bRa#lj{&L zEdtjJM^i&gToP{e$ESp$=^Sw@b=*2+WL4GoF#4{p7rflmi2KK~JV_Ct>CMj06@=x! z{$Xv^pnZh&pY`m;f$ZPd95bqj8c)*E^b42v_~-Hi)`|}stRwrM@)$p5xiz)G&Q2|0 zk#gaaZ7toy@)3fV2#zrKaEe#ggC--)j!+dW{DfI&t?4ic#rw?>6 zPPRG%q)kDln3zf3q*2PFQW6TUUM(ZoPn`{}^VOIH#mT&pfEcmw0|QA6pOk0cvO-i- z8YVIlNw46&+W5mgl~Ctm(DHTg8^77vd5Q~dB(Xf627SWG&Nsk$3W9T4={7=m8r582 zR~xW;l`O7nj+wODfw4cVA2crNhEL;ps`n`iW_Y7pluhg`JcT;zUi_G>y*&-3oP zx@Q^3;h_@+Gs?Pr4f}$+Jn~*DbNBASjMMI!sa{n0yPgV7%JwHH|GCBR$0mCUS|()C z!}$oDArx*Nr`b^Qy3%DM~r{?}`#&o5p5J zOk2Xj7CY}vB~*gW1PLwPG`*_IKpZ{4^_0etNG`Se4J;~WOYTfuGv-*Uit?V3DNLZM zH)l)CW2OvucE~xYg1G0WG5#o-m+v{cl8ZCX}!I*7dx`k1mFU7!yy+} zpJIn))^WZ)oC=zCm=)oylT3+9oLm?}&~NxIGY$g}15;~xVOeIUv>f$pwe7Ean8;Ur1gdtl%jef?!8~--x-qvErhrOpM4&I9Oa#`zcFO_E0k)ru!Y1(tT(+?jWRb@>J*o{pjW#35^V0%qrss4+j;Mxmt^NWQI`s z=}yT^gs;MPHU4zR{bU=)&a`PQaY|{y|-J)TMsez=ur`Iy0v%gn`Vo z|4T9Z;bDS)*O;I@enS=T=gmSDh)5YZ2+}Q0gMc4G@Wzo`@MkIIV%UkhW`I>!1ES#EL8J5)HA2reBv0#kYK05Fu ziMstC3()GFk(^)GGYDUx+r+zEh-Eaet@sNn9W^Mxg_GN?<1uow4POu0JbhBxh!}``c zqkJu6X_B6`XLob+vAbOc_!QtMh>nSP5JE<%(9+z?(=Pfie{O9|a<3gUnfu@5pDP|o71?lb^{#|`# zo_NSp+S=jc!(wvwtiYs^^Xy0;|PjHmqn{@s#D8Qv;Iw$;uOt&882@xDh|UVPfZnh=Po*X--A6 zJNB}^#y5lx7%&v<{CFU>j!*t4Ws5rn)R(G?R;(_*W{?uTfz?YOVrSD{d$niP>=K7f z_3}FX10eQ~?AbzE>G&RsC9WHl$^G4CCL4WRr=F+gk951w$gr<8;mBv*Xmgv=p2Zv0 zAV;GG==3W~;edFlqD^E6K9IjeT1*|BcH%}1DkotQCPn-qn%a^y`DfD{Z5TJ?^=4{S zBJCm@m`=ZcIHZ2<$F1WdYT^btPzGN2D%-G!cZc?}AC2q}f~$HO|%(IxUr zVZeHeiPdzEM19wv&f-gd8YJVt7~=!iFMrl4_nal1YyVUFpCktf@U}S2ukA_hc8R0Y z>d1(@s+l(>6O{0^Hka4?VDr!k1Lc+ToCiU^efoRduh-&i>!Wt%s-jGn`|}giw0&A9 z{s9m~)a{?e>wIi&K>A|*7=j$WiCMyb z4)yNYe57V=1{-9j8h?<4o+ePqn+=J(@J7cjE@c;zUb@iQ40tq3&j$4X>cJ{8D0xsd zNl-$hB#zYl1mJ1`1DGgv6?Tu1S;!Ly@tZ*a7;pQFWp6zD5H2QX#C^nJ5?x%JxCDt_ z$b=E-IvRC1QK*iGdxu#bZs7U82KqY)6Xw-BX+_kN;bDx_%t-Lv*`l1-%ScniXLAmz z1--ZHPucsHb>WnT27V%vXv2wY(Lc*gH-9E6R&?5lAo(CY=$ZZkqK+wS!6*6(su2x2zE}uKGd>8>6^Tv?#T!UJUT0c+IaL-3u>V2wu!C*)lU9OzA6!ba z9yge`++kTifddo_#_}40$w>8(wWSdS#Q|>N7AGcVP5`iUp+njOdz>E}`Z;d$9#go- zjV24KzeYRft{K6FkTQMi--Et?QkT|6Ri9H}&$#42CjO@yWtv!bws4^JFvbt@KW}y| zHJ|Ubj~75YxqStpH`yKKqv(6MLX2wqbc^_xR9^HaO2l0ON8adn7Sbv zhL@t-;?8zmTNBcp<&GS)FCV~sEB*85X-xyJ6YSXq2d5Y~j?5&& zMB7ac(g<-LLzUm8hobO-6~=Bw=H=ot9b@Sz2CWqnW4CslPjw-5P+frxw51H+6Wdyw z)gWO5+dnuY0p}$+d@FYq6ZX@Yn=_yZ*9zg(oPw!oR2h?Xb$A9g&nd)TT%Ku%05Fui z$fp)l> zRQwd8l`MJfEdu7xxNqM!KOKIvb2Bygpc)XY`OT4u7jJ=zDkM@Kt=((;Za9Ur!W$>J z`iCIzM0&vQlA(;YLm!`)G1TLYfN^{o!vzlyn1q7(Bqd+`WZl|YkCC(^YE)p%XbCz| zx}AR5;jYn2|89f7u%(mO*;@I7=ouEyDd`&sa;Y3!0r0{s;7daHTBs{hHfiHvgFGSR zC5F?;6_zKOS(wGS&8RtlLs{%JRu+$)= zh1otcFE540ra@i@2f5BRP}prR&tV{ynS!{>?d`G?6%0(k@Kfwm=={X**=OvRYr~&%PndL3I-#tqQAxGfFgN3kX7nm7Lo9udzn^S+q zMFf3gRLV`K0W6X!yb-4V8xYUgfNLIKT2>`)Z-5w$>bhj+To+i+KOWGXzdfQotsCOh zjCC4K4aq+D3e?ZqH^wW zFypBX1pZC>h93RH+H_$+;Fyt@iE)}^XbA^E6=#=vS0~TFhpsihrqOG=O8$W9w(Z8f zwu9H*7oJUEWm_8bFY>F+ZMuhbovxRvfhx?iZUO{yVx=@R#?+lcJb^(#67>+sNwCi| zp}uKaVBs!&aWvks{=uX370?bS%K;yc1**_QJvCmR^x7IP`wV$=ZY_ExLVcPTnvfQb zqN({d9fkm+jG_?9`VbBXxThgMB9Rz9?%)x0(`^u~hldwAZ1D8vztP25;3GI>GP0D* z$t?2mSN==mm>i~o72H_0{uBqS$h9-p-f5d4{7ulWjq*|C-My9 zeKXNIJ(47<62*ckOF_u1sMUBy7KnNNf%}(+&XOBHcfwDCZ6qXS&bDLYIUL;suY5N* zS8BoJ4`LL6%Y=0K04s5mjPT`|@DULnx@ypdZ?pJ~z3(SPRCW*E%ypR*6n=fBu0UI! zt^nRper0B+;z(Rc5KJta&aADMycNjQg}{eAJN02>LX&k^Gs^k)ZSgUM00jeR`UE^Ns1vG$;*V5nbk(d|=@+SaF>6KgO zrdKk1JYV92i;oOqq3FiOP*D7mJH7*q1bmtShlOg2gl|O7?Ik5L#&!df1^my!E1gDH z9X{b%+=u|1hqmTFy!Eo^l6TJ~g=!-cF7T{Iy-4^Ehq21l57oWP`abv-v zG&Izz_FZ>h7fBh1#GwN<147e)D(yoyg=7u&&Dq{Ch`;LmJdSZCixoA(XOmPw>Y<2Y zBzmAG2LGA8Xd+AIpI?;O7?rH!=N<4Nf4V(i{zTxc&egT4PlISBaF?uH#i*$F-= z5ZDE6vZfO3|A4k4RE&UenlLOZ&qSOXAFC(Wd+~sp6N1=59pJU^q!g%WWL?I+uF$)cU;==@!mB zpNamRp)xknpV=J+V~}(W4f}=xB#NGiYqGx8H%jEWZs&IeG!Cxji|soQDoAN(D1rl` zuxWSFx6{E@vDe2lKl-2u#y~Tc@Dv2U%3)^h+=>IttTMYJoL6qv3D~%TObo`6?ZQ@P zY{G2lAg<)}8@nTXFF#?vYGz=B0ySq;R8`fTKchM^v;Hz90s~N`f;VJuqVQW;g*fOt z=1yO$oW9qPN0>T9MxOEuXm1S%$06qa8IXb?9`oZ0IKRd1==189M_`6rLuJ2GL3I;B zz)}A|4sfIbUX!}~uhp^CdQe^I0Wb_2?JV8PzcR44KgoovI7Po?tRRu9y?Xczf-0l@ zvY!notn_U7IvH&)^UP|OVf6g%!JvuMIaqV^6tIcD1XTnpQA^QTX&FjNLo5t0VOnCp zqi|IJu}`0RaIFs^FV269Lv*Y?M?S z-VF&n$i6|KCxtbaetEgLwHL;6!c=;bVPs16FP(%~-rwhVcwIzs(}%2Sy;{Hbu#i$n zMxpqFrt8972mow><(kmy&f$7$g(VX8YM{~1m|KtaV-TY9VYwg~)xkT#}#9a=Q^+P+S@6KAr8+4;@=GNZEK zlKH?Hn@JE<#9rZ*R@nH1=~ix}+;NFdqEO(KaQNVwIF!dJe}q|7S=kg}wfOxDJD<)y zj%HoHvwZW1i1zCB55zoV3hFZq$fzfgQE&w=fZ<)3q;7wLNt>nh(GlF<$jB_cNAMiC zzEb1)#Ww3#wr{DHTUZUfkkG}mb`Qu15Z_#<6x)60R(HA{7OeGaq6b(Hi2!c2F#I?!(e0C|8`VftvW{p5QuOBMgnyx(MO(dT?bR|Rraw$a z9!=m7Z66-h`2pM9@awT0G6Xei_|U+}jvXYpeKH@cuAHFfBi8gqd90IF%Fw@BNkN(cMBkIzw# z2-(5?byFGp0Jy(|O$(LXKy@bU5x}#ktJ_{*NzFQRzR<48dm-9Z|B9;0BkzfMU;fjf zqZv;;`AYV$?}`wstf%p3f@(mV1Z-LTLNj0|~7k3H-H@2juMMCkIABD&)d zFW2j8hUoC1p?aU0Bs{O-;6g#l(4B3tCT5hYSs3ReoK9|C z*1}vNxd^{LywK?gq8Q+pJn&t$;YyJ~XZJgymFJ|eTj`DHIorZ#cK2l4n)~vQL*u5* zt_M!nF>-SwxK!fAB~Ua#%ZlfC$Ea!;#N6HC_3g{GyKTflLAXTd4Db24YfjI9%&1kR zAc(E3@bC<|d`{A3HXCW&13`ygE1@hA7x(1ulIFjj=gi&TX=;s_@auu?G6;d>5scF& z^!ay+D*ZE{U(%mUy-@Jg`O$S%U@D1Gdu)Gb^L!s3uX6Qc1yFGyqM`>27y=Q;-dLDP z6j%4QKs*yX-fFC%L>62`F)@7`xa^`IeR3m<%|)UWPRr7S_PSQrs=p+WB!KZBO}piH zW+dpPvx82OZSUyB|3?BC_fudYzqB;%2q+(6MNmb=^z~t&|4NwdFE%t2VTdlV0ie0i zgllSX=t%(&Prc@z@ZUp}*OS@>GF>RR(6ke4At57i@xdGrF!^qe_De5bPgLRcTRPlS z2%RPTAoRB0TBL$pLLBqFXU;^`CXxh(je$#*j558;KDJ|Q49$} zf6MXhdAz|J{7m(fWcFWc246Xn2~oVq7m`X#3!(W;O`7BG35mBa3&aB0v+1$L~h)@?aD!bT{Xhk!+;~7(#!Pb?ry^(({47|yCG+{WP zk22uVUXv(%dNZi}vVCcQM8|osTN`BY{ z1*XcBH-=9(l2*YKl7gh26FE`A>wbgy_V#MJ`RMy=q{MA)@lG2M4don0$E=ITdneB` zlV}q5ch(mE0656$(JW^gHg5UUxo*)_nNa&UJF>1?Fnb^K;3k?eOD=GhO7h+k;3<5CM1G z&pHN@FG*3n;Q7>!Tq1c=-~GfYia)4xIo%5WN_nReBJFZ|MNK!SvB18$N2c`aFId}J zjMEA!T^#+`FY7JZ$UA>rh-Sy~k7uBlPPWFyFd{rXdbeMOc5rfD4Oi=y!>#Y#B06O& zE9^?dz_6kP!?N5km?$?mecOlZMipBVUrS4rG|5~f;4aupb=f?TCA$`qbrRD}>QuKP z3Q)Y|-w|M}pmq=Tz{`o1t#^}c^AQ)PVm?aSxXHL5!(zXk5QgmADIGghl}%-+1*90N zg#N5|FDTc!$;_t*cs={4QJrFQB;{uOL4eCNQ%>1_`wCnB%Rn(t|H(JF?Pfi)Z@gU- z3i7fBF#fxNeq1Ovv&kYJuLb=jh{{Jmf*|9OiKz_})6-AZSRZ_#7Fmv3YO+wt{!9|* zVAoy#<^7bpp`)4^aJ4-=oi>MiiVZMQ0~s%c3lk7P_!GEYkmmLy#}E-qvi14PukIaH6rn+ zX6VptRo!)x*dp|Y`l3QHB+B1d*MyM#nE$k>6$(%YeH_Qf|hD{GQ@cP%uO zzu5??<93g1`etgw2#kazBeY6=(FNiKOkHm)638(Ua$||7rueUKYWwCseZ0G?Vdth+ zPlJ$TII4o+!o^%H;`6 z4gBJ~R^@Y5jA!7NB8&&$@`<@evOY#AU*1LMn`A9K7F@) zPoQdIvY44+T-Pof{k=>(HL(y-MqjXLjm{Qp!$03*#Q~(;QVwY?C9Mb)LtGvn6|k-c z7RvU^O5lO(fC7wgC7(MP77zCQPe++t@bYvDT`3k57$9xS-ZJ?xJNsg112%$vZXqnD ztW3pbsHM8v#Exn%Ii*|WL$Jo)IH-38U&@h8Npmy~16of;*kp0t@T8>F$iy}ENs(7p z8QP12r@;Q)@bE6R-3yk1E%M+mvNtgZ)=7a37uz~qps%i!0MW^H_ROZhUg+fsI^gtc z2mcnAh6}K=rh{c4a0*_2%&Hj~;XjAP01_)#QLdt)k7~!mV_8vNsJT#G!^72kBN~)x z_iJf+5+kn3Rup_{fOx!M@W2(Yw6zWX>qRU*zD`kYT?Tx`rvydqUk?jYfu*Ho-3>!B z!@_~U>ZpGBhYWxzu-X?GkI#mYmowIYuRQ*<`vqYHY##JNCB?7Y)~my?${=_r0U;7i zDoWt<4_953ThzWJ-~qL@{EwZ_#=G~;kwWV~0Xti>dp<$q@q3b0xUeEa;a#Xk%e2ab z$tLD6oeSSq1qq;mdOTo_U?IS0FKjE6D$f--?w|9wz&Y#oBAR3PDlq!*)40yFwG z5Af(H`|J9J1V60=sO5!}P>j{L-po(*>|5!!6v9A`mfTU<4BLAPgx6)va2FS4x}G(t z-A=Bh_v>-euO{(Z+S_9Uo&=`MPBcd<2Sao4UsAW)S~EouBD@w->Jgy}1ZJK5=O?a; z*8njwa*tH)t;ED$|2|*<;M4xjr?4VFAGSK>_rS8`eRRWo&S_zD#Wit~rRmV|Mi}(| zYuq1~#Niapf`il7^r@`c*ksksd3_bQ5d^kWH$VIidJy^D?q09$^3g zuJfGpUo#-1T&*~42?YI~^DxrjqyE|D3Z@6n70{Q8>s(-Q*6IHBGU1)ydUXGl>)Og* zax%dSfDWp)Q7@A6%i`dd$FT*G*HU1o_VGS_Lv{mCO+B}ek`y3d+p+69T7s zd|Uq~fDMl{S$m~%ca2J|XC6!JL^6xJbNy zKE$LtrTh;i6D67$ofv$MCG7>HmpEVqK|&Vvac{h|vP#n4iNgR7M@E0{6$Bt9BGIH# zG=p(T1J~<6LO_C-|1AOYg$~fu{yA2xUOdCFl|FKJS)7Z98Z%pWn5UH8^-ZWm(gLrUG;2-;rmHL+Hz< zm}fNfDU&~w+Q;E_m>S(2huZ&R0icaEwN^n90Vb=isW0ba4sHn0U6Lr+ApmIr-wvI* z(23D5$j4W&Zt760o`4MqG%BExUz&^UoK`5vD7ZgH4_ONugJnx78$>VO2Hay~{EVwB zmfuVAOXcDQfNj|{wn0YMT~1X}B>(Z}Px{||dTe=TS%Re!<*2*syO1!Kq&VQJV(T6g zB&EFYVh8aU1&E(`zkXf0E(PughqiVzE_P7o$%?3|BplG-PFH89qnq`PA3n0PkNnE8 z>3swljk21WJ0kJd`dYw# z+9!OY^EEuM3jI&_{jfgr&d`C@3VaQwk?w)8Z)WsakzlHDJvrF1Z{067jlQ?w6le@- zp*VV#L6umdbJ)Et(e{%iFamQ9%D>;bFQOjZ@!yJgbE{6bX*7#et6!)u-mI@aq4q8R z-Zeq%^?gxW;X$ivLp>JI9kTn`zzxV2y2dCO4>JPVgHH;qASc^#8SZXB{8o7>Kjyy` z5#Q#hC)aFAZ#HgFt-LY<8^@JP3e|Y6jyxy;V>=CLA|8mV>&93%*e~o=YBu6Ld|A>5 z4kzV?5;xdfSGntoFqzhR1BNk~D;M~tO)ul zdBj_~@we}6d*r>Jf7A0XYUfu3;DOJz)5ap@Y>mdcjv&3Usx^yLvz8P}x5m~( z5dEwkUv2-)+FzX*WQFbn=%%Qsg~hx#vHbH(N5VLe7o?Bh*9cRV;9iTKr9uo;+qHr? zUgN{}ID@RvTBtQ4x#;R7Ocm8%xjnBz5~|}mM-uwq?$c{<`5g!C2m12CN`RpCR=v@1 zd4*HdAha9~Ad4}++vm)lvsF|}88P$7OM+FWP_US1TUkR!aL z6V!yf2!`CA+^nG?s+p5~HCi4|nL0fz;r}v;Y8z95uKcMZEgAUn3Z#|+tsC9wCF{}T zz`4|VV@G7r_BjaI*w|$IlLTO7$vK0(68xgb!>_KHA^XMUQt=CDiK!w)mge`_gQ-+K9Ew*er-?{UG4_S&2-i;LjXCk<7~ z2!}CIV8;VvZu`X4TlT1f0tYHNsCbSOxTCBFHn%^{*I;{9RfpEY zZVW8`b!4&#s!n!S^Lal#VxD)1yc6ssB1U`xc`m!YHt5;0s3&XAelIOar}t*9J8#9s zJxCXb$)x95j$(<0vbB*E-O_T$)(6irpad1dkE}HrYL**&eEEKK})HDFNdja;0V z@e0~U&1?oHj*Y*J%`9kPPdXr3j*LI`{!LrjcSQn*2}2$;PbO;KiNUv;`|kn z+Ywgdhd{ufL0^8uzVL%h*hj9m>f9|=QCkR}C`L+vw!R~m^3%$4 z4HOXgS*}49zz97EMhsu96*n_X04%EUpN;OZ*jlhIAn|vFK^=>CJN%rJ21CB!i#gdx@I{a~9vF((`RiB4W*CeedyQX4;a_rTYjkLPD+|52hx z8hqeXW9ehNRBsalKF9B0@EZd#!#O*RpX%X(j!)vTju8f7`#}<~pQe zv(a$_$^Sqci963(o!vi--wGEnw|OCJQ9B@ViMSVjm_Ci-$t22=WYqy)I0e%^De%P3 z{;3DNGgeSkC$s>E!NsB(Nhq|LpkdV0KDzSA9Xf<#Zd{Jv$D{V0u8c2ul*5&MUR=F& zYWUH*hT%k_3;`E6hJ$Q}%?t?&$>jSZH@leF#{a&CET+Q3wRoTXU|by* zjIPFn|MM?gtP}Af(c&?4aTw&5&orPkM}SSkfSwmDw-C$xd8&!8 zfif`-U}m*F>A5YhY(}f|)c}rOH-Y+p0*495Z-KNaTj}%l)WRIk&Ch3DxmFt^PhXJZXW7yf2 z=rzZxP;O!!U$!~ZmznYIPBv5<$3Rd=&tj8f!);J!i0?Ro`KDtnhzxtdA<1`r80yml zS=+~d3>vXe{^SFlts047B-?d`%n46;<{ldn!wPl|eQ!LD-?qz1-IP!_M5#pE*?o&}$ zqwHs&w=%$%sIXssv7+Nax(p0vkBcq1*K~BqdMYm#nw1GOSh|lU=0-4uM@ue8k4Y_O zgx07MGqPoleFaYi7Eo}K(_HdSic1kpNl8I0-ZP$k2Pb4VgaH-@SmxI0$`(t3pdDw? z4g?eH|Lz407R9pZYDRQ-4MD-M5B9^&grWUrWpCEiPGE#)L7^GJv2p+gSj*sw*(xUl z>X@JOB^}tq@h5{cKK=#QV|4ofl@>f%;%759e%OTPRd4_ft|17&KmJ{n$6^A9%GWYf z@(W4#4Zt@Ct{2)8uLyE^%@Cg4j|jlG)KQQcRzwl}mS=!^A{mkhh1+pin0!sb7GzL! zKm=7GGV~fR12mMCGj)rJ!s-GjK;yF4SSSzsUNYk?#Of+)XHX}z5OKZoTWyN~D+mvs zyC`540+2_UA5aH2fsy*M)X8vl^^&=}w*hw*yd&^=GNj{9kB1UCW&1e6J~35Ql@lE+ z+RM@yAG!a%r;|r&ZtU+8rA;dxov3ZZEip@azkfw>HUBZ~)q3#DNF;z#Mu?N^#n3(Y z+q;bAn@|phtH?)fc@D6V0QO^7kgA@W+}AhN)veYCJG0Ob)gwQ}fAx<=*k?yT;Kjjg zg)S;I{XCnYIylUAeiw~fTQoGf=!Fk=A6`lx=}+12e!%mcJMr?#DKY(>C6Yk=`JG+WB@mH-W@kZ20p${I`2C1*YjuMiW<-@bvG$ z;_T(zdi{Ow>}b{dGWEq&9`AuW{ke@jkS{dW`0oR**Cokbwi5}=^Dp-_mJOtt`<2-2 z#TFiAp+^Ss+{b9w!)x!>m_K13iY>0)^gLDZ1)q(t4bzH|%n2{2avpBy_dI@Aslr_e zFdM_I3 zq4y3-2SG#cf*>8Fw@?Hj(xrypLa%|)3FJGz-@5ny3-^aND{Ez)tei8G*?XS->}O`p z<}&lK7hR0YsM8N}Lex3*1WRB3tPwY~PP#RUO+g6Irsfzh|t-a32V0Gj*NombW+? z-u(^kZ@h?0`7N-&m?AfuUuRx9ek(=-*s<@ijABV; zWzaTek*rFD>ag_UdQp$b`~h1<^Km{w>Byu*WB|FPmDSz^(${$MCPzCFch%xscfPCH z(q8bx61|TmnBCd!l||nvw=qAplQVdwsdLAGBvGbW^JyTXq;q_7sNDfnO~bl7oHQRg zuWa}FcJEr>nuBb6rQSma;CoBudkpo^Ucb0LYM!?TUldMvq6-qsjWOb3g4!iix(To% z&0l$C zDHNQr-KZbc4PkxV-GmJnv9mYA-%{o#KtPi{LF9uTU66N8X8XP z6lcErtia>)q5n4HY(2O2nPl>I#O`&*UpY0yKN1k@Bh)I9YR-kojyTjxp)Z+Wc;qtj zvR3ZL-G4YBR-%8Y8+3}*8WX0I4kY{DmNj%9g)wNgdiw9@*Wvs+#U>#ox-i?(A{vKy z*;ul@jIrDRH|1ok$ARf!c0=Zw+#^H-%Bse9@b&1ZNRde~fmo^j55t5RMmHTuoIMg6 z(LrFb8!E+T*lbmqUFlkIk4=|LNh_>cw9NcdiEiN4O)lPj+RAnF;p-HQ*Qy@?i1I1D zy~AjfG^r%|4Z)3Y{x!`cS-UQ{m)ihU+dvHm@u4L--Jx|#=3SP&lbCL#_W8R}|G@O> zFS@1LZ>AfQ#%oD&~a7lFhL2KDUjb|h}a(4XwNx6w-{6!asj z9Ive=D;8BRTrG>Vng~3|%6o*`?NzVD)ix)a#HbU3X6vO|E9rhSC?IxkI{ke;o%+#8 zN8aPPXk7*X3P=2f-#nI648>57nwzAvdkN9+BG@#46RNyD2ZIQqz$BAW5||Q zFIu0YCovN1Oga9i^Ref?_dM+NA>&G3`!3g{fcT5P)~UK-hc3W+)&g3Nb{`^lM<8qy zt*Pb3Tkd<~(OQ@ATx6of6a-lH)}oW%mE$tqzWA~ixzdX)+F5 z>Wy9^C}(riiXwFN2Qs%->u(jE;$12VQ;_cT`^cOQR1h%w zcVRhq_#ro8ML*z4fAe!l%TgzgHDw3>thyG^sR8T`gxs9aV?x9c=xk-i0kJmU%jG$Q@G*18g%j zO=LPV`E~cvnl0cF8>_qax1G%o7Iy6(*-XEj0cX3-xiC)rWc?&}ohVdeRrRi)#!kOn zxnZ)rX*)lmNV|^5qeS<+@y?`<%EHAByPtiB-@%%k3BFAGFtf?%4O&=gd8+v&!^isE z;4*uWdx#y}{pr_~)7cQZ%7+(ybNweN)5oaA)C@Ns^R)4@rx4%~D**92@7FEdJG!J~ ze_~W$q|{Gy(%8J%%jnkWpqgDD34j1w=+Az#JJbpNV|CiR&7O9Om1DCbO-g*hmsYz2 zaObjXAvK@td7*rOGn_PxNfq~hl@5TeVihWBH!MgfB^mFtV(An|h?iEY+}6<(wYHgm?G7#x$~@WoOwUDe%K?Wa3Zn~m zS)rfvY$%)sJEo-EfMeHq=8b04lxG(EQn^#ezuLg3aGL2YpsM<+_UU= zHLf%Z%a*RU)sAzRIo1bR<)GpVhYu0BlJv**oTk9I2AvFV0I)DOSHmfBw%asj?>OI^ z}#{IUDLViAm1dNqng=xZ8sS4l33b2opVbbjbAl=EQWVm=2A9bNP59@0Y*k# z38$X5|7kSwp*hF<*s)UXU|4f0-f~)H3iQ^=e_?xl0YmWNy z=q>YN#2ufX zn+=gNipDz3-rJqm+vSArwX3C(k@-0JE*|yq`eXo-rU@=fG)k~gtslfl{gRGp*q3du z?pH_n+$UgfNcO;!sZ@O)0kex8bD!nroyOB~ZChkMI0TeduP??O#f)I=x(>LiM)z{k zV+-ZzW5Ir`kXdm@->m|y!cJuQ$7FZB`>gr+@f*w<8BL+@STrIbiZH60^9?b7kkxaF z`>lP6)7Q5g+h-WrrZxtjFoGb4*Nae2 z>siZ?-aa1q;EC};P|DfG!K~Qu6&#E*GVyn_LYAV!7_p>^#^{UIgAtVsk~!VKrFh5sJlk+9P{R6Ab z);WV9k`5*pKBdu0ikDM>b1QU!@U&C-mU}hi*200^8YXG(&NgPiS%vn<^-%%SqaHn{ zxj*S@8Aqq@N?fTOfv=0V?~7*g%~}|m zfWTI^fe@XL#bk^f0rDU}fAa%3X<=-F!5`dF#`ngJ16uqqX=&XZFS_WC58|b&`oFs0 zbUhd^H~oAZ>+p|KRkmM|_Un}u0vXQSRea1nnf18~Udi^wr=msrS!3#UU7F>O-j>@5 zmm;C7r9xwv?8^U5m_G7ia_GFJfMm{MbX*aBwk-MDUo1>S!yfUKpW$tr34L<8!9P}o z*=scXU};I)oP!M8z=jOBr~mV4rWV{M%<#7Si5;~e7W0Th!+hXe@HQU0)870LFb>{_ z4~~QulbMz#0T5`LRt_evPz90f6YtlnXzG15J$$}gc;PSZN~tz`lce2p9S5+xR1qg4 z^8k_0c+C$MoNV0HGkKB&)7 z^?v)OqD+#_jR!lAsW~;NNbwwpL4lYi1~2bV`mkuNQnDb(Wm!(Kam%BaLaco}VLHHo z#_a;xGaB+oie8YeYcQ%(DVlg+e1~8CI+HfNCUSmL7cFx=HIW(6Bk0$zo(T`eT!K2W zVJ&7=9-W8f-k50yPn#&>pSEs1K}~y7W`S-xW=s01Ku+7Vex&V@TAhKkpuZ9qGBn%UxWKuz5B&;_2)Z|RzrqHn;`4V zndFCYPQ8P;153P~0HJSx@ebsLoPH@A;g+59uPNg`-(z*3o&a?#c1A$nqKO6pygk|# zL;h}h0#kG9secz|nVE zoqMj&Fo(aRd=xsOSVIL-2FdxYREnBv7R+Br-ZprOS^49*s1qE7_=-0j02-Mv?0;Jx z2uPdLt$SwkxSqd4d`8u`gG&WKQGm&V4JeK$uNH+ou~2}|boHnigOzy@??~-O0nOkt z(@RE|hjS0@&3fx~fb=JFxvP-gF`63Rz1PCR^_qZ3E7jR`7=q%~eh-ybdxMo+kA7$>|V4goG7E^|fSC7ay=E3ki~&VvwYmyV4Q z+#LX$#(mh1W%oZ`WWjG-%^Q-Q&)AiBz9b?%|M2@aR-rJILN;C>q}c0B5}8*-@Ql>v z7JB9cIo5*876c`^JNFOtEGlTE6aYZixWv)SiD@XkoZfE;0 zWp7|?-kYDu8`suSFyzx!^3UHWYP#P?%kLkmAx~CwTLc%nnP6;8lHq}9(1zKi^G)uV z0@x(e}TxOTopXD;Bpi(KZ=)@-BhMBe<9P_Z{LD<7c%`(#D*@qns;|FNbx zbei(tv+vsO{ZKPGo`PI_s)D|+1d;aSf6^I}4Z$f4?F>51R!iclm8NQ?#M;8Zuv!M> z0#^0Lf@CTC)xDk$XQ&_UalKvWUCjESoQB+I-ktmv`@WTK6B%#k{WBjt0dTE3ftCyH z%k$98UO|dkb9C+1KE&SFm$4Ma#-2VNOX3Scg;KQPoBaW0 zi#SOIwVgDbQ?r3b9RX#B7?70QZ*q$}x}=-nQ^Jh>oS{ESH%ZHgyq8NWH*quehy2Q; zfmJpqcFjQfq#J6sc)(p^t<_+s8E~L+d)tY#Lqu=iP#gpd%YRkH&l`hb@d*W3Qk zWuvq@J9y^ohG5_i$b0K^rO$F*<%(V`8(3PzqleOQ6Zi5aSM>cniSUZHCYCPF0ciWy zCO#COP7+EN@4tDqrsYy?HOA4r=*7|xaDApryhczQ@Wgo6nfXk@fnFxRAgp&qz&gEt zqzde`l!8DXbV9{)eGa)<-s-rhKT3{{r|6_vB6wVxvmzz|8Z2_M-oCBI1w#kFVEe#YE9(Rv9@!H3)eD_5bN>g6d2D+R z?Zq8d{tfr~XhD<0_mKN;dU47;KVA}-20sj8Z-QuirhC!Os&I60{RBKJTLTOS@6EMS zHtwh&+ocjRra)|u(n-$0W($2reQvz(V&uyK@>?9%(5C6Bv7K@%Qiiban|5 zUj%Gs7O4$(p_PL8Zsc)YK1EYf;LlB#(w?2|F#w&pwgYVZ!|#^`l;^Kh=+8jf1~AWS zAOMlZ5|pgRWsTJHJ1sa9Quif)Hh%}pe{ZSc`z zo1kIiP#p2-K&_Tl zU-jD-9s)8^Vr1Sq4To)|sv$ge|7;ln9eI8Fy4g|W+q8{8hkgxp3MjS z&37q3r{(}FzcH@=;kM6CemMOHd=X(yh=`!jJ6Np`wUDg8lgHKkW$IqFFrIat(=Y~U zrjnGO|F2u|Bn)!dfePV2->EFTiX4#_)Q<&6@kZw*cNEHB&s8-~lpJ0HXtx#lbVWav zZR^`9kQp2YU=OhmtMO>?=M{)W{#on^jiRR1lE^o=eS`8xNf)boxB`HmpnyBLbIXj| z)3RId903gEA|eH!NrCu2N_!%t%Na_ps5wsU%~EvhFCg?SG%nwMF6zV#pu^sHeHq_A z{qw|@1)m6ixgFWZ^$3G)0mr07JivZ$_#R8kc$IyKqQs)++?r5uj0w8{cm~3Hip~bd-U>8w7DgWj7^hD_l_Bndav9$;2StXT`S!%_ zX#^0Pyl)`jc2U$!B!R26A=3+#lU5HTvbvZWGL@nz+fo4BJ$oIOuDn>vY~5W#dJ#eU zVD`P$q`ISuWH`i+J33FfBPck=6%l7Um&&Sd^2=o~y}R-m81I9XrO;~4@Hv9P>8BJw zzn3IYsRqp5VkSL%h_EX{ zWU2M+&s04>uGpcYwZoJ(bhq;$Ig#rh6N8q<-N(eA?JgwKX2av`bQ4h8scgkly}%~K z{fLFN{X2`S(k=4)B3TB{PTew_8cx8NFDv^n!0p4zgnY=J-7jJlbOvY++ULY7ID}T9Zm?$(1 zmH%%)0a_}Rf?G597x9d6aBROd1mv+?z|63cJY{&LIZi^S+O~F>)R(f6uC2a2Y1Uel zyt~U%%;hiQ#z7cCit1ts{38b^@+NK+4E^#Tr;m*Z>UtX9_^^?T>r1FuiRLE;-{Yn2 z1dSgiTccqMf?%FD;d%$uXCX-A)x1|)%lq!r!kVbMtyZDXp9=3ez<8QeS)?*|bb93i zdx{{ynEFyEHzFcImV9{piXbmpxD=HZO zsQaU?GOq=JbF{} zVb5rRMIuiBb-dNwT$6MQRG_N0+sxHT2<-PXI?wfYGxgk?Hjoqk_GCrRV9)dk|nY6Wx%QkW(3uo3nFA zxy4JzCB#3Et|&Ls9HX`zb+oj!#-KhD#b!QFdWS+_=69#VOiziNorstFp9pAZ5dch) z>Mz44Ib&7Lj?s9r0-$kh&6H3xrArhpu-12f&HvO5WHA?>lYDK!a>!ThLSgF*fkl*e&n`?BBoPS_srxDlLepEqm4DCc|Bis7JLX=Y|D zzK9j=44*wSI)$Q>Q_*DRMZYstE-H_UzL8|}4x{!TAEU`qC7=TrfL2ypq#Z%yvHkYD zR>7WN66I?vJsOOD#Rni-4;a}g~R*{UR)-r-~JK7b9Au;t@;3zI@_G!c4 zdI?$g5@#k(fTF;KK6^7&@y|Vq(i2|+Frvd_o~;ZlFIB$+8a9T#f_6^ylpBMmo0Isr zw#sJVY192FB7W1tR)Xe3>$SD>pjRAdZZzLBnR6Cf@YNeC#Rq>=3^vW2t}yJ%uQHwe zc?Ft&-rqQuNsjJai-EreYxzTGle?{-avt^>f2Th^^aiHMy%wlQ6@Sj{a0<_>JiYd3 zjJyO=A|V1Cr|+#JXrEu`s;K{X_xX`d@!OD9*R?l&J`dG+9EEGDr!td!!ugH=eE^xh z0kEB8w%SwbLj3+Yqc@SaVCY*LI}Y%bF_q#(FeX?fIL<{t308|!y<m>w> zuH=gDqsXubU~o2ghfL%(PM2duess(-`X|iAfqrlUkj~d9%nrVqJ~osSaUIur9hcpQ zg#4&+yk5^TZN~Q|prd+eVC+s!!x9crsoEn=TmgwFAi- zN_xl-hTV(KE0X=2G<9%VA^+)Ij}3fDN^{h2Km3(7)bfyDNh_}xIeO*PG1Ag3E>+A} z9$z%PJh(Fo2Ro!olq-DlohUYvidtQDW#jCY1t2uM_E=TiNgaavQJxQ->jM@aQl+fv zYc>QRr|>n^tg298@x$}%nMw$2#}Y+n&$YS7p`|2^5&*8ZjPUvEuZl?7AkII2e^G~C z96YkXf5y835q}2otLJfb;8C-fyrKtHiw6;egHhLxPQ*I5dGOT_lJd`c3B(Dwe}DWr zhs+WQ-eL_^JmgjT&mUuV#&_oa%hfjV2DZXQeNN#`e+~$p{6i;H_roD~8o8o*DDU^} zmKUv9fqqJbexW~j$yUszsHwyJ<_S$AK$Ci2Tc{ATiY_}!&5 ziH+LJEy_cb4&R^Zj9k(iY~ zJB*#@|J(qy!X8U`C?Nlz2LCn7!xIkqzZc4M|GoI{7_fo=I|l#1j{%OQ|1?sG2*_da PfEQR%{Z++Fi;w>Um{*4{ literal 0 HcmV?d00001 diff --git a/zip-0227-asset-identifier-relation.svg b/zip-0227-asset-identifier-relation.svg new file mode 100644 index 000000000..de18d9914 --- /dev/null +++ b/zip-0227-asset-identifier-relation.svg @@ -0,0 +1,293 @@ + + + +image/svg+xmlAssetDigestAssetIdAssetBaseAssetIdProtocolAssetIdAsset Digest diff --git a/zip-0227.html b/zip-0227.html index 44f419f1c..976cf9d31 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -169,6 +169,11 @@ where \(\mathsf{GroupHash}^\mathbb{P}\) is defined as in 10.

    +

    The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

    +
    + +
    Diagram relating the Asset Identifer, Asset Digest, and Asset Base in the ZSA Protocol
    +

    • Global Issuance State

    Issuance requires the following additions to the global state:

    diff --git a/zip-0227.rst b/zip-0227.rst index f45310628..b9cc251b4 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -151,6 +151,16 @@ where In the case of Orchard, we define :math:`\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. +The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram: + +.. figure:: zip-0227-asset-identifier-relation.png + :width: 600px + :align: center + :figclass: align-center + + Diagram relating the Asset Identifer, Asset Digest, and Asset Base in the ZSA Protocol + + Global Issuance State --------------------- From 6c07f7bf8bfb931c85021f210bcdf7751f63a99e Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 14 Feb 2023 14:51:29 +0530 Subject: [PATCH 075/101] adding note commitment definition and instantiation --- zip-0226.html | 107 +++++++++++++++++++++++++++++++------------------- zip-0226.rst | 31 +++++++++++++-- 2 files changed, 95 insertions(+), 43 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 740dc0708..4b158ec7f 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -53,29 +53,29 @@

    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 \(\mathsf{AssetId}\) - . This Asset Identifier is stored in Orchard-based ZSA notes as an Asset Base + . This Asset Identifier maps to an Asset Base \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - . These terms are formally defined in ZIP 227 5.

    -

    The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 9), and by extension the balance of an Orchard transaction. That is, the sum of all the + that is stored in Orchard-based ZSA notes. These terms are formally defined in ZIP 227 5.

    +

    The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 10), 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}-value^{new}}\) , must be balanced only with respect to the same Asset Identifier. This is specially 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 19 20, we propose to make this happen by changing the value base point, +

    As was initially proposed by Jack Grigg and Daira Hopwood 20 21, 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 \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - an auxiliary input to the proof for each Action statement 17, represented already as a point on the Pallas curve. The circuit then should check that the same + an auxiliary input to the proof for each Action statement 18, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - is used in the old note commitment and the new note commitment 14, and as the base point + is used in the old note commitment and the new note commitment 15, and as the base point \(\mathcal{V}^\mathsf{Orchard}\) - in the value commitment 15. This ensures (1) that the input and output notes are of the same + in the value commitment 16. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetBase}^{\mathsf{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 16 for Custom Assets, as we need to enforce that the +

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 17 for Custom Assets, as we need to enforce that the \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) of the output note of that split Action is the output of a valid \(\mathsf{ZSAValueBase^{Orchard}}\) @@ -119,23 +119,42 @@

    • \(\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P*}\) - is the unique element of the Pallas group 11 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 5. The byte representation of the Asset Base is defined as + is the unique element of the Pallas group 12 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 5. The byte representation of the Asset Base is defined as \(\mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})\) .
    -

    In this case, the instance of the note commitment scheme, +

    Specifically, we define the note commitment scheme \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}}\) - , will differ from - \(\mathsf{NoteCommit^{Orchard}_{rcm}}\) - in that for Custom Assets, the Asset Base will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment 14 allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 13. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    -
    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output}\)
    -

    The nullifier is generated in the same manner as in the Orchard protocol 10.

    -

    The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 7. It consists of

    + as follows:

    +
    \(\mathsf{NoteCommit}^{\mathsf{OrchardZSA}} : \mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor} \times \mathbb{B}^{[l_{\mathbb{P}}]} \times \mathbb{B}^{[l_{\mathbb{P}}]} \times \{0 .. 2^{l_{\mathsf{value}}} - 1\} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{P*} \to \mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Output}\)
    +

    where + \(\mathbb{P}, l_{\mathbb{P}}, q_{\mathbb{P}}\) + are as defined for the Pallas curve 12, and + \(\mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor}, \mathsf{Orchard}.\mathsf{Output}\) + are as defined in the Zcash protocol specification 9. This note commitment scheme is instantiated using the Sinsemilla Commitment 15 as follows:

    +
    \(\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{SinsemillaCommit}_{\mathsf{rcm}}( \texttt{"z.cash:ZSA-NoteCommit"}, +\mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})) &\text{otherwise} +\end{cases} +\end{align}\)
    +

    The nullifier is generated in the same manner as in the Orchard protocol 11.

    +

    The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 7. It consists of

    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)
    +

    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 15 allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 14. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    +
    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output}\)
    +

    Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 15 to perform the value commitment, with fixed base points +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 16 to perform the value commitment, with fixed base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) @@ -153,16 +172,16 @@ respectively,

    \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) - is defined in ZIP 227 5, and

    + is defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) , as in the Orchard protocol.

    We define \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

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

    +

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

    For a total of \(n\) Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key @@ -181,7 +200,7 @@

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 16, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 17, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset Identifiers, as the output note of the split Actions cannot contain any Asset Base, but it must be enforced 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). If not, then the prover could essentially input a multiple (or linear combination) of an existing Asset Base, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -196,7 +215,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 17, except for a few additions that ensure the security of the Asset Identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 18, except for a few additions that ensure the security of the Asset Identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -204,12 +223,12 @@
  • The Asset Base, \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) , for the note is witnessed once, as an auxiliary input.
    • -
  • In the Old note commitment integrity constraint in the Orchard Action statement 17, +
  • In the Old note commitment integrity constraint in the Orchard Action statement 18, \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) .
    • -
  • In the New note commitment integrity constraint in the Orchard Action statement 17, +
  • In the New note commitment integrity constraint in the Orchard Action statement 18, \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) @@ -360,7 +379,7 @@

    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.

    • ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 18, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 19, with the following additions to the Orchard bundle:

    @@ -391,7 +410,7 @@

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

    +

    The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the ZSA protocol upgrade 22.

    Security and Privacy

      @@ -485,10 +504,18 @@
    - +
    + + + +
    9Zcash Protocol Specification, Version 2022.3.8. Section 4.1.8: Commitment
    + + + + @@ -496,7 +523,7 @@
    10 Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard)
    - + @@ -504,7 +531,7 @@
    1011 Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers
    - + @@ -512,7 +539,7 @@
    1112 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta
    - + @@ -520,7 +547,7 @@
    1213 Pallas/Vesta supporting evidence
    - + @@ -528,7 +555,7 @@
    1314 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.1.9: Sinsemilla hash function
    - + @@ -536,7 +563,7 @@
    1415 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments
    - + @@ -544,7 +571,7 @@
    1516 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
    - + @@ -552,7 +579,7 @@
    1617 Zcash Protocol Specification, Version 2022.3.8. Section 4.8.3: Dummy Notes (Orchard)
    - + @@ -560,7 +587,7 @@
    1718 Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard)
    - + @@ -568,7 +595,7 @@
    1819 Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    - + @@ -576,7 +603,7 @@
    1920 User-Defined Assets and Wrapped Assets
    - + @@ -584,7 +611,7 @@
    2021 Comment on Generalized Value Commitments
    - + diff --git a/zip-0226.rst b/zip-0226.rst index 5884e6667..a197492e6 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -96,11 +96,21 @@ where - :math:`\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P*}` is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 [#zip-0227]_. The byte representation of the Asset Base is defined as :math:`\mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})`. -In this case, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, will differ from :math:`\mathsf{NoteCommit^{Orchard}_{rcm}}` in that for Custom Assets, the Asset Base will be added as an input to the commitment computation. As we will see, the nested structure of the Sinsemilla-based commitment [#protocol-concretesinsemillacommit]_ allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. +Specifically, we define the note commitment scheme :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}` as follows: -The commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function [#protocol-concretesinsemillahash]_. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have: +.. math:: \mathsf{NoteCommit}^{\mathsf{OrchardZSA}} : \mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor} \times \mathbb{B}^{[l_{\mathbb{P}}]} \times \mathbb{B}^{[l_{\mathbb{P}}]} \times \{0 .. 2^{l_{\mathsf{value}}} - 1\} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{P*} \to \mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Output} -.. math:: \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output} +where :math:`\mathbb{P}, l_{\mathbb{P}}, q_{\mathbb{P}}` are as defined for the Pallas curve [#protocol-pallasandvesta]_, and :math:`\mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor}, \mathsf{Orchard}.\mathsf{Output}` are as defined in the Zcash protocol specification [#protocol-abstractcommit]_. +This note commitment scheme is instantiated using the Sinsemilla Commitment [#protocol-concretesinsemillacommit]_ as follows: + +.. math:: \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{SinsemillaCommit}_{\mathsf{rcm}}( \texttt{"z.cash:ZSA-NoteCommit"}, + \mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})) &\text{otherwise} + \end{cases} + \end{align} The nullifier is generated in the same manner as in the Orchard protocol [#protocol-commitmentsandnullifiers]_. @@ -109,6 +119,20 @@ It consists of .. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]}) +Rationale for Note Commitment +''''''''''''''''''''''''''''' + +In the ZSA protocol, the instance of the note commitment scheme, :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm}}`, differs from the Orchard note commitment :math:`\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 [#protocol-concretesinsemillacommit]_ allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification. + +The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function [#protocol-concretesinsemillahash]_. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have: + +.. math:: \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output} + + + + Value Commitment ---------------- @@ -308,6 +332,7 @@ References .. [#protocol-notes] `Zcash Protocol Specification, Version 2022.3.8. Section 3.2: Notes `_ .. [#protocol-notept] `Zcash Protocol Specification, Version 2022.3.8. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ .. [#protocol-actions] `Zcash Protocol Specification, Version 2022.3.8. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2022.3.8. Section 4.1.8: Commitment `_ .. [#protocol-binding] `Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard) `_ .. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers `_ .. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta `_ From a0808bed20b96600fe81ee83b8ac59b27d2924c0 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Thu, 16 Feb 2023 20:15:49 +0530 Subject: [PATCH 076/101] editing note commitment text for improved readability and more complete definitions --- zip-0226.html | 98 ++++++++++++++++++++++++++++++++------------------- zip-0226.rst | 14 ++++++-- 2 files changed, 73 insertions(+), 39 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 4b158ec7f..bdd02f56c 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -61,21 +61,21 @@ from each Action Description, computed as \(\mathsf{value^{old}-value^{new}}\) , must be balanced only with respect to the same Asset Identifier. This is specially 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 20 21, we propose to make this happen by changing the value base point, +

    As was initially proposed by Jack Grigg and Daira Hopwood 22 23, 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 \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - an auxiliary input to the proof for each Action statement 18, represented already as a point on the Pallas curve. The circuit then should check that the same + an auxiliary input to the proof for each Action statement 20, represented already as a point on the Pallas curve. The circuit then should check that the same \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - is used in the old note commitment and the new note commitment 15, and as the base point + is used in the old note commitment and the new note commitment 17, and as the base point \(\mathcal{V}^\mathsf{Orchard}\) - in the value commitment 16. This ensures (1) that the input and output notes are of the same + in the value commitment 18. This ensures (1) that the input and output notes are of the same \(\mathsf{AssetBase}^{\mathsf{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 17 for Custom Assets, as we need to enforce that the +

    In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes 19 for Custom Assets, as we need to enforce that the \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) of the output note of that split Action is the output of a valid \(\mathsf{ZSAValueBase^{Orchard}}\) @@ -119,7 +119,7 @@

    • \(\mathsf{AssetBase}^{\mathsf{Orchard}} : \mathbb{P*}\) - is the unique element of the Pallas group 12 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 5. The byte representation of the Asset Base is defined as + is the unique element of the Pallas group 14 that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 5. The byte representation of the Asset Base is defined as \(\mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})\) .
    @@ -129,32 +129,42 @@
    \(\mathsf{NoteCommit}^{\mathsf{OrchardZSA}} : \mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor} \times \mathbb{B}^{[l_{\mathbb{P}}]} \times \mathbb{B}^{[l_{\mathbb{P}}]} \times \{0 .. 2^{l_{\mathsf{value}}} - 1\} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{P*} \to \mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Output}\)

    where \(\mathbb{P}, l_{\mathbb{P}}, q_{\mathbb{P}}\) - are as defined for the Pallas curve 12, and + are as defined for the Pallas curve 14, and \(\mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor}, \mathsf{Orchard}.\mathsf{Output}\) - are as defined in the Zcash protocol specification 9. This note commitment scheme is instantiated using the Sinsemilla Commitment 15 as follows:

    + are as defined in the Zcash protocol specification 9. This note commitment scheme is instantiated using the Sinsemilla Commitment 17 as follows:

    \(\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{SinsemillaCommit}_{\mathsf{rcm}}( \texttt{"z.cash:ZSA-NoteCommit"}, -\mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})) &\text{otherwise} +\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}\)
    -

    The nullifier is generated in the same manner as in the Orchard protocol 11.

    -

    The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 7. It consists of

    +

    where (note that + \(\mathsf{repr}_{\mathbb{P}}\) + is as defined for the Pallas curve 14, + \(l^{\mathsf{Orchard}}_{\mathsf{base}}\) + is as defined in §5.3 13, and + \(\mathsf{I2LEBSP}\) + is as defined in §5.1 12 of the Zcash protocol specification):

    +
    \(\begin{align} +\mathsf{cm}_{\mathsf{ZSA}} &:= \mathsf{SinsemillaCommit}_{\mathsf{rcm}}( \texttt{"z.cash:ZSA-NoteCommit"}, \\ +&\mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})) +\end{align}\)
    +

    The nullifier is generated in the same manner as in the Orchard protocol 11.

    +

    The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext 7. It consists of

    \((\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[l_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{l_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})\)

    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 15 allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    -

    The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 14. 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 17 allows us to add the Asset Base as a final recursive step, and hence keep a single instance of the Sinsemilla hash function in the circuit for the note commitment verification.

    +

    The note commitment output is still indistinguishable from the original Orchard ZEC note commitments, by definition of the Sinsemilla hash function 16. ZSA note commitments will therefore be added to the same Orchard Note Commitment Tree. In essence, we have:

    \(\mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, \mathsf{AssetBase}^{\mathsf{Orchard}})} \in \mathsf{NoteCommit^{Orchard}.Output}\)

    Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 16 to perform the value commitment, with fixed base points +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 18 to perform the value commitment, with fixed base points \(\mathcal{V}^{\mathsf{Orchard}}\) and \(\mathcal{R}^{\mathsf{Orchard}}\) @@ -172,16 +182,16 @@ respectively,

    \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) - is defined in ZIP 227 5, and

    + is defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) , as in the Orchard protocol.

    We define \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

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

    +

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

    For a total of \(n\) Actions in a transfer, the prover MUST still sign the SIGHASH of the transaction using the binding signature key @@ -200,7 +210,7 @@

    Split Notes

    -

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 17, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    +

    One of the key functionalities in a UTXO-based protocol is the fact that input notes are usually 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. This requires a 1-to-many (Orchard) transaction. However, because each Action represents an input and an output, the resulting transaction must have multiple inputs. In order to cope with this today, the Actions that have not been assigned input notes are instead given dummy spend notes 19, which we call split Actions and split notes respectively. Basically, the input note is “faked” inside of the proof in order to hide which Action contains the real spend note.

    This, however, brings some issues when it comes to adding multiple Asset Identifiers, as the output note of the split Actions cannot contain any Asset Base, but it must be enforced 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). If not, then the prover could essentially input a multiple (or linear combination) of an existing Asset Base, with the goal to attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

    In order to prevent this, we make some modifications to the circuit. Specifically we remove the dummy note functionality for Custom Assets and 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.

    This creates a chain of induction that 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. If this were not done then it would be possible to violate balance, for example by using a value base point derived from those of other Assets.

    @@ -215,7 +225,7 @@

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 18, except for a few additions that ensure the security of the Asset Identifier system.

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 20, except for a few additions that ensure the security of the Asset Identifier system.

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same \(\mathsf{AssetId}\) :

    @@ -223,12 +233,12 @@
  • The Asset Base, \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) , for the note is witnessed once, as an auxiliary input.
    • -
  • In the Old note commitment integrity constraint in the Orchard Action statement 18, +
  • In the Old note commitment integrity constraint in the Orchard Action statement 20, \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) .
    • -
  • In the New note commitment integrity constraint in the Orchard Action statement 18, +
  • In the New note commitment integrity constraint in the Orchard Action statement 20, \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) is replaced with \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) @@ -379,7 +389,7 @@

    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.

    • ZSA Transaction Structure

    -

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 19, with the following additions to the Orchard bundle:

    +

    The transaction format is similar to the version 5 transaction format described in the Zcash specification 21, with the following additions to the Orchard bundle:

    2122 ZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs
    @@ -410,7 +420,7 @@

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

    +

    The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the ZSA protocol upgrade 24.

    Security and Privacy

      @@ -528,10 +538,26 @@
    - +
    + + + +
    12Zcash Protocol Specification, Version 2022.3.8. Section 5.1: Integers, Bit Sequences, and Endianness
    + + + + + + + +
    13Zcash Protocol Specification, Version 2022.3.8. Section 5.3: Constants
    + + + + @@ -539,7 +565,7 @@
    14 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta
    - + @@ -547,7 +573,7 @@
    1315 Pallas/Vesta supporting evidence
    - + @@ -555,7 +581,7 @@
    1416 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.1.9: Sinsemilla hash function
    - + @@ -563,7 +589,7 @@
    1517 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.4: Sinsemilla commitments
    - + @@ -571,7 +597,7 @@
    1618 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard)
    - + @@ -579,7 +605,7 @@
    1719 Zcash Protocol Specification, Version 2022.3.8. Section 4.8.3: Dummy Notes (Orchard)
    - + @@ -587,7 +613,7 @@
    1820 Zcash Protocol Specification, Version 2022.3.8. Section 4.17.4: Action Statement (Orchard)
    - + @@ -595,7 +621,7 @@
    1921 Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    - + @@ -603,7 +629,7 @@
    2022 User-Defined Assets and Wrapped Assets
    - + @@ -611,7 +637,7 @@
    2123 Comment on Generalized Value Commitments
    - + diff --git a/zip-0226.rst b/zip-0226.rst index a197492e6..942918377 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -106,12 +106,18 @@ This note commitment scheme is instantiated using the Sinsemilla Commitment [#pr .. math:: \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{SinsemillaCommit}_{\mathsf{rcm}}( \texttt{"z.cash:ZSA-NoteCommit"}, - \mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})) &\text{otherwise} + \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} +where (note that :math:`\mathsf{repr}_{\mathbb{P}}` is as defined for the Pallas curve [#protocol-pallasandvesta]_, :math:`l^{\mathsf{Orchard}}_{\mathsf{base}}` is as defined in §5.3 [#protocol-constants]_, and :math:`\mathsf{I2LEBSP}` is as defined in §5.1 [#protocol-endian]_ of the Zcash protocol specification): + +.. math:: \begin{align} + \mathsf{cm}_{\mathsf{ZSA}} &:= \mathsf{SinsemillaCommit}_{\mathsf{rcm}}( \texttt{"z.cash:ZSA-NoteCommit"}, \\ + &\mathsf{g_{d}*}\; \| \; \mathsf{pk_{d}*}\; \| \; \mathsf{I2LEBSP_{64}(v)}\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho)\; \| \; \mathsf{I2LEBSP}_{l^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi)\; \| \; \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}^{\mathsf{Orchard}})) + \end{align} + The nullifier is generated in the same manner as in the Orchard protocol [#protocol-commitmentsandnullifiers]_. The ZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext [#protocol-notept]_. @@ -335,6 +341,8 @@ References .. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2022.3.8. Section 4.1.8: Commitment `_ .. [#protocol-binding] `Zcash Protocol Specification, Version 2022.3.8. Section 4.14: Balance and Binding Signature (Orchard) `_ .. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2022.3.8. Section 4.16: Note Commitments and Nullifiers `_ +.. [#protocol-endian] `Zcash Protocol Specification, Version 2022.3.8. Section 5.1: Integers, Bit Sequences, and Endianness `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2022.3.8. Section 5.3: Constants `_ .. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.6: Pallas and Vesta `_ .. [#pasta-evidence] `Pallas/Vesta supporting evidence `_ .. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.1.9: Sinsemilla hash function `_ From 94c407df5ec5c72b232ab38c19c58004e2c95223 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Thu, 16 Feb 2023 22:35:07 +0530 Subject: [PATCH 077/101] incorporating comment from PR#628 --- zip-0226.html | 2 +- zip-0226.rst | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/zip-0226.html b/zip-0226.html index bdd02f56c..898b9fcdc 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -324,7 +324,7 @@

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.

    -

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.

    +

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. However, new notes will always be ZSA notes with an Asset Base.

    The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases:

    • diff --git a/zip-0226.rst b/zip-0226.rst index 942918377..b8d192b8c 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -234,6 +234,7 @@ the input and output note are of the same :math:`\mathsf{AssetId}`: **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with Orchard ZEC notes. The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. +However, new notes will always be ZSA notes with an Asset Base. The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases: From 4f391ea008111e6f9f11ccbfa05052f9e653424b Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 21 Feb 2023 13:24:01 +0530 Subject: [PATCH 078/101] updating issuance authorizing key derivation --- zip-0227.html | 6 ++++-- zip-0227.rst | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 976cf9d31..778e4d0a7 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -115,7 +115,7 @@ \(\mathsf{sk}_{\mathsf{iss}}\) , as a private signature key:
    -
    \(\mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{PRF}^{\mathsf{expand}}_{\mathsf{sk}_{\mathsf{iss}}} ([\mathsf{0x0a}]))\)
    +
    \(\mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{sk}_{\mathsf{iss}} )\)
    • The issuance validating key is derived from the issuance authorizing key, \(\mathsf{isk}\) @@ -321,7 +321,9 @@ as 32 byte-string
    • sign the SIGHASH of the transaction with the issuance authorizing key, \(\mathsf{isk}\) - , using the RedPallas signature scheme. The signature is then added to the issuance bundle.
      • + , using the + \(\mathsf{IssueAuthSig}\) + signature scheme. The signature is then added to the issuance bundle.

    NOTE that the commitment is not included in the IssuanceAction itself. As explained below, it is later computed by the validators and added to the NoteCommitmentTree.

    diff --git a/zip-0227.rst b/zip-0227.rst index b9cc251b4..31928bd0c 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -109,7 +109,7 @@ The issuance authorizing key and issuance validating key are derived from the is - The issuance authorizing key is derived from the issuance master key, :math:`\mathsf{sk}_{\mathsf{iss}}`, as a private signature key: -.. math:: \mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{PRF}^{\mathsf{expand}}_{\mathsf{sk}_{\mathsf{iss}}} ([\mathsf{0x0a}])) +.. math:: \mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{sk}_{\mathsf{iss}} ) - The issuance validating key is derived from the issuance authorizing key, :math:`\mathsf{isk}`, as a public verification key: @@ -230,7 +230,7 @@ For the `IssueBundle`: - encode the `vIssueActions` vector - encode the :math:`\mathsf{ik}` as 32 byte-string -- sign the `SIGHASH` of the transaction with the issuance authorizing key, :math:`\mathsf{isk}`, using the RedPallas signature scheme. The signature is then added to the issuance bundle. +- sign the `SIGHASH` of the transaction with the issuance authorizing key, :math:`\mathsf{isk}`, using the :math:`\mathsf{IssueAuthSig}` signature scheme. The signature is then added to the issuance bundle. NOTE that the commitment is not included in the `IssuanceAction` itself. As explained below, it is later computed by the validators and added to the `NoteCommitmentTree`. From c4d78d525f1f0075589cf15e0feeff4d0be760b6 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 21 Feb 2023 13:40:13 +0530 Subject: [PATCH 079/101] reverting back to BLAKE2b-512 for AssetDigest, fixed some typos --- zip-0226.html | 4 ++-- zip-0226.rst | 4 ++-- zip-0227.html | 24 +++++++++++++++--------- zip-0227.rst | 14 +++++++------- 4 files changed, 26 insertions(+), 20 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 898b9fcdc..bb37cefe9 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -357,7 +357,7 @@

    Backward Compatibility

    -

    In order to have a "clean" backwards 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: - The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree - 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.

    +

    In order to have a "clean" backwards 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: - The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset Identifier; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree - 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.

    Burn Mechanism

    @@ -426,7 +426,7 @@
    • Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure.
    • When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design.
      • -
    • We prevent the "roadblock" attack on the Asset Identifer by ensuring the output notes receive an Asset Base that exists on the global state.
      • +
    • We prevent the "roadblock" attack on the Asset Identifier by ensuring the output notes receive an Asset Base that exists on the global state.
    • Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets.
      • One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
        • diff --git a/zip-0226.rst b/zip-0226.rst index b8d192b8c..3002b231b 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -250,7 +250,7 @@ Backward Compatibility ---------------------- In order to have a "clean" backwards 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: -- The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset identifer; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree +- The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset Identifier; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree - 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. @@ -308,7 +308,7 @@ Security and Privacy - Even if the Orchard protocol and ZSA protocol do not share the same anonymity pool (nodes can keep track of the notes that where published with different transaction structures), the migration from one to the other is done automatically and seamlessly. The Orchard bundle will be replaced by the ZSA bundle and all ZEC notes will be fully spendable with the new transaction structure. - When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design. -- We prevent the "roadblock" attack on the Asset Identifer by ensuring the output notes receive an Asset Base that exists on the global state. +- We prevent the "roadblock" attack on the Asset Identifier by ensuring the output notes receive an Asset Base that exists on the global state. - Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are the use of a petname system or a list of well-known Assets. - One proposal for a petname system for the zcashd wallet is the use of an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients. diff --git a/zip-0227.html b/zip-0227.html index 778e4d0a7..af6100915 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -59,7 +59,7 @@

        Specification

        As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

        Overview

        -

        This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifer, as the Asset Identifiers are tied to the issuer keys.

        +

        This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifier, as the Asset Identifiers are tied to the issuer keys.

        The protocol was designed with three main properties in mind:

        • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
          • @@ -140,7 +140,7 @@

          A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, \(\mathsf{AssetDigest}\) , which is simply is a - \(\mathsf{BLAKE2b-256}\) + \(\textsf{BLAKE2b-512}\) hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.

          @@ -154,7 +154,7 @@ be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

        Define - \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))\) + \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\mathtt{''ZZSA-AssetDigest''},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))\) , where

        • @@ -172,7 +172,7 @@

          The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

          -
          Diagram relating the Asset Identifer, Asset Digest, and Asset Base in the ZSA Protocol
          +
          Diagram relating the Asset Identifier, Asset Digest, and Asset Base in the ZSA Protocol

        Global Issuance State

        @@ -294,13 +294,19 @@
        • encode \(\mathsf{asset\_desc}\) - as 512 byte-string.
          • + as a UTF-8 byte string of size up to 512.
        • compute - \(\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))\) -
          • + \(\mathsf{AssetDigest}\) + from the issuance validating key + \(\mathsf{ik}\) + and + \(\mathsf{asset\_desc}\) + as decribed in the Asset Identifier section.
        • compute - \(\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})\) -
          • + \(\mathsf{AssetBase^{Protocol}}\) + from + \(\mathsf{AssetDigest}\) + as decribed in the Asset Identifier section.
        • set the finalize boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set finalize = 0, otherwise set finalize = 1)
        • For each recipient \(i\) diff --git a/zip-0227.rst b/zip-0227.rst index 31928bd0c..0d3a333cf 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -70,7 +70,7 @@ As explained, the issuance protocol allows for a single issuance action to be se Overview -------- -This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifer, as the Asset Identifiers are tied to the issuer keys. +This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifier, as the Asset Identifiers are tied to the issuer keys. The protocol was designed with three main properties in mind: @@ -132,7 +132,7 @@ Asset Identifier For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair :math:`(\mathsf{ik}, \mathsf{asset\_desc})`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string. -A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is simply is a :math:`\mathsf{BLAKE2b-256}` hash of the Asset Identifier. +A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is simply is a :math:`\textsf{BLAKE2b-512}` hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes. Let @@ -140,7 +140,7 @@ Let - :math:`\mathsf{asset\_desc}` be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. - :math:`\mathsf{ik}` be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH. -Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`, +Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\mathtt{''ZZSA-AssetDigest''},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))`, where - :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!`. @@ -158,7 +158,7 @@ The relations between the Asset Identifier, Asset Digest, and Asset Base are sho :align: center :figclass: align-center - Diagram relating the Asset Identifer, Asset Digest, and Asset Base in the ZSA Protocol + Diagram relating the Asset Identifier, Asset Digest, and Asset Base in the ZSA Protocol Global Issuance State @@ -216,9 +216,9 @@ The issuer program performs the following operations For all actions `IssueAction`: -- encode :math:`\mathsf{asset\_desc}` as 512 byte-string. -- compute :math:`\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))` -- compute :math:`\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})` +- encode :math:`\mathsf{asset\_desc}` as a UTF-8 byte string of size up to 512. +- compute :math:`\mathsf{AssetDigest}` from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as decribed in the `Asset Identifier`_ section. +- compute :math:`\mathsf{AssetBase^{Protocol}}` from :math:`\mathsf{AssetDigest}` as decribed in the `Asset Identifier`_ section. - set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set ``finalize = 0``, otherwise set ``finalize = 1``) - For each recipient :math:`i`: From 2c519ffcd772bb481c41f8608b386b97304e183e Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 21 Feb 2023 14:03:16 +0530 Subject: [PATCH 080/101] adding cross reference for note commitment function definition --- zip-0227.html | 74 +++++++++++++++++++++++++++++++-------------------- zip-0227.rst | 7 ++--- 2 files changed, 49 insertions(+), 32 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index af6100915..c554798a8 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -32,7 +32,7 @@

        Abstract

        -

        ZIP 226 4 and ZIP 227 5 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 5. The transfer and burn of such Assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

        +

        ZIP 226 4 and ZIP 227 6 propose in conjunction the Zcash Shielded Assets (ZSA) protocol, which is an extension of the Orchard protocol that enables the creation, transfer and burn of custom Assets on the Zcash chain. The creation of such Assets is defined in ZIP 227 6. The transfer and burn of such Assets is defined in ZIP 226 4. This ZIP must only be implemented in conjuction with ZIP 226 4, as the issuance mechanism is only valid for the ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

        Motivation

        This ZIP is a supporting ZIP for ZIP 226 4, which lays out its motivations, but requires an issuance mechanism to be defined (which is substantial enough to stand on its own) in order to function.

        @@ -69,12 +69,12 @@

        The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

        Issuance Authorization Signature Scheme

        -

        The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature 12.

        +

        The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature 13.

        We define the issuance authorization signature scheme \(\mathsf{IssueAuthSig}\) similar to the Orchard spend authorization signature scheme, \(\mathsf{SpendAuthSig}^{\mathsf{Orchard}}\) - 13. Specifically, we instantiate + 14. Specifically, we instantiate \(\mathsf{IssueAuthSig}\) as \(\mathsf{RedPallas}\) @@ -82,10 +82,10 @@ \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 10.

        + is defined as in 11.

        Issuance Keys

        -

        The ZSA Protocol adds the following three keys to the key components 9:

        +

        The ZSA Protocol adds the following three keys to the key components 10:

        1. The issuance master key, denoted as \(\mathsf{sk}_{\mathsf{iss}}\) @@ -99,9 +99,9 @@

        The issuance master key is generated by choosing a bit sequence uniformly at random from \(\mathbb{B}^{\mathbb{Y}[32]}\) - , like the Orchard spending key 11. In + , like the Orchard spending key 12. In \(\mathsf{zcashd}\) - , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 7, as detailed below:

        + , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 8, as detailed below:

        • Let \(S\) @@ -109,7 +109,7 @@ \(\mathsf{sk}_{\mathsf{iss}} := \mathsf{BLAKE2b\text{-}256}(\mathtt{''ZcashIP32Issuance''}, S)\) .
        -

        The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 11, as described below.

        +

        The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 12, as described below.

        • The issuance authorizing key is derived from the issuance master key, \(\mathsf{sk}_{\mathsf{iss}}\) @@ -122,7 +122,7 @@ , as a public verification key:
        \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)
        -

        This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 7. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

        +

        This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 8. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

        The derivation of these keys are shown in the following diagram:

        @@ -168,7 +168,7 @@ \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 10.

        + is defined as in 11.

        The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

        @@ -248,7 +248,7 @@ \(\mathsf{isk}\) , that validates the issuance .
      -

      The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 14.

      +

      The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 15.

    2224 ZIP 317: Proportional Transfer Fee Mechanism - Pull Request #667 for ZSA Protocol ZIPs
    @@ -387,9 +387,11 @@

    If all of the above checks pass, do the following:

    • For each note, compute the note commitment as - \(cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) - and
      • -
    • add cm to the Merkle tree of note commitments, NoteCommitmentTree.
      • + \(\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) + as defined in the Note Structure and Commitment section of ZIP 226 5 and +
    • add + \(\mathsf{cm}\) + to the Merkle tree of note commitments, NoteCommitmentTree.
    • If finalize = 1, add \(\mathsf{AssetId}\) to the previously_finalized set in the global state.
      • @@ -414,9 +416,9 @@

      TxId Digest

      A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

      -
      -

      issuance_txid_digest ├── issueActions └── issuerVerificationKey

      -
      + 
      issuance_txid_digest
+├── issueActions
+└── issuerVerificationKey

      In the specification below, nodes of the tree are presented in depth-first order.

      issuance_txid_digest

      A BLAKE2b-256 hash of the following values

      @@ -472,7 +474,7 @@ \(\mathsf{AssetId}\) .
    -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -483,7 +485,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 6.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 7.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -538,10 +540,24 @@

    - +
    + + + +
    5 +
    +

    System Message: WARNING/2 (zip-0227.rst line 414) zip-226-transfer-and-burn-of-zcash-shielded-assets-1

    +

    Duplicate explicit target name: "zip 226: transfer and burn of zcash shielded assets".

    +
    +

    ZIP 226: Transfer and Burn of Zcash Shielded Assets

    +
    + + + + @@ -549,7 +565,7 @@
    6 ZIP 227: Issuance of Zcash Shielded Assets
    - + @@ -557,7 +573,7 @@
    67 ZIP 317b: ZSA Extension Proportional Fee Mechanism
    - + @@ -565,7 +581,7 @@
    78 ZIP 32: Shielded Hierarchical Deterministic Wallets
    - + @@ -573,7 +589,7 @@
    89 ZIP 316: Unified Addresses and Unified Viewing Keys
    - + @@ -581,7 +597,7 @@
    910 Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys
    - + @@ -589,7 +605,7 @@
    1011 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta
    - + @@ -597,7 +613,7 @@
    1112 Zcash Protocol Specification, Version 2022.3.8. Section 4.2.3: Orchard Key Components
    - + @@ -605,7 +621,7 @@
    1213 Zcash Protocol Specification, Version 2022.3.8. Section 4.15: Spend Authorization Signature (Sapling and Orchard)
    - + @@ -613,7 +629,7 @@
    1314 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)
    - + diff --git a/zip-0227.rst b/zip-0227.rst index 0d3a333cf..36033036f 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -272,8 +272,8 @@ For each `IssueAction` in `IssueBundle`: If all of the above checks pass, do the following: -- For each note, compute the note commitment as :math:`cm = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` and -- add `cm` to the Merkle tree of note commitments, `NoteCommitmentTree`. +- For each note, compute the note commitment as :math:`\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` as defined in the Note Structure and Commitment section of ZIP 226 [#zip-0226-notestructure]_ and +- add :math:`\mathsf{cm}` to the Merkle tree of note commitments, `NoteCommitmentTree`. - If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set in the global state. @@ -291,7 +291,7 @@ The following is a list of rationale for different decisions made in the proposa TxId Digest =========== -A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below: +A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:: issuance_txid_digest ├── issueActions @@ -417,6 +417,7 @@ References .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0224] `ZIP 224: Orchard `_ .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0226-notestructure] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ From 672e7f4661fd0c9afed1c265945ccdeadc94b87f Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Thu, 23 Feb 2023 08:18:19 +0530 Subject: [PATCH 081/101] IssueAuthSig fix to remove key rerendomization --- zip-0227.html | 2 +- zip-0227.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index c554798a8..a3a8a34ba 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -78,7 +78,7 @@ \(\mathsf{IssueAuthSig}\) as \(\mathsf{RedPallas}\) - with key re-randomization and with generator + without key re-randomization using generator \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})\) where \(\mathsf{GroupHash}^\mathbb{P}\) diff --git a/zip-0227.rst b/zip-0227.rst index 36033036f..ccf9328ac 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -86,7 +86,7 @@ Issuance Authorization Signature Scheme The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature [#protocol-spendauthsig]_. We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` similar to the Orchard spend authorization signature scheme, :math:`\mathsf{SpendAuthSig}^{\mathsf{Orchard}}` [#protocol-concretespendauthsig]_. -Specifically, we instantiate :math:`\mathsf{IssueAuthSig}` as :math:`\mathsf{RedPallas}` with key re-randomization and with generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. +Specifically, we instantiate :math:`\mathsf{IssueAuthSig}` as :math:`\mathsf{RedPallas}` without key re-randomization using generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. Issuance Keys From d0a75f11d25b1df0a2837c6d03ee75f9943450d1 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Thu, 23 Feb 2023 10:25:40 +0530 Subject: [PATCH 082/101] adding back the leading 0x00 for EncodeAssetId --- zip-0227.html | 2 +- zip-0227.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index a3a8a34ba..66262f961 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -158,7 +158,7 @@ , where

    • - \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!\) + \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{0x00} || \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!\) .

    Define diff --git a/zip-0227.rst b/zip-0227.rst index ccf9328ac..b3c975c2f 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -143,7 +143,7 @@ Let Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\mathtt{''ZZSA-AssetDigest''},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))`, where -- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!`. +- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{0x00} || \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!`. Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})`, where From 661565deaef66f93207405887077881b95c00775 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 26 Feb 2023 10:41:19 +0530 Subject: [PATCH 083/101] minor edits, rearranging for value commitment rationale --- zip-0226.html | 287 +++++++++++++++++++++++++------------------------- zip-0226.rst | 16 ++- 2 files changed, 156 insertions(+), 147 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index bb37cefe9..62efe699f 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -56,7 +56,7 @@ . This Asset Identifier maps to an Asset Base \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) that is stored in Orchard-based ZSA notes. These terms are formally defined in ZIP 227 5.

    -

    The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 10), and by extension the balance of an Orchard transaction. That is, the sum of all the +

    The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description 8 is preserved across Assets (see the Orchard Binding Signature 10), 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}-value^{new}}\) @@ -164,12 +164,7 @@

    Value Commitment

    -

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 18 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.

    -

    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. This enables the final balance of the transaction to be securely computed, such that each Asset Identifier is balanced independently, as different Assets are not meant to be mutually fungible. The value commitment then becomes

    +

    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:

    \(\mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}} + [\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}}\)

    where \(\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{AssetId}}\) @@ -182,13 +177,21 @@ respectively,

    \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) - is defined in ZIP 227 5, and

    + is defined in ZIP 227 5, and

    \(\mathcal{R}^{\mathsf{Orchard}}:=\mathsf{GroupHash^{\mathbb{P}}}\texttt{("z.cash:Orchard-cv", "r")}\) , as in the Orchard protocol.

    We define \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}\) - so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    + so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 3.

    +

    Rationale for Value Commitment

    +

    The Orchard Protocol uses a Homomorphic Pedersen Commitment 18 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.

    +

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

    @@ -223,139 +226,139 @@

    The specific circuit changes are presented below.

    - -

    Circuit Statement

    -

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 20, except for a few additions that ensure the security of the Asset Identifier system.

    -

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same - \(\mathsf{AssetId}\) - :

    -
      -
    • The Asset Base, - \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) - , for the note is witnessed once, as an auxiliary input.
      • -
    • In the Old note commitment integrity constraint in the Orchard Action statement 20, - \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) - is replaced with - \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) - .
      • -
    • In the New note commitment integrity constraint in the Orchard Action statement 20, - \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) - is replaced with - \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) - .
      • -
    -

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base, as represented in the notes:

    -
      -
    • The fixed-base multiplication constraints 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 value base equation is the auxiliary input - \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) - .
      • -
    -

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the Asset Base for the output note in a Split Action:

    -
      -
    • -
      -
      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}(v’ - v^new, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) -
        • -
      -
      -
      -
      • -
    • -
      -
      Add a boolean split variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
      -
      -
        -
      • If split = 1 then set - \(\mathsf{v}' = 0\) - otherwise - \(\mathsf{v}'=\mathsf{v^{old}}\) - from the auxiliary input.
        • -
      -
      -
      -
      • -
    • -
      -
      The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes):
      -
      -
        -
      • Check that (path, pos) is a valid Merkle path of depth - \(\mathsf{MerkleDepth^Orchard}\) - , from - \(\mathsf{cm^old}\) - to the anchor - \(\mathsf{rt^Orchard}\) - .
        • -
      -
      -
      -
      • -
    • -
      -
      The Nullifier Integrity will be changed to prevent the identification of notes
      -
      -
        -
      • Replace the - \(\psi_{old}\) - value with a generic - \(\psi'\) - as - \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\) -
        • -
      • if - \(\mathtt{split} = 0\) - then constrain - \(\psi' = \psi^{old}\) - . (Otherwise - \(\psi'\) - should be sampled randomly.)
        • -
      -
      -
      -
      • -
    -

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.

    -

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. However, new notes will always be ZSA notes with an Asset Base.

    -

    The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases:

    -
      -
    • -
      -
      If the Asset Base auxiliary input present but set to - \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) - = - \(\mathcal{V}^\mathsf{Orchard}\) -
      -
      -
        -
      • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the Asset Base)
        • -
      • This path also uses the original domain separator for ZEC note commitment
        • -
      -
      -
      -
      • -
    • -
      -
      Else,
      -
      -
        -
      • The note commitment adds the identfier, - \(\mathsf{AssetId}\) - , as a final “chunk” of the Sinsemilla commitment
        • -
      • The note commitment uses a different domain separator for ZSA note commitment
        • -
      -
      -
      -
      • -
    +

    Circuit Statement

    +

    The advantage of the design described above, with respect to the circuit statement, is that every ZSA Action statement is kept closely similar to the Orchard Action statement 20, except for a few additions that ensure the security of the Asset Identifier system.

    +

    Asset Identifier Equality: the following constraints must be added to ensure that the input and output note are of the same + \(\mathsf{AssetId}\) + :

    +
      +
    • The Asset Base, + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) + , for the note is witnessed once, as an auxiliary input.
      • +
    • In the Old note commitment integrity constraint in the Orchard Action statement 20, + \(\mathsf{NoteCommit^{Orchard}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old})}\) + is replaced with + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}(repr_{\mathbb{P}}(g_d^{old}), repr_{\mathbb{P}}(pk_d^{old}), v^{old}, \rho^{old}, \psi^{old}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) + .
      • +
    • In the New note commitment integrity constraint in the Orchard Action statement 20, + \(\mathsf{NoteCommit^{Orchard}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new})}\) + is replaced with + \(\mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}(repr_{\mathbb{P}}(g_d^{new}), repr_{\mathbb{P}}(pk_d^{new}), v^{new}, \rho^{new}, \psi^{new}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) + .
      • +
    +

    Correct Value Commitment: the following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base, as represented in the notes:

    +
      +
    • The fixed-base multiplication constraints 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 value base equation is the auxiliary input + \(\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}\) + .
      • +
    +

    Enforce Secure Identifier for Split Actions: the following constraints must be added to prevent senders from changing the Asset Base for the output note in a Split Action:

    +
      +
    • +
      +
      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}(v’ - v^new, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}\) +
        • +
      +
      +
      +
      • +
    • +
      +
      Add a boolean split variable as an auxiliary witness. This variable is to be activated split = 1 if the Action in question is a split and split = 0 if the Action is actually spending an input note:
      +
      +
        +
      • If split = 1 then set + \(\mathsf{v}' = 0\) + otherwise + \(\mathsf{v}'=\mathsf{v^{old}}\) + from the auxiliary input.
        • +
      +
      +
      +
      • +
    • +
      +
      The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes):
      +
      +
        +
      • Check that (path, pos) is a valid Merkle path of depth + \(\mathsf{MerkleDepth^Orchard}\) + , from + \(\mathsf{cm^old}\) + to the anchor + \(\mathsf{rt^Orchard}\) + .
        • +
      +
      +
      +
      • +
    • +
      +
      The Nullifier Integrity will be changed to prevent the identification of notes
      +
      +
        +
      • Replace the + \(\psi_{old}\) + value with a generic + \(\psi'\) + as + \(\mathsf{nf_old = DeriveNullifier_nk}(\rho^\mathsf{old}, \psi', \mathsf{cm^old})\) +
        • +
      • if + \(\mathtt{split} = 0\) + then constrain + \(\psi' = \psi^{old}\) + . (Otherwise + \(\psi'\) + should be sampled randomly.)
        • +
      +
      +
      +
      • +
    +

    Enabling Backwards Compatibility with ZEC Notes: the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.

    +

    The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. However, new notes will always be ZSA notes with an Asset Base.

    +

    The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases:

    +
      +
    • +
      +
      If the Asset Base auxiliary input present but set to + \(\mathsf{AssetBase}^{\mathsf{Orchard}}\) + = + \(\mathcal{V}^\mathsf{Orchard}\) +
      +
      +
        +
      • NoteCommitment has a “compatibility” path that computes the note commitment as in plain Orchard (i.e.: without including the Asset Base)
        • +
      • This path also uses the original domain separator for ZEC note commitment
        • +
      +
      +
      +
      • +
    • +
      +
      Else,
      +
      +
        +
      • The note commitment adds the identfier, + \(\mathsf{AssetId}\) + , as a final “chunk” of the Sinsemilla commitment
        • +
      • The note commitment uses a different domain separator for ZSA note commitment
        • +
      +
      +
      +
      • +
    +

    Backward Compatibility

    In order to have a "clean" backwards 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: - The input notes with an Asset Base denote the Custom Assets, generating a note commitment that includes the Asset Identifier; whereas the notes without an Asset Base denote the ZEC notes from before the protocol upgrade, and generate a note commitment that does not include the Asset Base, in order to maintain the referencability to the Merkle tree - 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.

    diff --git a/zip-0226.rst b/zip-0226.rst index 3002b231b..e9b36beeb 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -61,7 +61,7 @@ In order to be able to represent different Assets, we need to define a data fiel This Asset Identifier maps to an Asset Base :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}` that is stored in Orchard-based ZSA notes. These terms are formally defined in ZIP 227 [#zip-0227]_. -The Asset Identifier (via means of theAsset Digest and Asset Base) will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset Identifier**. This is specially 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. +The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description [#protocol-actions]_ is preserved across Assets (see the Orchard Binding Signature [#protocol-binding]_), and by extension the balance of an Orchard transaction. That is, the sum of all the :math:`\mathsf{value^{net}}` from each Action Description, computed as :math:`\mathsf{value^{old}-value^{new}}`, must be balanced **only with respect to the same Asset Identifier**. This is specially 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 [#initial-zsa-issue]_ [#generalized-value-commitments]_, we propose to make this happen by changing the value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}`, in the Homomorphic Pedersen Commitment that derives the value commitment, :math:`\mathsf{cv^{net}}`, of the *net value* in an Orchard Action. @@ -142,9 +142,7 @@ The note commitment output is still indistinguishable from the original Orchard Value Commitment ---------------- -The Orchard Protocol uses a Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, with fixed base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and :math:`\mathcal{R}^{\mathsf{Orchard}}` as the values represent the amount of ZEC being transferred. - -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**. This enables the final balance of the transaction to be securely computed, such that each Asset Identifier is balanced independently, as different Assets are not meant to be mutually fungible. The value commitment then becomes +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: .. math:: \mathsf{cv^{net}:=ValueCommit^{OrchardZSA}_{rcv}(v^{net}_{AssetId}, \mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}})}:= \mathsf{[v^{net}_{AssetId}]}\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}} + [\mathsf{rcv}]\mathcal{R}^{\mathsf{Orchard}} @@ -158,6 +156,14 @@ where :math:`\mathsf{v^{net}_{AssetId}} = \mathsf{v^{old}_{AssetId} - v^{new}_{A We define :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{ZEC}} :=\mathcal{V}^{\mathsf{Orchard}}` so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 [#zip-0224]_. +Rationale for Value Commitment +'''''''''''''''''''''''''''''' + +The Orchard Protocol uses a Homomorphic Pedersen Commitment [#protocol-concretevaluecommit]_ to perform the value commitment, with fixed base points :math:`\mathcal{V}^{\mathsf{Orchard}}` and :math:`\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. + + Value Balance Verification -------------------------- @@ -203,7 +209,7 @@ Wallets and other clients have a choice to make to ensure the Asset Base is pres The specific circuit changes are presented below. Circuit Statement -================= +----------------- The advantage of the design described above, with respect to the circuit statement, is that every *ZSA Action statement* is kept closely similar to the Orchard Action statement [#protocol-actionstatement]_, except for a few additions that ensure the security of the Asset Identifier system. From ef0f8dff0c2ab222a54eff0a7dd000012124541d Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 28 Feb 2023 10:31:43 +0530 Subject: [PATCH 084/101] updating ZIP owners --- zip-0226.html | 13 +++++++------ zip-0226.rst | 13 +++++++------ zip-0227.html | 21 ++++++++------------- zip-0227.rst | 15 ++++++++------- 4 files changed, 30 insertions(+), 32 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 62efe699f..132425350 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -9,12 +9,13 @@ 
    ZIP: 226
 Title: Transfer and Burn of Zcash Shielded Assets
-Owners: Daniel Benarroch <daniel@qed-it.com>
-        Pablo Kogan <pablo@qed-it.com>
-        Aurelien Nicolas <aurel@qed-it.com>
-Credits: Daira Hopwood
-         Jack Grigg
-         Vivek Arte
+Owners: Pablo Kogan <pablo@qed-it.com>
+        Vivek Arte <vivek@qed-it.com>
+        Daira Hopwood <daira@electriccoin.co>
+        Jack Grigg <str4d@electriccoin.co>
+        Deidre Connolly <deirdre@zfnd.org>
+Credits: Daniel Benarroch
+         Aurelien Nicolas
 Status: Draft
 Category: Consensus
 Created: 2022-05-01
diff --git a/zip-0226.rst b/zip-0226.rst
index e9b36beeb..b74756a43 100644
--- a/zip-0226.rst
+++ b/zip-0226.rst
@@ -2,12 +2,13 @@
 
   ZIP: 226
   Title: Transfer and Burn of Zcash Shielded Assets
-  Owners: Daniel Benarroch 
-          Pablo Kogan 
-          Aurelien Nicolas 
-  Credits: Daira Hopwood
-           Jack Grigg
-           Vivek Arte
+  Owners: Pablo Kogan 
+          Vivek Arte 
+          Daira Hopwood 
+          Jack Grigg 
+          Deidre Connolly 
+  Credits: Daniel Benarroch
+           Aurelien Nicolas
   Status: Draft
   Category: Consensus
   Created: 2022-05-01
diff --git a/zip-0227.html b/zip-0227.html
index 66262f961..f7566f1e4 100644
--- a/zip-0227.html
+++ b/zip-0227.html
@@ -9,12 +9,13 @@
     
    
         
    ZIP: 227
 Title: Issuance of Zcash Shielded Assets
-Owners: Daniel Benarroch <daniel@qed-it.com>
-        Pablo Kogan <pablo@qed-it.com>
-        Aurelien Nicolas <aurel@qed-it.com>
-Credits: Daira Hopwood
-         Jack Grigg
-         Vivek Arte
+Owners: Pablo Kogan <pablo@qed-it.com>
+        Vivek Arte <vivek@qed-it.com>
+        Daira Hopwood <daira@electriccoin.co>
+        Jack Grigg <str4d@electriccoin.co>
+        Deidre Connolly <deirdre@zfnd.org>
+Credits: Daniel Benarroch
+         Aurelien Nicolas
 Status: Draft
 Category: Consensus
 Created: 2022-05-01
@@ -544,13 +545,7 @@
    - +
    1415 Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    5 -
    -

    System Message: WARNING/2 (zip-0227.rst line 414) zip-226-transfer-and-burn-of-zcash-shielded-assets-1

    -

    Duplicate explicit target name: "zip 226: transfer and burn of zcash shielded assets".

    -
    -

    ZIP 226: Transfer and Burn of Zcash Shielded Assets

    -     		ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment
    diff --git a/zip-0227.rst b/zip-0227.rst index b3c975c2f..c17df1f95 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -2,12 +2,13 @@ ZIP: 227 Title: Issuance of Zcash Shielded Assets - Owners: Daniel Benarroch - Pablo Kogan - Aurelien Nicolas - Credits: Daira Hopwood - Jack Grigg - Vivek Arte + Owners: Pablo Kogan + Vivek Arte + Daira Hopwood + Jack Grigg + Deidre Connolly + Credits: Daniel Benarroch + Aurelien Nicolas Status: Draft Category: Consensus Created: 2022-05-01 @@ -417,7 +418,7 @@ References .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0224] `ZIP 224: Orchard `_ .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ -.. [#zip-0226-notestructure] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0226-notestructure] `ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ From 5b9d42457e9313338c8d1fd0f7b9916a37b2aba2 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 28 Feb 2023 11:21:55 +0530 Subject: [PATCH 085/101] editing issuance key section --- zip-0227.html | 129 ++++++++++++++++++++++++++------------------------ zip-0227.rst | 26 +++++----- 2 files changed, 81 insertions(+), 74 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index f7566f1e4..a6bda3cfe 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -69,24 +69,8 @@

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    -

    Issuance Authorization Signature Scheme

    -

    The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature 13.

    -

    We define the issuance authorization signature scheme - \(\mathsf{IssueAuthSig}\) - similar to the Orchard spend authorization signature scheme, - \(\mathsf{SpendAuthSig}^{\mathsf{Orchard}}\) - 14. Specifically, we instantiate - \(\mathsf{IssueAuthSig}\) - as - \(\mathsf{RedPallas}\) - without key re-randomization using generator - \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})\) - where - \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 11.

    -
    -

    Issuance Keys

    -

    The ZSA Protocol adds the following three keys to the key components 10:

    +

    Issuance Keys & Issuance Authorization Signature Scheme

    +

    The ZSA Protocol adds the following three keys to the key components 11:

    1. The issuance master key, denoted as \(\mathsf{sk}_{\mathsf{iss}}\) @@ -98,37 +82,50 @@ \(\mathsf{ik}\) , is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.
    -

    The issuance master key is generated by choosing a bit sequence uniformly at random from - \(\mathbb{B}^{\mathbb{Y}[32]}\) - , like the Orchard spending key 12. In - \(\mathsf{zcashd}\) - , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 8, as detailed below:

    -
      -
    • Let - \(S\) - be a seed byte sequence of a chosen length, which MUST be at least 32 bytes and at most 252 bytes. Compute the issuance master key - \(\mathsf{sk}_{\mathsf{iss}} := \mathsf{BLAKE2b\text{-}256}(\mathtt{''ZcashIP32Issuance''}, S)\) - .
      • -
    -

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 12, as described below.

    -
      -
    • The issuance authorizing key is derived from the issuance master key, - \(\mathsf{sk}_{\mathsf{iss}}\) - , as a private signature key:
      • -
    -
    \(\mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{sk}_{\mathsf{iss}} )\)
    -
      -
    • The issuance validating key is derived from the issuance authorizing key, - \(\mathsf{isk}\) - , as a public verification key:
      • -
    -
    \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 8. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    -

    The derivation of these keys are shown in the following diagram:

    -
    - -
    Diagram of Issuance Key Components for the ZSA Protocol
    -
    +

    Issuance Authorization Signature Scheme

    +

    We define the issuance authorization signature scheme + \(\mathsf{IssueAuthSig}\) + similar to + \(\mathsf{SpendAuthSig}^{\mathsf{Orchard}}\) + , the Orchard spend authorization signature scheme 15. Specifically, we instantiate + \(\mathsf{IssueAuthSig}\) + as + \(\mathsf{RedPallas}\) + without key re-randomization using generator + \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})\) + where + \(\mathsf{GroupHash}^\mathbb{P}\) + is defined as in the Zcash protocol specification 12.

    +
    +

    Issuance Key Derivation

    +

    The issuance master key is generated by choosing a bit sequence uniformly at random from + \(\mathbb{B}^{\mathbb{Y}[32]}\) + , like the Orchard spending key 13. In + \(\mathsf{zcashd}\) + , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 9, as detailed below:

    +
      +
    • Details TBD
      • +
    +

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 13, as described below.

    +
      +
    • The issuance authorizing key is derived from the issuance master key, + \(\mathsf{sk}_{\mathsf{iss}}\) + , as a private signature key:
      • +
    +
    \(\mathsf{isk} := \mathsf{ToScalar}^{\mathsf{Orchard}}(︀ \mathsf{sk}_{\mathsf{iss}} )\)
    +
      +
    • The issuance validating key is derived from the issuance authorizing key, + \(\mathsf{isk}\) + , as a public verification key:
      • +
    +
    \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)
    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 8. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    The derivation of these keys are shown in the following diagram:

    +
    + +
    Diagram of Issuance Key Components for the ZSA Protocol
    +
    +

    Asset Identifier

    For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair @@ -169,7 +166,7 @@ \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 11.

    + is defined as in 12.

    The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

    @@ -249,7 +246,7 @@ \(\mathsf{isk}\) , that validates the issuance . -

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 15.

    +

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 16.

    @@ -341,7 +338,7 @@

    Asset Features

      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example,
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
      @@ -389,7 +386,7 @@
      • For each note, compute the note commitment as \(\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) - as defined in the Note Structure and Commitment section of ZIP 226 5 and
        • + as defined in the Note Structure and Commitment section of ZIP 226 5 and
      • add \(\mathsf{cm}\) to the Merkle tree of note commitments, NoteCommitmentTree.
        • @@ -475,7 +472,7 @@ \(\mathsf{AssetId}\) .
      -

      Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

      +

      Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

      Other Considerations

      Implementing Zcash Nodes

      @@ -486,7 +483,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

      Fee Structures

      -

      The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 7.

      +

      The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 7.

      Future Work

      In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -573,10 +570,18 @@

    - +
    + + + +
    9ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation
    + + + + @@ -584,7 +589,7 @@
    10 ZIP 316: Unified Addresses and Unified Viewing Keys
    - + @@ -592,7 +597,7 @@
    1011 Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys
    - + @@ -600,7 +605,7 @@
    1112 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta
    - + @@ -608,7 +613,7 @@
    1213 Zcash Protocol Specification, Version 2022.3.8. Section 4.2.3: Orchard Key Components
    - + @@ -616,7 +621,7 @@
    1314 Zcash Protocol Specification, Version 2022.3.8. Section 4.15: Spend Authorization Signature (Sapling and Orchard)
    - + @@ -624,7 +629,7 @@
    1415 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)
    - + diff --git a/zip-0227.rst b/zip-0227.rst index c17df1f95..a83bb15fc 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -81,17 +81,9 @@ The protocol was designed with three main properties in mind: The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. -Issuance Authorization Signature Scheme ---------------------------------------- - -The requirement of cryptographic authorization in order to issue new Assets or change attributes of existing Assets is met by using a signature to prove knowledge of the issuance key used to authorize the issuance of the Asset, similar to what is done with the Spend Authorization Signature [#protocol-spendauthsig]_. - -We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` similar to the Orchard spend authorization signature scheme, :math:`\mathsf{SpendAuthSig}^{\mathsf{Orchard}}` [#protocol-concretespendauthsig]_. -Specifically, we instantiate :math:`\mathsf{IssueAuthSig}` as :math:`\mathsf{RedPallas}` without key re-randomization using generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. - -Issuance Keys -------------- +Issuance Keys & Issuance Authorization Signature Scheme +------------------------------------------------------- The ZSA Protocol adds the following three keys to the key components [#protocol-addressesandkeys]_: @@ -101,10 +93,19 @@ The ZSA Protocol adds the following three keys to the key components [#protocol- 3. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer. +Issuance Authorization Signature Scheme +``````````````````````````````````````` + +We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` similar to :math:`\mathsf{SpendAuthSig}^{\mathsf{Orchard}}`, the Orchard spend authorization signature scheme [#protocol-concretespendauthsig]_. +Specifically, we instantiate :math:`\mathsf{IssueAuthSig}` as :math:`\mathsf{RedPallas}` without key re-randomization using generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in the Zcash protocol specification [#protocol-concretegrouphashpallasandvesta]_. + +Issuance Key Derivation +``````````````````````` + The issuance master key is generated by choosing a bit sequence uniformly at random from :math:`\mathbb{B}^{\mathbb{Y}[32]}`, like the Orchard spending key [#protocol-orchardkeycomponents]_. -In :math:`\mathsf{zcashd}`, this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 [#zip-0032]_, as detailed below: +In :math:`\mathsf{zcashd}`, this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 [#zip-0032-orchard-master]_, as detailed below: -- Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 bytes and at most 252 bytes. Compute the issuance master key :math:`\mathsf{sk}_{\mathsf{iss}} := \mathsf{BLAKE2b\text{-}256}(\mathtt{''ZcashIP32Issuance''}, S)`. +- Details TBD The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key [#protocol-orchardkeycomponents]_, as described below. @@ -422,6 +423,7 @@ References .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ +.. [#zip-0032-orchard-master] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ .. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys `_ .. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ From b265a018f8321bd328188f52483b4b31ff0920f2 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Tue, 28 Feb 2023 14:44:09 +0530 Subject: [PATCH 086/101] Editing the "previously_finalized" definitions to only deal with finalize setting at each block Co-authored-by: Daira Hopwood --- zip-0227.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0227.rst b/zip-0227.rst index a83bb15fc..594b74d98 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -166,9 +166,9 @@ The relations between the Asset Identifier, Asset Digest, and Asset Base are sho Global Issuance State --------------------- -Issuance requires the following additions to the global state: +Issuance requires the following additions to the global state defined at block boundaries: -- ``previously_finalized``, a set of :math:`\mathsf{AssetId}` that have been finalized (i.e.: the ``finalize`` flag has been set to ``1``). +- :math:`\mathsf{previously\_finalized}`, a set of :math:`\mathsf{AssetId}` that have been finalized (i.e.: the ``finalize`` flag has been set to ``1`` in some issuance transaction preceding the block boundary). Issuance Action Description --------------------------- @@ -179,7 +179,7 @@ An issuance action, `IssueAction`, is the instance of issuing a specific custom - `notes`: an array containing the unencrypted output notes of the recipients of the Asset, of type `Note` - ``finalize``: a boolean that defines whether the issuance of that specific custom Asset is finalized or not -Once ``finalize`` is set to 1, it cannot be unset. For Assets whose ``finalize = 1``, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets whose ``finalize = 0``, new issuance actions can be issued in future transactions. These must use the same Asset description, :math:`\mathsf{asset\_desc}`, and can either maintain ``finalize = 0`` or change it to ``finalize = 1``, denoting the last transaction containing issuance of such custom Asset. +An asset's :math:`\mathsf{AssetId}` is added to the :math:`\mathsf{previously\_finalized}` set after a block that contains any issuance transaction for that asset with ``finalize = 1``. It then cannot be removed from this set. For Assets with :math:`\mathsf{AssetId} \in \mathsf{previously\_finalized}`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with :math:`\mathsf{AssetId} \not\in \mathsf{previously\_finalized}`, new issuance actions can be issued in future transactions. These must use the same Asset description, :math:`\mathsf{asset\_desc}`, and can either maintain ``finalize = 0`` or change it to ``finalize = 1``, denoting that this custom Asset cannot be issued after the containing block. ================= =============================== ========================== ======================================================================== Size Name Data Type Description From e8d879667e09a5e0f99f8c707d6cb8d0161c63ab Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 28 Feb 2023 14:48:36 +0530 Subject: [PATCH 087/101] editing the asset digest section --- zip-0227.html | 4 ++-- zip-0227.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index a6bda3cfe..b91c977f2 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -152,7 +152,7 @@ be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

    Define - \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\mathtt{''ZZSA-AssetDigest''},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))\) + \(\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\texttt{"ZSA-Asset-Digest"},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))\) , where

    • @@ -163,7 +163,7 @@ \(\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})\) , where

      In the case of Orchard, we define - \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})\) + \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_digest}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_digest})\) where \(\mathsf{GroupHash}^\mathbb{P}\) is defined as in 12.

      diff --git a/zip-0227.rst b/zip-0227.rst index 594b74d98..35d8ac6e1 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -142,7 +142,7 @@ Let - :math:`\mathsf{asset\_desc}` be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance. - :math:`\mathsf{ik}` be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH. -Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\mathtt{''ZZSA-AssetDigest''},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))`, +Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \textsf{BLAKE2b-512}(\texttt{"ZSA-Asset-Digest"},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))`, where - :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{0x00} || \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!`. @@ -150,7 +150,7 @@ where Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})`, where -In the case of Orchard, we define :math:`\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})` +In the case of Orchard, we define :math:`\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_digest}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_digest})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_. The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram: From 40f1a6c6579e15bd043258f64c21e99e27df70ba Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 28 Feb 2023 14:55:00 +0530 Subject: [PATCH 088/101] adding rationale for the finalize happening at block boundaries --- zip-0227.html | 21 ++++++++++++++++----- zip-0227.rst | 3 +++ 2 files changed, 19 insertions(+), 5 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index b91c977f2..68cfef5d2 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -174,11 +174,13 @@

      Global Issuance State

      -

      Issuance requires the following additions to the global state:

      +

      Issuance requires the following additions to the global state defined at block boundaries:

        -
      • previously_finalized, a set of +
      • + \(\mathsf{previously\_finalized}\) + , a set of \(\mathsf{AssetId}\) - that have been finalized (i.e.: the finalize flag has been set to 1).
        • + that have been finalized (i.e.: the finalize flag has been set to 1 in some issuance transaction preceding the block boundary).

      Issuance Action Description

      @@ -190,9 +192,17 @@
    • notes: an array containing the unencrypted output notes of the recipients of the Asset, of type Note
    • finalize: a boolean that defines whether the issuance of that specific custom Asset is finalized or not
    -

    Once finalize is set to 1, it cannot be unset. For Assets whose finalize = 1, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets whose finalize = 0, new issuance actions can be issued in future transactions. These must use the same Asset description, +

    An asset's + \(\mathsf{AssetId}\) + is added to the + \(\mathsf{previously\_finalized}\) + set after a block that contains any issuance transaction for that asset with finalize = 1. It then cannot be removed from this set. For Assets with + \(\mathsf{AssetId} \in \mathsf{previously\_finalized}\) + , no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with + \(\mathsf{AssetId} \not\in \mathsf{previously\_finalized}\) + , new issuance actions can be issued in future transactions. These must use the same Asset description, \(\mathsf{asset\_desc}\) - , and can either maintain finalize = 0 or change it to finalize = 1, denoting the last transaction containing issuance of such custom Asset.

    + , and can either maintain finalize = 0 or change it to finalize = 1, denoting that this custom Asset cannot be issued after the containing block.

    1516 Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    @@ -410,6 +420,7 @@
  • information to be committed by the issuer, though not enforceable by the protocol.
    • +
  • We require a check whether the finalize flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the previously_finalized set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.

    • TxId Digest

    diff --git a/zip-0227.rst b/zip-0227.rst index 35d8ac6e1..641380186 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -291,6 +291,9 @@ The following is a list of rationale for different decisions made in the proposa - bridging information for Wrapped Assets (chain of origin, issuer name, etc) - information to be committed by the issuer, though not enforceable by the protocol. +- We require a check whether the ``finalize`` flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the ``previously_finalized`` set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve. + + TxId Digest =========== A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:: From b2b92aa9bf23740004fcd437401488030f125469 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Thu, 2 Mar 2023 11:42:10 +0530 Subject: [PATCH 089/101] Fixing typos in owner details Co-authored-by: Deirdre Connolly --- zip-0226.rst | 4 ++-- zip-0227.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0226.rst b/zip-0226.rst index b74756a43..c3cc5cf6e 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -4,9 +4,9 @@ Title: Transfer and Burn of Zcash Shielded Assets Owners: Pablo Kogan Vivek Arte - Daira Hopwood + Daira Emma Hopwood Jack Grigg - Deidre Connolly + Deirdre Connolly Credits: Daniel Benarroch Aurelien Nicolas Status: Draft diff --git a/zip-0227.rst b/zip-0227.rst index 641380186..faa78cc98 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -4,9 +4,9 @@ Title: Issuance of Zcash Shielded Assets Owners: Pablo Kogan Vivek Arte - Daira Hopwood + Daira Emma Hopwood Jack Grigg - Deidre Connolly + Deirdre Connolly Credits: Daniel Benarroch Aurelien Nicolas Status: Draft From 2d2643fa6be69147a5420701db2562b378191c1e Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Thu, 2 Mar 2023 11:44:21 +0530 Subject: [PATCH 090/101] Applying suggestions from ZIP review Co-authored-by: Deirdre Connolly --- zip-0227.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0227.rst b/zip-0227.rst index faa78cc98..201efc97f 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -82,8 +82,8 @@ The protocol was designed with three main properties in mind: The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. -Issuance Keys & Issuance Authorization Signature Scheme -------------------------------------------------------- +Issuance Keys and Issuance Authorization Signature Scheme +--------------------------------------------------------- The ZSA Protocol adds the following three keys to the key components [#protocol-addressesandkeys]_: @@ -276,7 +276,7 @@ If all of the above checks pass, do the following: - For each note, compute the note commitment as :math:`\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` as defined in the Note Structure and Commitment section of ZIP 226 [#zip-0226-notestructure]_ and - add :math:`\mathsf{cm}` to the Merkle tree of note commitments, `NoteCommitmentTree`. -- If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set in the global state. +- If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set immediately after the block in which this transaction occurs. Rationale From 1ef4663a638d1ab80ad961751d05004a073f62ae Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 4 Mar 2023 21:19:40 +0530 Subject: [PATCH 091/101] updating html files to reflect rst changes --- zip-0226.html | 4 ++-- zip-0227.html | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/zip-0226.html b/zip-0226.html index 132425350..15f69f6e9 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -11,9 +11,9 @@ Title: Transfer and Burn of Zcash Shielded Assets Owners: Pablo Kogan <pablo@qed-it.com> Vivek Arte <vivek@qed-it.com> - Daira Hopwood <daira@electriccoin.co> + Daira Emma Hopwood <daira@electriccoin.co> Jack Grigg <str4d@electriccoin.co> - Deidre Connolly <deirdre@zfnd.org> + Deirdre Connolly <deirdre@zfnd.org> Credits: Daniel Benarroch Aurelien Nicolas Status: Draft diff --git a/zip-0227.html b/zip-0227.html index 68cfef5d2..10cbae1c8 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -11,9 +11,9 @@ Title: Issuance of Zcash Shielded Assets Owners: Pablo Kogan <pablo@qed-it.com> Vivek Arte <vivek@qed-it.com> - Daira Hopwood <daira@electriccoin.co> + Daira Emma Hopwood <daira@electriccoin.co> Jack Grigg <str4d@electriccoin.co> - Deidre Connolly <deirdre@zfnd.org> + Deirdre Connolly <deirdre@zfnd.org> Credits: Daniel Benarroch Aurelien Nicolas Status: Draft @@ -69,7 +69,7 @@

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    -

    Issuance Keys & Issuance Authorization Signature Scheme

    +

    Issuance Keys and Issuance Authorization Signature Scheme

    The ZSA Protocol adds the following three keys to the key components 11:

    1. The issuance master key, denoted as @@ -402,7 +402,7 @@ to the Merkle tree of note commitments, NoteCommitmentTree.
    2. If finalize = 1, add \(\mathsf{AssetId}\) - to the previously_finalized set in the global state.
      3. + to the previously_finalized set immediately after the block in which this transaction occurs.
    From 881959b2b386b63e0031b25ed9a1ee5debfb9f58 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 4 Mar 2023 23:45:25 +0530 Subject: [PATCH 092/101] rearrangement of ZIP 227 motivation and requirements --- zip-0227.html | 19 +++++++------------ zip-0227.rst | 26 ++++++++++---------------- 2 files changed, 17 insertions(+), 28 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 10cbae1c8..381da3c8d 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -37,6 +37,8 @@

    Motivation

    This ZIP is a supporting ZIP for ZIP 226 4, which lays out its motivations, but requires an issuance mechanism to be defined (which is substantial enough to stand on its own) in order to function.

    +

    This ZIP enables only transparent issuance, since as a first step, transparency will allow for proper testing of the applications that will be most used in the Zcash ecosystem, and will enable the supply of Assets to be tracked.

    +

    The issuance mechanism described in this ZIP is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import "wrapped" Assets. This enables what we hope will be a useful set of applications.

    Use Cases

    The design presented in this ZIP enables issuance of shielded Assets in various modes:

    @@ -52,23 +54,15 @@
    • Any user of the Zcash block chain can issue custom Assets on chain.
    • The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain.
      • +
    • At the time of issuance, the issuer should be able to allocate all the Assets to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. This allows for allocation to be totally private even though the issuance mechanism is itself transparent.
    • Issuing or changing the attributes of a specific Asset should require cryptographic authorization.
    • The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset Identifier.
      • -
    • An issuer should be able to issue different Assets in the same transaction.
      • +
    • An issuer should be able to issue different Assets in the same transaction. In other words, in a single "issuance bundle", the issuer should be able publish many "issuance actions", potentially creating multiple Custom Assets.
      • +
    • Every "issuance action" should contain a finalize boolean that defines whether the specific Custom Asset can have further tokens issued or not.

    Specification

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    -

    Overview

    -

    This specification enables only transparent issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifier, as the Asset Identifiers are tied to the issuer keys.

    -

    The protocol was designed with three main properties in mind:

    -
      -
    • At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private.
      • -
    • In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple Custom Assets.
      • -
    • Every issuance action contains the finalize boolean that defines whether that specific Custom Asset can have further tokens issued or not.
      • -
    -

    The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.

    -

    Issuance Keys and Issuance Authorization Signature Scheme

    The ZSA Protocol adds the following three keys to the key components 11:

      @@ -409,7 +403,8 @@

      Rationale

      The following is a list of rationale for different decisions made in the proposal:

        -
      • The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets.
        • +
      • The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This is in order to keep the issuance details and the Asset Identifiers consistent across multiple shielded pools.
        • +
      • The design decision is not to have a chosen name to describe the Custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.
      • The \(\mathsf{asset\_desc}\) is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: diff --git a/zip-0227.rst b/zip-0227.rst index 201efc97f..edfc10e1d 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -41,6 +41,11 @@ Motivation This ZIP is a supporting ZIP for ZIP 226 [#zip-0226]_, which lays out its motivations, but requires an issuance mechanism to be defined (which is substantial enough to stand on its own) in order to function. +This ZIP enables only *transparent* issuance, since as a first step, transparency will allow for proper testing of the applications that will be most used in the Zcash ecosystem, and will enable the supply of Assets to be tracked. + +The issuance mechanism described in this ZIP is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import "wrapped" Assets. This enables what we hope will be a useful set of applications. + + Use Cases ========= @@ -58,9 +63,11 @@ Requirements - Any user of the Zcash block chain can issue custom Assets on chain. - The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash block chain. +- At the time of issuance, the issuer should be able to allocate all the Assets to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. This allows for allocation to be totally private even though the issuance mechanism is itself transparent. - Issuing or changing the attributes of a specific Asset should require cryptographic authorization. - The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset Identifier. -- An issuer should be able to issue different Assets in the same transaction. +- An issuer should be able to issue different Assets in the same transaction. In other words, in a single "issuance bundle", the issuer should be able publish many "issuance actions", potentially creating multiple Custom Assets. +- Every "issuance action" should contain a ``finalize`` boolean that defines whether the specific Custom Asset can have further tokens issued or not. Specification @@ -68,20 +75,6 @@ Specification As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions. -Overview --------- - -This specification enables only *transparent* issuance, since as a first step, transparency is important to properly test the applications that will be most used in the Zcash ecosystem, while enabling tracking of supply of Assets. Any user of the block chain can issue new Asset Identifiers, yet only a single issuer (a set of keys) can issue that specific Asset Identifier, as the Asset Identifiers are tied to the issuer keys. - -The protocol was designed with three main properties in mind: - -- At the time of issuance, the issuer can already allocate all the tokens to the corresponding owners by creating the corresponding (shielded) output notes to the respective addresses. As is implied, the issuance mechanism is itself transparent, but the allocation is totally private. -- In a single issuance bundle, the issuer can publish many issuance actions, or in other words, create multiple Custom Assets. -- Every issuance action contains the ``finalize`` boolean that defines whether that specific Custom Asset can have further tokens issued or not. - -The issuance mechanism is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash block chain), as well as for institutions to create bridges from other chains and import Wrapped Assets. In fact, the protocol described below enables what we hope will be a useful set of applications. The design decision is not to have a chosen name to describe the custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. - - Issuance Keys and Issuance Authorization Signature Scheme --------------------------------------------------------- @@ -283,7 +276,8 @@ Rationale ========= The following is a list of rationale for different decisions made in the proposal: -- The issuance key structure was kept aligned to the original key tree in order to ease issuance integration with wallets and to prevent users from having to manage multiple keys and secrets. +- The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This is in order to keep the issuance details and the Asset Identifiers consistent across multiple shielded pools. +- The design decision is not to have a chosen name to describe the Custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. - The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: - links for storage such as for NFTs. From 00e6c7bd61ab2711b09141cedd35316ff26084c7 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 7 Mar 2023 12:33:12 +0530 Subject: [PATCH 093/101] link to QEDIT deploy of ZIP 317 --- zip-0227.html | 2 +- zip-0227.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 381da3c8d..ca1af0b3e 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -564,7 +564,7 @@
    - +
    7ZIP 317b: ZSA Extension Proportional Fee MechanismZIP 317: Proportional Fee Mechanism
    diff --git a/zip-0227.rst b/zip-0227.rst index edfc10e1d..0c603cfae 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -418,7 +418,7 @@ References .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0226-notestructure] `ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ -.. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ +.. [#zip-0317b] `ZIP 317: Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0032-orchard-master] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ From c84e4f42e8e30732fdc236131fddfb59a5cb5a32 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 7 Mar 2023 12:38:59 +0530 Subject: [PATCH 094/101] moving concrete applications to top level heading --- zip-0227.html | 56 +++++++++++++++++++++++++-------------------------- zip-0227.rst | 41 +++++++++++++++++++------------------ 2 files changed, 49 insertions(+), 48 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index ca1af0b3e..2c42ecc04 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -335,33 +335,6 @@

    NOTE that the commitment is not included in the IssuanceAction itself. As explained below, it is later computed by the validators and added to the NoteCommitmentTree.

    -

    Concrete Applications

    -

    Bridging Assets Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    -
      -
    • First, the issuance and burn mechanism can be used in conjunction to determine the
      • -
    -

    Asset Features

    -
      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, -
        -
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • -
      -
      • -
    • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by -
        -
      • issuing a last set of tokens of that specific - \(\mathsf{AssetId}\) - , during which finalize = 1, or by
        • -
      • issuing a transaction with a single note in the issuance action pertaining to that - \(\mathsf{AssetId}\) - , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
        • -
      -
      • -
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each - \(\mathsf{AssetId}\) - corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
      • -
    -

    Consensus Rule Changes

    For the IssueBundle:

      @@ -390,7 +363,7 @@
      • For each note, compute the note commitment as \(\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) - as defined in the Note Structure and Commitment section of ZIP 226 5 and
        • + as defined in the Note Structure and Commitment section of ZIP 226 5 and
      • add \(\mathsf{cm}\) to the Merkle tree of note commitments, NoteCommitmentTree.
        • @@ -400,6 +373,33 @@
    +

    Concrete Applications

    +

    Bridging Assets Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    +
      +
    • First, the issuance and burn mechanism can be used in conjunction to determine the
      • +
    +

    Asset Features

    +
      +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
        +
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • +
      +
      • +
    • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by +
        +
      • issuing a last set of tokens of that specific + \(\mathsf{AssetId}\) + , during which finalize = 1, or by
        • +
      • issuing a transaction with a single note in the issuance action pertaining to that + \(\mathsf{AssetId}\) + , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
        • +
      +
      • +
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each + \(\mathsf{AssetId}\) + corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
      • +
    +

    Rationale

    The following is a list of rationale for different decisions made in the proposal:

      diff --git a/zip-0227.rst b/zip-0227.rst index 0c603cfae..f68f953b5 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -230,26 +230,6 @@ For the `IssueBundle`: NOTE that the commitment is not included in the `IssuanceAction` itself. As explained below, it is later computed by the validators and added to the `NoteCommitmentTree`. -Concrete Applications ---------------------- - -**Bridging Assets** -Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - -- First, the issuance and burn mechanism can be used in conjunction to determine the - -**Asset Features** - -- By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any Asset associated to their issuer keys. For example, - - - by setting ``finalize = 1`` from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. - -- Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by - - - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, during which ``finalize = 1``, or by - - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations). - -- Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. Consensus Rule Changes ---------------------- @@ -271,6 +251,27 @@ If all of the above checks pass, do the following: - add :math:`\mathsf{cm}` to the Merkle tree of note commitments, `NoteCommitmentTree`. - If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set immediately after the block in which this transaction occurs. +Concrete Applications +===================== + +**Bridging Assets** +Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): + +- First, the issuance and burn mechanism can be used in conjunction to determine the + +**Asset Features** + +- By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any Asset associated to their issuer keys. For example, + + - by setting ``finalize = 1`` from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed. + +- Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by + + - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, during which ``finalize = 1``, or by + - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations). + +- Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. + Rationale ========= From af4cf9e65d57c5b4bc9b5c24552c0f9699de1505 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 7 Mar 2023 14:48:21 +0530 Subject: [PATCH 095/101] moving Concrete Applications to within the Rationale --- zip-0227.html | 54 +++++++++++++++++++++++++-------------------------- zip-0227.rst | 33 ++++++++++++++++--------------- 2 files changed, 44 insertions(+), 43 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 2c42ecc04..089b9b5e2 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -373,33 +373,6 @@
    -

    Concrete Applications

    -

    Bridging Assets Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    -
      -
    • First, the issuance and burn mechanism can be used in conjunction to determine the
      • -
    -

    Asset Features

    -
      -
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, -
        -
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • -
      -
      • -
    • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by -
        -
      • issuing a last set of tokens of that specific - \(\mathsf{AssetId}\) - , during which finalize = 1, or by
        • -
      • issuing a transaction with a single note in the issuance action pertaining to that - \(\mathsf{AssetId}\) - , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
        • -
      -
      • -
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each - \(\mathsf{AssetId}\) - corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
      • -
    -

    Rationale

    The following is a list of rationale for different decisions made in the proposal:

      @@ -417,6 +390,33 @@
    • We require a check whether the finalize flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the previously_finalized set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.
    +

    Concrete Applications

    +

    Bridging Assets Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    +
      +
    • First, the issuance and burn mechanism can be used in conjunction to determine the
      • +
    +

    Asset Features

    +
      +
    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, +
        +
      • by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
        • +
      +
      • +
    • Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by +
        +
      • issuing a last set of tokens of that specific + \(\mathsf{AssetId}\) + , during which finalize = 1, or by
        • +
      • issuing a transaction with a single note in the issuance action pertaining to that + \(\mathsf{AssetId}\) + , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
        • +
      +
      • +
    • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each + \(\mathsf{AssetId}\) + corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
      • +
    +

    TxId Digest

    A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

    diff --git a/zip-0227.rst b/zip-0227.rst index f68f953b5..33332b55b 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -251,8 +251,24 @@ If all of the above checks pass, do the following: - add :math:`\mathsf{cm}` to the Merkle tree of note commitments, `NoteCommitmentTree`. - If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set immediately after the block in which this transaction occurs. + +Rationale +========= +The following is a list of rationale for different decisions made in the proposal: + +- The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This is in order to keep the issuance details and the Asset Identifiers consistent across multiple shielded pools. +- The design decision is not to have a chosen name to describe the Custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. +- The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: + + - links for storage such as for NFTs. + - metadata for Assets, encoded in any format. + - bridging information for Wrapped Assets (chain of origin, issuer name, etc) + - information to be committed by the issuer, though not enforceable by the protocol. + +- We require a check whether the ``finalize`` flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the ``previously_finalized`` set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve. + Concrete Applications -===================== +--------------------- **Bridging Assets** Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): @@ -273,21 +289,6 @@ Issuers can wrap Assets defined in other chains and issue them at once in a sing - Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. -Rationale -========= -The following is a list of rationale for different decisions made in the proposal: - -- The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This is in order to keep the issuance details and the Asset Identifiers consistent across multiple shielded pools. -- The design decision is not to have a chosen name to describe the Custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”. -- The :math:`\mathsf{asset\_desc}` is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are: - - - links for storage such as for NFTs. - - metadata for Assets, encoded in any format. - - bridging information for Wrapped Assets (chain of origin, issuer name, etc) - - information to be committed by the issuer, though not enforceable by the protocol. - -- We require a check whether the ``finalize`` flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the ``previously_finalized`` set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve. - TxId Digest =========== From 2ef7c97488f3eeb8ac7462a9dc764a3e98048e98 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 14 Mar 2023 01:13:45 +0530 Subject: [PATCH 096/101] adding Teor to credits --- zip-0226.html | 1 + zip-0226.rst | 1 + zip-0227.html | 1 + zip-0227.rst | 1 + 4 files changed, 4 insertions(+) diff --git a/zip-0226.html b/zip-0226.html index 15f69f6e9..acda0ca62 100644 --- a/zip-0226.html +++ b/zip-0226.html @@ -16,6 +16,7 @@ Deirdre Connolly <deirdre@zfnd.org> Credits: Daniel Benarroch Aurelien Nicolas + Teor Status: Draft Category: Consensus Created: 2022-05-01 diff --git a/zip-0226.rst b/zip-0226.rst index c3cc5cf6e..517f63159 100644 --- a/zip-0226.rst +++ b/zip-0226.rst @@ -9,6 +9,7 @@ Deirdre Connolly Credits: Daniel Benarroch Aurelien Nicolas + Teor Status: Draft Category: Consensus Created: 2022-05-01 diff --git a/zip-0227.html b/zip-0227.html index 089b9b5e2..596f139cf 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -16,6 +16,7 @@ Deirdre Connolly <deirdre@zfnd.org> Credits: Daniel Benarroch Aurelien Nicolas + Teor Status: Draft Category: Consensus Created: 2022-05-01 diff --git a/zip-0227.rst b/zip-0227.rst index 33332b55b..086cec2ab 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -9,6 +9,7 @@ Deirdre Connolly Credits: Daniel Benarroch Aurelien Nicolas + Teor Status: Draft Category: Consensus Created: 2022-05-01 From 890df09f0d9a17b65f9cfc0087cfd7c2343bdf7e Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 14 Mar 2023 01:20:16 +0530 Subject: [PATCH 097/101] fixing inconsistency in ZIP 227 Consensus Rule Changes --- zip-0227.html | 16 ++++++++++------ zip-0227.rst | 6 +++--- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 596f139cf..befab468a 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -347,23 +347,27 @@ \(\mathsf{asset\_desc}\) is a string with 0 < byte size <= 512.
  • retrieve - \(\mathsf{AssetId}\) + \(\mathsf{AssetBase}\) from the first note in the sequence and check that - \(\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}\) - is properly derived.
    • + \(\mathsf{AssetBase}\) + is derived from the issuance validating key + \(\mathsf{ik}\) + and + \(\mathsf{asset\_desc}\) + as described in the Asset Identifier section.
  • check that the \(\mathsf{AssetId}\) does not exist in the previously_finalized set in the global state.
  • check that every note in the IssueAction contains the same - \(\mathsf{AssetId}\) + \(\mathsf{AssetBase}\) and is properly constructed as - \(note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})\) + \(note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetBase})\) .

    • If all of the above checks pass, do the following:

    • For each note, compute the note commitment as - \(\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}\) + \(\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetBase)}\) as defined in the Note Structure and Commitment section of ZIP 226 5 and
    • add \(\mathsf{cm}\) diff --git a/zip-0227.rst b/zip-0227.rst index 086cec2ab..c07d918d8 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -242,13 +242,13 @@ For the IssueBundle: For each `IssueAction` in `IssueBundle`: - check that :math:`\mathsf{asset\_desc}` is a string with `0 < byte size <= 512`. -- retrieve :math:`\mathsf{AssetId}` from the first note in the sequence and check that :math:`\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}` is properly derived. +- retrieve :math:`\mathsf{AssetBase}` from the first note in the sequence and check that :math:`\mathsf{AssetBase}` is derived from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as described in the `Asset Identifier`_ section. - check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state. -- check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetId}` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`. +- check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetBase}` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetBase})`. If all of the above checks pass, do the following: -- For each note, compute the note commitment as :math:`\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetId)}` as defined in the Note Structure and Commitment section of ZIP 226 [#zip-0226-notestructure]_ and +- For each note, compute the note commitment as :math:`\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}(repr_{\mathbb{P}}(g_d), repr_{\mathbb{P}}(pk_d), v, \rho, \psi, AssetBase)}` as defined in the Note Structure and Commitment section of ZIP 226 [#zip-0226-notestructure]_ and - add :math:`\mathsf{cm}` to the Merkle tree of note commitments, `NoteCommitmentTree`. - If ``finalize = 1``, add :math:`\mathsf{AssetId}` to the ``previously_finalized`` set immediately after the block in which this transaction occurs. From 639f46bd3d07981bc41edc47b446dd2c1bf46d51 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 14 Mar 2023 10:30:38 +0530 Subject: [PATCH 098/101] fixing bridging text --- zip-0227.html | 5 +---- zip-0227.rst | 7 ++----- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index befab468a..d862f352b 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -396,10 +396,6 @@
    • We require a check whether the finalize flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the previously_finalized set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.

    Concrete Applications

    -

    Bridging Assets Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges):

    -
      -
    • First, the issuance and burn mechanism can be used in conjunction to determine the
      • -

    Asset Features

    • By using the finalize boolean and the burning mechanism defined in 4, issuers can control the supply production of any Asset associated to their issuer keys. For example, @@ -417,6 +413,7 @@ , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
    +
  • The issuance and burn mechanisms can be used in conjunction to determine the supply of Assets on the Zcash ecosystem. This allows for the bridging of Assets defined on other chains.
  • Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each \(\mathsf{AssetId}\) corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.
    • diff --git a/zip-0227.rst b/zip-0227.rst index c07d918d8..e0c29fcc5 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -271,11 +271,6 @@ The following is a list of rationale for different decisions made in the proposa Concrete Applications --------------------- -**Bridging Assets** -Issuers can wrap Assets defined in other chains and issue them at once in a single transaction. The specifics of the bridge are not implemented in the protocol, but there are several ways we conceive issuers can build these bridges (at least centralized bridges): - -- First, the issuance and burn mechanism can be used in conjunction to determine the - **Asset Features** - By using the ``finalize`` boolean and the burning mechanism defined in [#zip-0226]_, issuers can control the supply production of any Asset associated to their issuer keys. For example, @@ -287,6 +282,8 @@ Issuers can wrap Assets defined in other chains and issue them at once in a sing - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, during which ``finalize = 1``, or by - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations). +- The issuance and burn mechanisms can be used in conjunction to determine the supply of Assets on the Zcash ecosystem. This allows for the bridging of Assets defined on other chains. + - Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each :math:`\mathsf{AssetId}` corresponds to ``value = 1`` at the fundamental unit level. Issuers and users should make sure that ``finalize = 1`` for each of the actions in this scenario. From 633a4406b7401b9dc71273b3f5a27b14b2e4266f Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 14 Mar 2023 11:21:10 +0530 Subject: [PATCH 099/101] additions based on review comments --- zip-0227.html | 3 ++- zip-0227.rst | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index d862f352b..f0f8d267c 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -407,10 +407,11 @@
    • issuing a last set of tokens of that specific \(\mathsf{AssetId}\) - , during which finalize = 1, or by
      • + , for which finalize = 1, or by
    • issuing a transaction with a single note in the issuance action pertaining to that \(\mathsf{AssetId}\) , where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
      • +
    • Note in the above cases, that the setting of the finalize flag will take effect at the block boundary, that is, after all the transactions in the block.
  • The issuance and burn mechanisms can be used in conjunction to determine the supply of Assets on the Zcash ecosystem. This allows for the bridging of Assets defined on other chains.
    • diff --git a/zip-0227.rst b/zip-0227.rst index e0c29fcc5..0d4cfdc7b 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -279,8 +279,9 @@ Concrete Applications - Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by - - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, during which ``finalize = 1``, or by + - issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, for which ``finalize = 1``, or by - issuing a transaction with a single note in the issuance action pertaining to that :math:`\mathsf{AssetId}`, where the note will contain a ``value = 0``. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations). + - Note in the above cases, that the setting of the ``finalize`` flag will take effect at the block boundary, that is, after all the transactions in the block. - The issuance and burn mechanisms can be used in conjunction to determine the supply of Assets on the Zcash ecosystem. This allows for the bridging of Assets defined on other chains. From 7475f6cf0560928604f8d16551dcd4ea609181f2 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Tue, 14 Mar 2023 13:53:09 +0530 Subject: [PATCH 100/101] Changes to issuance_txid_digest to align with ZIP 244 (#7) * changes to issuance_txid_digest to align with ZIP 244 * using flagsIssuance in place of a single bit boolean for the issue actions as well * fixing small typo --- zip-0227.html | 113 +++++++++++++++++++++++++++++++------------------- zip-0227.rst | 70 +++++++++++++++++++------------ 2 files changed, 114 insertions(+), 69 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index f0f8d267c..2632424a4 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -65,7 +65,7 @@

    Specification

    As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.

    Issuance Keys and Issuance Authorization Signature Scheme

    -

    The ZSA Protocol adds the following three keys to the key components 11:

    +

    The ZSA Protocol adds the following three keys to the key components 12:

    1. The issuance master key, denoted as \(\mathsf{sk}_{\mathsf{iss}}\) @@ -82,7 +82,7 @@ \(\mathsf{IssueAuthSig}\) similar to \(\mathsf{SpendAuthSig}^{\mathsf{Orchard}}\) - , the Orchard spend authorization signature scheme 15. Specifically, we instantiate + , the Orchard spend authorization signature scheme 16. Specifically, we instantiate \(\mathsf{IssueAuthSig}\) as \(\mathsf{RedPallas}\) @@ -90,18 +90,18 @@ \(\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in the Zcash protocol specification 12.

      + is defined as in the Zcash protocol specification 13.

    Issuance Key Derivation

    The issuance master key is generated by choosing a bit sequence uniformly at random from \(\mathbb{B}^{\mathbb{Y}[32]}\) - , like the Orchard spending key 13. In + , like the Orchard spending key 14. In \(\mathsf{zcashd}\) - , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 9, as detailed below:

    + , this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 10, as detailed below:

    • Details TBD
    -

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 13, as described below.

    +

    The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key 14, as described below.

    • The issuance authorizing key is derived from the issuance master key, \(\mathsf{sk}_{\mathsf{iss}}\) @@ -114,7 +114,7 @@ , as a public verification key:
    \(\mathsf{ik} := \mathsf{IssueAuthSig}.\mathsf{DerivePublic}(\mathsf{isk})\)
    -

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 8. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    +

    This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 9. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

    The derivation of these keys are shown in the following diagram:

    @@ -161,7 +161,7 @@ \(\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_digest}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_digest})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 12.

    + is defined as in 13.

    The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

    @@ -229,10 +229,10 @@ A sequence of note descriptions within the issuance action - 1 bit - finalize - boolean - The boolean that determines the finality of the issuance of that Asset + 1 byte + flagsIssuance + byte + An 8-bit value with the finalize boolean value as the LSB, and the other bits set to 0. @@ -251,7 +251,7 @@ \(\mathsf{isk}\) , that validates the issuance . -

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 16.

    +

    The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format 18.

    @@ -422,31 +422,38 @@

    TxId Digest

    -

    A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

    +

    As in ZIP 244 7, the digests are all personalized BLAKE2b-256 hashes, and in cases where no elements are available for hashing, a personalized hash of the empty byte array is used.

    +

    A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of issuance transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

    issuance_txid_digest
-├── issueActions
-└── issuerVerificationKey
    +├── issue_actions_digest +└── issuanceValidatingKey

    In the specification below, nodes of the tree are presented in depth-first order.

    issuance_txid_digest

    A BLAKE2b-256 hash of the following values

    - 
    T.1: issueActions            (field encoding bytes)
-T.2: issuerVerificationKey   (field encoding bytes)
    + 
    T.1: issue_actions_digest    (32-byte hash output)
+T.2: issuanceValidatingKey   (32 bytes)

    The personalization field of this hash is set to:

    - 
    "ZTxIdOrcZSAIssue"
    -

    T.1 issueActions

    -

    A byte encoding of Issue Action information for all Issue Actions belonging to the transaction. For each Action, the following elements are included in the hash:

    - 
    T.1a: notes                   (field encoding bytes)
+                
    "ZTxIdSAIssueHash"
    
+                
    In case the transaction has no issuance components, ''issue_actions_digest'' is:
    
+                
    BLAKE2b-256("ZTxIdSAIssueHash", [])
    
+                
    T.1: issue_actions_digest 
    
+                    
    A BLAKE2b-256 hash of Issue Action information for all Issuance Actions belonging to the transaction. For each Action, the following elements are included in the hash:
    
+                    
    T.1a: notes_digest            (32-byte hash output)
 T.1b: assetDescription        (field encoding bytes)
-T.1c: isFinalized             (1 bit)
    
-                    
    T.1a: notes 
    
-                        
    A byte encoding of Note information for all Notes belonging to the Action. For each Note, the following elements are included in the hash:
    
+T.1c: flagsIssuance           (1 byte)
    +

    The personalization field of this hash is set to:

    + 
    "ZTxIdIssActHash"
    +
    T.1a: notes_digest
    +

    A BLAKE2b-256 hash of Note information for all Notes belonging to the Issuance Action. For each Note, the following elements are included in the hash:

    T.1a.1: recipient                    (field encoding bytes)
 T.1a.2: value                        (field encoding bytes)
 T.1a.3: asset                        (field encoding bytes)
 T.1a.4: rho                          (field encoding bytes)
 T.1a.5: rseed                        (field encoding bytes)
    +

    The personalization field of this hash is set to:

    + 
    "ZTxIdIANoteHash"
    T.1a.1: recipient
    -

    Raw Address encoded as specified in [Zcash Protocol Spec § 5.6.4.2: Orchard Raw Payment Addresses].

    +

    This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification 17.

    T.1a.2: value

    Note value encoded as little-endian 8-byte representation of u64 raw value.

    @@ -464,12 +471,16 @@
    T.1b: assetDescription

    UTF-8 encoding of the Asset description string.

    -
    T.1c: isFinalized
    -

    1-bit representation of a boolean flag that is set to 'true' if the Asset Identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0.

    +
    T.1c: flagsIssuance
    +

    An 8-bit value representing a set of flags. Ordered from LSB to MSB:

    +
      +
    • finalize
      • +
    • The remaining bits are set to 0.
      • +
    -

    T.2 issuerVerificationKey

    -

    A byte encoding of issuer validating key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components].

    +

    T.2: issuanceValidatingKey

    +

    A byte encoding of issuance validating key for the bundle as defined in the Issuance Key Derivation section.

    @@ -481,7 +492,7 @@ \(\mathsf{AssetId}\) . -

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    +

    Bridging Assets For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 4. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

    Other Considerations

    Implementing Zcash Nodes

    @@ -492,7 +503,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 7.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317b 8.

    Future Work

    In future versions of this ZIP, the protocol may also include a "key rotation" mechanism. This would allow an issuer to change the underlying @@ -563,18 +574,26 @@

    - +
    - +
    7ZIP 317: Proportional Fee MechanismZIP 244: Transaction Identifier Non-Malleability
    - +
    + + + +
    8ZIP 317b: ZSA Extension Proportional Fee Mechanism
    + + + + @@ -582,7 +601,7 @@
    9 ZIP 32: Shielded Hierarchical Deterministic Wallets
    - + @@ -590,7 +609,7 @@
    910 ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation
    - + @@ -598,7 +617,7 @@
    1011 ZIP 316: Unified Addresses and Unified Viewing Keys
    - + @@ -606,7 +625,7 @@
    1112 Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys
    - + @@ -614,7 +633,7 @@
    1213 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta
    - + @@ -622,7 +641,7 @@
    1314 Zcash Protocol Specification, Version 2022.3.8. Section 4.2.3: Orchard Key Components
    - + @@ -630,15 +649,23 @@
    1415 Zcash Protocol Specification, Version 2022.3.8. Section 4.15: Spend Authorization Signature (Sapling and Orchard)
    - +
    1516 Zcash Protocol Specification, Version 2022.3.8. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)
    + + + + + + + +
    17Zcash Protocol Specification, Version 2022.3.8. Section 5.6.4.2: Orchard Raw Payment Addresses
    - + diff --git a/zip-0227.rst b/zip-0227.rst index 0d4cfdc7b..31fe86cac 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -175,14 +175,14 @@ An issuance action, `IssueAction`, is the instance of issuing a specific custom An asset's :math:`\mathsf{AssetId}` is added to the :math:`\mathsf{previously\_finalized}` set after a block that contains any issuance transaction for that asset with ``finalize = 1``. It then cannot be removed from this set. For Assets with :math:`\mathsf{AssetId} \in \mathsf{previously\_finalized}`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with :math:`\mathsf{AssetId} \not\in \mathsf{previously\_finalized}`, new issuance actions can be issued in future transactions. These must use the same Asset description, :math:`\mathsf{asset\_desc}`, and can either maintain ``finalize = 0`` or change it to ``finalize = 1``, denoting that this custom Asset cannot be issued after the containing block. -================= =============================== ========================== ======================================================================== +================= =============================== ========================== =========================================================================================== Size Name Data Type Description -================= =============================== ========================== ======================================================================== +================= =============================== ========================== =========================================================================================== Varies :math:`\mathsf{asset\_desc}` byte UTF-8 encoded string of varied size, up to 512 bytes Varies nNotes compactSize The number of notes in the issuance action noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action -1 bit ``finalize`` boolean The boolean that determines the finality of the issuance of that Asset -================= =============================== ========================== ======================================================================== +1 byte ``flagsIssuance`` byte An 8-bit value with the ``finalize`` boolean value as the LSB, and the other bits set to 0. +================= =============================== ========================== =========================================================================================== We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the `NoteCommitmentTree` as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers. @@ -291,11 +291,14 @@ Concrete Applications TxId Digest =========== -A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:: + +As in ZIP 244 [#zip-0244]_, the digests are all personalized BLAKE2b-256 hashes, and in cases where no elements are available for hashing, a personalized hash of the empty byte array is used. + +A new issuance transaction digest algorithm is defined that constructs the identifier for an issuance transaction. Each branch of the tree of hashes will correspond to a specific subset of issuance transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:: issuance_txid_digest - ├── issueActions - └── issuerVerificationKey + ├── issue_actions_digest + └── issuanceValidatingKey In the specification below, nodes of the tree are presented in depth-first order. @@ -303,25 +306,32 @@ issuance_txid_digest -------------------- A BLAKE2b-256 hash of the following values :: - T.1: issueActions (field encoding bytes) - T.2: issuerVerificationKey (field encoding bytes) + T.1: issue_actions_digest (32-byte hash output) + T.2: issuanceValidatingKey (32 bytes) The personalization field of this hash is set to:: - "ZTxIdOrcZSAIssue" + "ZTxIdSAIssueHash" -T.1 issueActions -```````````````` -A byte encoding of Issue Action information for all Issue Actions belonging to the transaction. For each Action, the following elements are included in the hash:: +In case the transaction has no issuance components, ''issue_actions_digest'' is:: + + BLAKE2b-256("ZTxIdSAIssueHash", []) - T.1a: notes (field encoding bytes) +T.1: issue_actions_digest +````````````````````````` +A BLAKE2b-256 hash of Issue Action information for all Issuance Actions belonging to the transaction. For each Action, the following elements are included in the hash:: + + T.1a: notes_digest (32-byte hash output) T.1b: assetDescription (field encoding bytes) - T.1c: isFinalized (1 bit) + T.1c: flagsIssuance (1 byte) + +The personalization field of this hash is set to:: + "ZTxIdIssActHash" -T.1a: notes -''''''''''' -A byte encoding of Note information for all Notes belonging to the Action. For each Note, the following elements are included in the hash:: +T.1a: notes_digest +'''''''''''''''''' +A BLAKE2b-256 hash of Note information for all Notes belonging to the Issuance Action. For each Note, the following elements are included in the hash:: T.1a.1: recipient (field encoding bytes) T.1a.2: value (field encoding bytes) @@ -329,10 +339,13 @@ A byte encoding of Note information for all Notes belonging to the Action. For e T.1a.4: rho (field encoding bytes) T.1a.5: rseed (field encoding bytes) +The personalization field of this hash is set to:: + + "ZTxIdIANoteHash" T.1a.1: recipient ................. -Raw Address encoded as specified in [Zcash Protocol Spec § 5.6.4.2: Orchard Raw Payment Addresses]. +This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification [#protocol-orchardpaymentaddrencoding]_. T.1a.2: value ............. @@ -354,14 +367,17 @@ T.1b: assetDescription '''''''''''''''''''''' UTF-8 encoding of the Asset description string. -T.1c: isFinalized -''''''''''''''''' -1-bit representation of a boolean flag that is set to 'true' if the Asset Identifier was finalized in this action and 'false' otherwise. 'True' is represented as 1, 'false' as 0. +T.1c: flagsIssuance +''''''''''''''''''' +An 8-bit value representing a set of flags. Ordered from LSB to MSB: +- ``finalize`` +- The remaining bits are set to `0`. -T.2 issuerVerificationKey -````````````````````````` -A byte encoding of issuer validating key for the bundle as defined in [Zcash Protocol Spec § 4.2.3: Orchard Key Components]. + +T.2: issuanceValidatingKey +`````````````````````````` +A byte encoding of issuance validating key for the bundle as defined in the `Issuance Key Derivation`_ section. Security and Privacy Considerations @@ -419,7 +435,8 @@ References .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0226-notestructure] `ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ -.. [#zip-0317b] `ZIP 317: Proportional Fee Mechanism `_ +.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ +.. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0032-orchard-master] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ @@ -428,4 +445,5 @@ References .. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.3.8. Section 4.2.3: Orchard Key Components `_ .. [#protocol-spendauthsig] `Zcash Protocol Specification, Version 2022.3.8. Section 4.15: Spend Authorization Signature (Sapling and Orchard) `_ .. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) `_ +.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.3.8. Section 5.6.4.2: Orchard Raw Payment Addresses `_ .. [#protocol-transactionstructure] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5) `_ \ No newline at end of file From 81b6a00126024acfded51584bc5c7ab39132a654 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Tue, 14 Mar 2023 14:32:31 +0530 Subject: [PATCH 101/101] Addition of length prefix to Asset description in issuance action (#9) * changes to issuance_txid_digest to align with ZIP 244 * using flagsIssuance in place of a single bit boolean for the issue actions as well * adding assetDescSize field to IssueAction, and corresponding changes to the consensus rule changes section * rename authorization to issueAuthSig --- zip-0227.html | 34 +++++++++++++++++++++++++++++----- zip-0227.rst | 13 ++++++++----- 2 files changed, 37 insertions(+), 10 deletions(-) diff --git a/zip-0227.html b/zip-0227.html index 2632424a4..d0c39c846 100644 --- a/zip-0227.html +++ b/zip-0227.html @@ -181,6 +181,13 @@

    Issuance Action Description

    An issuance action, IssueAction, is the instance of issuing a specific custom Asset, and contains the following fields:

      +
    • + \(\mathsf{assetDescSize}\) + : the size of the Asset description, a number between + \(0\) + and + \(512\) + , stored in two bytes.
    • \(\mathsf{asset\_desc}\) : the Asset description, a UTF-8 encoded string of up to 512 bytes
      • @@ -208,13 +215,25 @@
    + + + + + + - + @@ -247,7 +266,7 @@ \(\mathsf{AssetId}\) is properly associated with the issuer.
  • actions: an array of issuance actions, of type IssueAction.
    • -
  • authorization: the signature of the transaction SIGHASH, signed by the issuance authorizing key, +
  • issueAuthSig: the signature of the transaction SIGHASH, signed by the issuance authorizing key, \(\mathsf{isk}\) , that validates the issuance .
    • @@ -284,7 +303,7 @@ - + @@ -339,13 +358,18 @@

    Consensus Rule Changes

    For the IssueBundle:

      -
    • Verify the RedPallas-based issuance authorization signature on SIGHASH, authorization, is verified by invoking authorization.VerifySig(ik, SIGHASH)
      • +
    • Verify the RedPallas-based issuance authorization signature on SIGHASH, issueAuthSig, is verified by invoking issueAuthSig.VerifySig(ik, SIGHASH)

    For each IssueAction in IssueBundle:

      +
    • check that + \(0 < \mathsf{assetDescSize} <= 512\) + .
    • check that \(\mathsf{asset\_desc}\) - is a string with 0 < byte size <= 512.
      • + is a string of length + \(\mathsf{assetDescSize}\) + bytes.
    • retrieve \(\mathsf{AssetBase}\) from the first note in the sequence and check that diff --git a/zip-0227.rst b/zip-0227.rst index 31fe86cac..06ec10528 100644 --- a/zip-0227.rst +++ b/zip-0227.rst @@ -169,6 +169,7 @@ Issuance Action Description An issuance action, `IssueAction`, is the instance of issuing a specific custom Asset, and contains the following fields: +- :math:`\mathsf{assetDescSize}`: the size of the Asset description, a number between :math:`0` and :math:`512`, stored in two bytes. - :math:`\mathsf{asset\_desc}`: the Asset description, a UTF-8 encoded string of up to 512 bytes - `notes`: an array containing the unencrypted output notes of the recipients of the Asset, of type `Note` - ``finalize``: a boolean that defines whether the issuance of that specific custom Asset is finalized or not @@ -178,7 +179,8 @@ An asset's :math:`\mathsf{AssetId}` is added to the :math:`\mathsf{previously\_f ================= =============================== ========================== =========================================================================================== Size Name Data Type Description ================= =============================== ========================== =========================================================================================== -Varies :math:`\mathsf{asset\_desc}` byte UTF-8 encoded string of varied size, up to 512 bytes +2 bytes :math:`\mathsf{assetDescSize}` byte The length of the :math:`\mathsf{asset\_desc}` string in bytes +Varies :math:`\mathsf{asset\_desc}` byte UTF-8 encoded string, of size :math:`\mathsf{assetDescSize}` bytes Varies nNotes compactSize The number of notes in the issuance action noteSize * nNotes vNotes Note[nNotes] A sequence of note descriptions within the issuance action 1 byte ``flagsIssuance`` byte An 8-bit value with the ``finalize`` boolean value as the LSB, and the other bits set to 0. @@ -193,7 +195,7 @@ An issuance bundle, `IssueBundle`, is the aggregate of all the issuance-related - :math:`\mathsf{ik}`: the issuance validating key, that allows the validators to verify that the :math:`\mathsf{AssetId}` is properly associated with the issuer. - `actions`: an array of issuance actions, of type `IssueAction`. -- `authorization`: the signature of the transaction SIGHASH, signed by the issuance authorizing key, :math:`\mathsf{isk}`, that validates the issuance . +- `issueAuthSig`: the signature of the transaction SIGHASH, signed by the issuance authorizing key, :math:`\mathsf{isk}`, that validates the issuance . The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format [#protocol-transactionstructure]_. @@ -203,7 +205,7 @@ Bytes Name Data Type Description Varies nIssueActions compactSize The number of issuance actions in the bundle Varies vIssueActions IssueAction[nIssueActions] A sequence of issuance actions descriptions 32 :math:`\mathsf{ik}` byte[32] The issuance validating key of the issuer, used to validate the signature -64 authorization byte[64] The signature of the transaction SIGHASH, signed by the issuer +64 issueAuthSig byte[64] The signature of the transaction SIGHASH, signed by the issuer ======= ==================== ========================== ========================================================================= Issuance Protocol @@ -237,11 +239,12 @@ Consensus Rule Changes For the IssueBundle: -- Verify the RedPallas-based issuance authorization signature on `SIGHASH`, `authorization`, is verified by invoking `authorization.VerifySig(ik, SIGHASH)` +- Verify the RedPallas-based issuance authorization signature on `SIGHASH`, `issueAuthSig`, is verified by invoking `issueAuthSig.VerifySig(ik, SIGHASH)` For each `IssueAction` in `IssueBundle`: -- check that :math:`\mathsf{asset\_desc}` is a string with `0 < byte size <= 512`. +- check that :math:`0 < \mathsf{assetDescSize} <= 512`. +- check that :math:`\mathsf{asset\_desc}` is a string of length :math:`\mathsf{assetDescSize}` bytes. - retrieve :math:`\mathsf{AssetBase}` from the first note in the sequence and check that :math:`\mathsf{AssetBase}` is derived from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as described in the `Asset Identifier`_ section. - check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state. - check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetBase}` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetBase})`.
    1618 Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)
    2 bytes + \(\mathsf{assetDescSize}\) + byteThe length of the + \(\mathsf{asset\_desc}\) + string in bytes
    Varies \(\mathsf{asset\_desc}\) byteUTF-8 encoded string of varied size, up to 512 bytesUTF-8 encoded string, of size + \(\mathsf{assetDescSize}\) + bytes
    Varies
    64authorizationissueAuthSig byte[64] The signature of the transaction SIGHASH, signed by the issuer