zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIPs 226 and 227: remove trailing spaces. 

Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira-Emma Hopwood 2024-02-07 15:14:52 +00:00
parent 9eb00eeac3
commit a7a9c213db
3 changed files with 46 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
zip-0226.rst
View File

@ -48,7 +48,7 @@ This ZIP builds on the issuance mechanism introduced in ZIP 227 [#zip-0227]_.
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}`.
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 maps to an Asset Base :math:`\mathsf{AssetBase}` that is stored in Orchard-based ZSA notes.
These terms are formally defined in ZIP 227 [#zip-0227]_.
@ -79,16 +79,16 @@ This Asset Base will be the base point of the value commitment for the specific
Rationale for Asset Identifiers
```````````````````````````````
In future network and protocol upgrades, the same Asset description string can be carried on, potentially mapping into a different shielded pool. In that case, nodes should know how to transform the Asset Identifier, the Asset Digest, and the Asset Base from one shielded pool to another, while ensuring there are no balance violations [#zip-0209]_.
In future network and protocol upgrades, the same Asset description string can be carried on, potentially mapping into a different shielded pool. In that case, nodes should know how to transform the Asset Identifier, the Asset Digest, and the Asset Base from one shielded pool to another, while ensuring there are no balance violations [#zip-0209]_.
Note Structure & Commitment
---------------------------
Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e.
Let :math:`\mathsf{Note^{OrchardZSA}}` be the type of a ZSA note, i.e.
:math:`\mathsf{Note^{OrchardZSA}} := \mathsf{Note^{Orchard}} \times \mathbb{P}^*`.
An Orchard ZSA note differs from an Orchard note [#protocol-notes]_ by additionally including the Asset Base, :math:`\mathsf{AssetBase}`. So a ZSA note is a tuple :math:`(\mathsf{g_d, pk_d, v, \rho, \psi, \mathsf{AssetBase}})`,
where
where
- :math:`\mathsf{AssetBase} : \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]_, a valid group element that is not the identity and is not :math:`\bot`. The byte representation of the Asset Base is defined as :math:`\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase})`.
@ -101,16 +101,16 @@ We define the note commitment scheme :math:`\mathsf{NoteCommit^{OrchardZSA}_{rcm
where :math:`\mathbb{P}, \ell_{\mathbb{P}}, q_{\mathbb{P}}` are as defined for the Pallas curve [#protocol-pallasandvesta]_, and where :math:`\mathsf{NoteCommit}^{\mathsf{Orchard}}.\mathsf{Trapdoor}` and :math:`\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}
.. math:: \begin{align}
\mathsf{NoteCommit^{OrchardZSA}_{rcm}(g_{d}*, pk_{d}*, v, \rho, \psi, \mathsf{AssetBase})}
:=\begin{cases}
\mathsf{NoteCommit^{Orchard}_{rcm}(g_{d}\star, pk_{d}\star, v, \rho, \psi)}, &\text{if } \mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}} \\
:=\begin{cases}
\mathsf{NoteCommit^{Orchard}_{rcm}(g_{d}\star, pk_{d}\star, v, \rho, \psi)}, &\text{if } \mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}} \\
\mathsf{cm}_{\mathsf{ZSA}} &\text{otherwise}
\end{cases}
\end{align}
where:
.. math:: \begin{align}
\mathsf{cm}_{\mathsf{ZSA}} :=&\ \mathsf{SinsemillaHashToPoint}( \texttt{"z.cash:ZSA-NoteCommit-M"}, \\
&\ \ \ \mathsf{g_{d}*} \,||\, \mathsf{pk_{d}*} \,||\, \mathsf{I2LEBSP_{64}(v)} \,||\, \mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\rho) \,||\, \mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\psi) \,||\, \mathsf{asset\_base}) \\
@ -122,22 +122,22 @@ Note that :math:`\mathsf{repr}_{\mathbb{P}}` and :math:`\mathsf{GroupHash}^{\mat
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]_.
It consists of
It consists of
.. math:: (\mathsf{leadByte} : \mathbb{B}^{\mathbb{Y}}, \mathsf{d} : \mathbb{B}^{[\ell_{\mathsf{d}}]}, \mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}, \mathsf{rseed} : \mathbb{B}^{\mathbb{Y}[32]}, \mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]}, \mathsf{memo} : \mathbb{B}^{\mathbb{Y}[512]})
Rationale for Note Commitment
`````````````````````````````
In the ZSA protocol, the instance of the note commitment scheme, :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.
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.
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})} \in \mathsf{NoteCommit^{Orchard}.Output}
This definition can be viewed as a generalization of the Orchard note commitment, and will allow maintaining a single commitment instance for the note commitment, which will be used both for pre-ZSA Orchard and ZSA notes.
This definition can be viewed as a generalization of the Orchard note commitment, and will allow maintaining a single commitment instance for the note commitment, which will be used both for pre-ZSA Orchard and ZSA notes.
Value Commitment
----------------
@ -204,20 +204,20 @@ After computing :math:`\mathsf{bvk}`, the verifier MUST use it to verify the bin
Rationale for Value Balance Verification
````````````````````````````````````````
We assume :math:`n` Actions in a transfer. Out of these :math:`n` Actions, we further distinguish (for the sake of clarity) between Actions related to ZEC and Actions related to Custom Assets.
We assume :math:`n` Actions in a transfer. Out of these :math:`n` Actions, we further distinguish (for the sake of clarity) between Actions related to ZEC and Actions related to Custom Assets.
We denote by :math:`S_{\mathsf{ZEC}} \subseteq [1,n]` the set of indices of Actions that are related to ZEC, and by :math:`S_{\mathsf{CA}} = [1,n] \setminus S_{\mathsf{ZEC}}` the set of indices of Actions that are related to Custom Assets.
The right hand side of the value balance verification equation can be expanded to:
.. math:: ((\sum_{i \in S_{\mathsf{ZEC}}} \mathsf{cv^{net}}_{i}) + (\sum_{j \in S_{\mathsf{CA}}} \mathsf{cv^{net}}_{j})) - ([\mathsf{v^{balanceOrchard}}]\mathcal{V}^{\mathsf{Orchard}} + [0]\mathcal{R}^{\mathsf{Orchard}}) - (\sum_{(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}} [\mathsf{v}]\mathsf{AssetBase} + [0]\mathcal{R}^{\mathsf{Orchard}})
This equation contains the balance check of the Orchard protocol [#protocol-binding]_.
With ZSA, transfer Actions for Custom Assets must also be balanced across Asset Bases.
All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer.
This equation contains the balance check of the Orchard protocol [#protocol-binding]_.
With ZSA, transfer Actions for Custom Assets must also be balanced across Asset Bases.
All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer.
Custom Assets can be burnt, the mechanism for which reveals the amount and identifier of the Asset being burnt, within the :math:`\mathsf{assetBurn}` set.
As such, for a correctly constructed transaction, we will get :math:`\sum_{j \in S_{\mathsf{CA}}} \mathsf{cv}_j^{\mathsf{net}} - \sum_{(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}} [\mathsf{v}]\mathsf{AssetBase} = \mathsf{\sum_{j \in S_{\mathsf{CA}}} rcv_{j}^{net}}\mathcal{R}^{\mathsf{Orchard}}`.
When the Asset is not being burnt, the net balance of the input and output values is zero, and there will be no addition to the :math:`\mathsf{assetBurn}` vector.
When the Asset is not being burnt, the net balance of the input and output values is zero, and there will be no addition to the :math:`\mathsf{assetBurn}` vector.
Therefore, the relationship between :math:`\mathsf{bvk}` and :math:`\mathsf{bsk}` will hold if and only if, per Custom Asset, the sum of the net values of the relevant Actions equals the corresponding :math:`\mathsf{v}_k` value (or equals :math:`0` if that Asset is not in the :math:`\mathsf{assetBurn}` set), and for ZEC, the sum of the net values of the relevant Actions equals the :math:`\mathsf{v^{balanceOrchard}}` value.
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 must sum to zero **per Asset Base**, as the Pedersen commitments add up homomorphically only with respect to the same value base point.
@ -237,7 +237,7 @@ When the number of input notes of a particular Asset Base is smaller than the re
Wallets and other clients have to choose from the following to ensure the Asset Base is preserved for the output note of a Split Action:
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).
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).
@ -322,8 +322,8 @@ The transaction format for v6 transactions is described in ZIP 230 [#zip-0230]_.
TxId Digest
===========
The transaction digest algorithm defined in ZIP 244 [#zip-0244]_ is modified by the ZSA protocol to add a new branch for issuance information, along with modifications within the ``orchard_digest`` to account for the inclusion of the Asset Base.
The details of these changes are described in this section, and highlighted using the ``[UPDATED FOR ZSA]`` or ``[ADDED FOR ZSA]`` text label. We omit the details of the sections that do not change for the ZSA protocol.
The transaction digest algorithm defined in ZIP 244 [#zip-0244]_ is modified by the ZSA protocol to add a new branch for issuance information, along with modifications within the ``orchard_digest`` to account for the inclusion of the Asset Base.
The details of these changes are described in this section, and highlighted using the ``[UPDATED FOR ZSA]`` or ``[ADDED FOR ZSA]`` text label. We omit the details of the sections that do not change for the ZSA protocol.
txid_digest
-----------
@ -345,7 +345,7 @@ When Orchard Actions are present in the transaction, this digest is a BLAKE2b-25
T.4b: orchard_actions_memos_digest (32-byte hash output) [UPDATED FOR ZSA]
T.4c: orchard_actions_noncompact_digest (32-byte hash output) [UPDATED FOR ZSA]
T.4d: flagsOrchard (1 byte)
T.4e: valueBalanceOrchard (64-bit signed little-endian)
T.4e: valueBalanceOrchard (64-bit signed little-endian)
T.4f: anchorOrchard (32 bytes)
T.4a: orchard_actions_compact_digest

44
zip-0227.rst
View File

@ -51,7 +51,7 @@ Motivation
This ZIP introduces the issuance mechanism for Custom Assets on the Zcash chain. While originally part of a same ZSA ZIP (ZIP 226 [#zip-0226]_) the issuance mechanism turned out to be substantial enough to stand on its own and justify the creation of this supporting ZIP for ZIP 226 [#zip-0226]_.
This ZIP only enables *transparent* issuance. 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.
This ZIP only enables *transparent* issuance. 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 blockchain), 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.
@ -104,7 +104,7 @@ We instantiate the issuance authorization signature scheme :math:`\mathsf{IssueA
Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results; for example, for a given verification key :math:`pk`, :math:`\mathit{lift\_x}(\mathit{int}(pk))` MAY be precomputed.
We define the constants as per the secp256k1 standard parameters, as described in BIP 340.
We define the constants as per the secp256k1 standard parameters, as described in BIP 340.
The associated types of the :math:`\mathsf{IssueAuthSig}` signature scheme are as follows:
@ -128,7 +128,7 @@ The issuance authorizing key is generated using the Orchard master key derivatio
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
We define the master extended issuance key :math:`m_{\mathsf{Issuance}} := \mathsf{MasterKeyGen}(\texttt{"ZIP32ZSAIssue_V1"}, S)`.
As in ZIP 32 for Orchard [#zip-0032-orchard-child-key-derivation]_, we only use hardened child key derivation for the issuance authorizing key.
As in ZIP 32 for Orchard [#zip-0032-orchard-child-key-derivation]_, we only use hardened child key derivation for the issuance authorizing key.
We reuse the :math:`\mathsf{CDKsk}` function for Orchard child key derivation from ZIP 32.
We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD paths, and define the issuance authorizing key path as :math:`m_\mathsf{Issuance} / purpose' / coin\_type' / account'`. We fix the path levels as follows:
@ -147,10 +147,10 @@ Define :math:`\mathsf{IssueAuthSig.DerivePublic}\: : \: (\mathsf{isk}\: : \: \ma
* :math:`\mathsf{ik} := \textit{PubKey}(\mathsf{isk})`
* Return :math:`\bot` if the :math:`\textit{PubKey}` algorithm invocation fails, otherwise return :math:`\mathsf{ik}`.
where the :math:`\textit{PubKey}` algorithm is defined in BIP 340 [#bip-0340]_.
where the :math:`\textit{PubKey}` algorithm is defined in BIP 340 [#bip-0340]_.
Note that the byte representation of :math:`\mathsf{ik}` is in big-endian order as defined in BIP 340.
It is possible for the :math:`\textit{PubKey}` algorithm to fail with very low probability, which means that :math:`\mathsf{IssueAuthSig.DerivePublic}` could return :math:`\bot` with very low probability.
It is possible for the :math:`\textit{PubKey}` algorithm to fail with very low probability, which means that :math:`\mathsf{IssueAuthSig.DerivePublic}` could return :math:`\bot` with very low probability.
If this happens, discard the keys and repeat with a different :math:`\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.
@ -183,7 +183,7 @@ For every new Asset, there must be a new and unique Asset Identifier, denoted :m
A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-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 shielded protocol using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.
Let
Let
- :math:`\mathsf{asset\_desc}` be the asset description, which includes any information pertaining to the issuance, and is a byte sequence of up to 512 bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.
- :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.
@ -213,7 +213,7 @@ The relations between the Asset Identifier, Asset Digest, and Asset Base are sho
Wallets MUST NOT display just the :math:`\mathsf{asset\_desc}` string to their users as the name of the Asset. Some possible alternatives include:
- Wallets could allow clients to provide an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers via a petname system. 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.
- Wallets could allow clients to provide an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers via a petname system. 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.
- The Asset Digest could be used as a more compact bytestring to uniquely determine an Asset, and wallets could support clients scanning QR codes to load Asset information into their wallets.
Specification: Global Issuance State
@ -238,12 +238,12 @@ An issuance action, ``IssueAction``, is the instance of issuing a specific Custo
- ``flagsIssuance``: a byte that stores the :math:`\mathsf{finalize}` boolean that defines whether the issuance of that specific Custom Asset is finalized or not.
An asset's :math:`\mathsf{AssetDigest}` is added to the :math:`\mathsf{previously\_finalized}` set after a block that contains any issuance transaction for that asset with :math:`\mathsf{finalize} = 1`. It then cannot be removed from this set. For Assets with :math:`\mathsf{AssetDigest} \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{AssetDigest} \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 :math:`\mathsf{finalize} = 0` or change it to :math:`\mathsf{finalize} = 1`, denoting that this Custom Asset cannot be issued after the containing block.
+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+
| Bytes | Name | Data Type | Description |
+=============================+==========================+===========================================+=====================================================================+
|``2`` |``assetDescSize`` |``byte`` |The length of the :math:`\mathsf{asset\_desc}` string in bytes. |
|``2`` |``assetDescSize`` |``byte`` |The length of the :math:`\mathsf{asset\_desc}` string in bytes. |
+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+
|``assetDescSize`` |``asset_desc`` |``byte[assetDescSize]`` |A byte sequence of length ``assetDescSize`` bytes which SHOULD be a |
| | | |well-formed UTF-8 code unit sequence according to Unicode 15.0.0 |
@ -259,14 +259,14 @@ An asset's :math:`\mathsf{AssetDigest}` is added to the :math:`\mathsf{previousl
| | | | * The remaining bits are 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 note commitment tree as a shielded note.
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 note commitment tree 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.
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:
- :math:`\mathsf{ik}`: the issuance validating key, that allows the validators to verify that the :math:`\mathsf{AssetId}` is properly associated with the issuer.
@ -354,7 +354,7 @@ The following is a list of rationale for different decisions made in the proposa
- information to be committed by the issuer, though not enforceable by the protocol.
- We require a check whether the :math:`\mathsf{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 :math:`\mathsf{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.
- We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.
- We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.
Concrete Applications
---------------------
@ -369,7 +369,7 @@ Concrete Applications
- issuing a last set of tokens of that specific :math:`\mathsf{AssetId}`, for which :math:`\mathsf{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 :math:`\mathsf{finalize}` flag will take effect at the block boundary, that is, after all the transactions in the block.
- Note in the above cases, that the setting of the :math:`\mathsf{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.
@ -387,11 +387,11 @@ As in ZIP 244 [#zip-0244]_, the digests are all personalized BLAKE2b-256 hashes,
A new issuance transaction digest algorithm is defined that constructs the subtree of the transaction digest tree of hashes for the issuance portion of a transaction. Each branch of the subtree 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_digest
├── issue_actions_digest
│   ├── issue_notes_digest
│   ├── assetDescription
│   └── flagsIssuance
└── issuanceValidatingKey
├── issue_actions_digest
│   ├── issue_notes_digest
│   ├── assetDescription
│   └── flagsIssuance
└── issuanceValidatingKey
In the specification below, nodes of the tree are presented in depth-first order.
@ -407,7 +407,7 @@ The personalization field of this hash is set to::
"ZTxIdSAIssueHash"
In case the transaction has no issuance components, ''issue_actions_digest'' is::
BLAKE2b-256("ZTxIdSAIssueHash", [])
T.5a: issue_actions_digest
@ -506,7 +506,7 @@ Identical to that specified for the transaction identifier.
Authorizing Data Commitment
===========================
The transaction digest algorithm defined in ZIP 244 [#zip-0244-authcommitment]_ which commits to the authorizing data of a transaction is modified by the Orchard-ZSA protocol to have the following structure.
The transaction digest algorithm defined in ZIP 244 [#zip-0244-authcommitment]_ which commits to the authorizing data of a transaction is modified by the Orchard-ZSA protocol to have the following structure.
We highlight the changes for the Orchard-ZSA protocol via the ``[ADDED FOR ZSA]`` text label, and we omit the descriptions of the sections that do not change for the Orchard-ZSA protocol::
auth_digest
@ -548,7 +548,7 @@ Security and Privacy Considerations
Displaying Asset Identifier information to users
------------------------------------------------
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 provided in the `Specification: Asset Identifier`_ section.
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 provided in the `Specification: Asset Identifier`_ section.
Issuance Key Compromise
-----------------------

4
zip-0230.rst
View File

@ -46,7 +46,7 @@ Motivation
The Orchard-ZSA protocol requires serialized data elements that are distinct from
any previous Zcash transaction. Since ZIP 244 was activated in NU5, the
v5 and later serialized transaction formats are not consensus-critical.
v5 and later serialized transaction formats are not consensus-critical.
Thus, this ZIP defines format that can easily accommodate future extensions,
where elements or a given pool are kept separate.
@ -312,7 +312,7 @@ An issuance action, ``IssueAction``, is the instance of issuing a specific Custo
+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+
| Bytes | Name | Data Type | Description |
+=============================+==========================+===========================================+=====================================================================+
|``2`` |``assetDescSize`` |``byte`` |The length of the asset description string in bytes. |
|``2`` |``assetDescSize`` |``byte`` |The length of the asset description string in bytes. |
+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+
|``assetDescSize`` |``asset_desc`` |``byte[assetDescSize]`` |A byte sequence of length ``assetDescSize`` bytes which SHOULD be a |
| | | |well-formed UTF-8 code unit sequence according to Unicode 15.0.0 |