diff --git a/README.template b/README.template index 20ec55ac6..ee21debf4 100644 --- a/README.template +++ b/README.template @@ -55,6 +55,7 @@ The following ZIPs are under consideration for inclusion in NU7: - `ZIP 233: Network Sustainability Mechanism: Burning `__ - `ZIP 234: Network Sustainability Mechanism: Issuance Smoothing `__ - `ZIP 235: Network Sustainability Mechanism: Burn 60% of Transaction Fees `__ +- `ZIP 246: Digests for the Version 6 Transaction Format `__ - `ZIP 2002: Explicit Fees `__ - `ZIP 2003: Disallow version 4 transactions `__ - `ZIP 2004: Remove the dependency of consensus on note encryption `__ diff --git a/static/css/style.css b/static/css/style.css index bb2e6e3c8..e0a79a772 100644 --- a/static/css/style.css +++ b/static/css/style.css @@ -420,7 +420,7 @@ div.math { overflow-y: hidden; margin: 2.6rem 1rem 2.6rem 1rem; text-align: center; - padding: 0; + padding: 2rem; } a, a:visited { diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index 99403c73a..74898636d 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -345,206 +345,14 @@ OrchardZSA Transaction Structure 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 OrchardZSA protocol to add a new branch for issuance information, along with modifications within the ``orchard_digest`` to account for the inclusion of the Asset Base. -The details of these changes are described in this section, and highlighted using the ``[UPDATED FOR ZSA]`` or ``[ADDED FOR ZSA]`` text label. We omit the details of the sections that do not change for the OrchardZSA protocol. - -txid_digest ------------ -A BLAKE2b-256 hash of the following values:: - - T.1: header_digest (32-byte hash output) - T.2: transparent_digest (32-byte hash output) - T.3: sapling_digest (32-byte hash output) - T.4: orchard_digest (32-byte hash output) [UPDATED FOR ZSA] - T.5: issuance_digest (32-byte hash output) [ADDED FOR ZSA] - -The personalization field remains the same as in ZIP 244 [#zip-0244]_. - -T.4: orchard_digest -``````````````````` -When OrchardZSA Actions Groups are present in the transaction, this digest is a BLAKE2b-256 hash of the following values:: - - T.4a: orchard_action_groups_digest (32-byte hash output) [ADDED FOR ZSA] - T.4b: orchard_zsa_burn_digest (32-byte hash output) [ADDED FOR ZSA] - T.4c: valueBalanceOrchard (64-bit signed little-endian) - -The personalization field of this hash is the same as in ZIP 244 [#zip-0244]_ :: - - "ZTxIdOrchardHash" - -In the case that the transaction has no OrchardZSA Action Groups, ``orchard_digest`` is :: - - BLAKE2b-256("ZTxIdOrchardHash", []) - -T.4a: orchard_action_groups_digest -'''''''''''''''''''''''''''''''''' - -A BLAKE2b-256 hash of the subset of OrchardZSA Action Groups information for all OrchardZSA Action Groups belonging to the transaction. -For each Action Group, the following elements are included in the hash:: - - T.4a.i : orchard_actions_compact_digest (32-byte hash output) - T.4a.ii : orchard_actions_memos_digest (32-byte hash output) - T.4a.iii: orchard_actions_noncompact_digest (32-byte hash output) - T.4a.iv : flagsOrchard (1 byte) - T.4a.v : anchorOrchard (32 bytes) - T.4a.vi : nAGExpiryHeight (4 bytes) - -The personalization field of this hash is set to:: - - "ZTxIdOrcActGHash" - - -T.4a.i: orchard_actions_compact_digest -...................................... - -A BLAKE2b-256 hash of the subset of OrchardZSA Action information intended to be included in -an updated version of the ZIP-307 [#zip-0307]_ ``CompactBlock`` format for all OrchardZSA -Actions belonging to the Action Group. For each Action, the following elements are included -in the hash:: - - T.4a.i.1 : nullifier (field encoding bytes) - T.4a.i.2 : cmx (field encoding bytes) - T.4a.i.3 : ephemeralKey (field encoding bytes) - T.4a.i.4 : encCiphertext[..84] (First 84 bytes of field encoding) [UPDATED FOR ZSA] - -The personalization field of this hash is the same as in ZIP 244:: - - "ZTxIdOrcActCHash" - - -T.4a.ii: orchard_actions_memos_digest -..................................... - -A BLAKE2b-256 hash of the subset of Orchard shielded memo field data for all OrchardZSA -Actions belonging to the Action Group. For each Action, the following elements are included -in the hash:: - - T.4a.ii.1: encCiphertext[84..596] (contents of the encrypted memo field) [UPDATED FOR ZSA] - -The personalization field of this hash remains identical to ZIP 244:: - - "ZTxIdOrcActMHash" - - -T.4a.iii: orchard_actions_noncompact_digest -........................................... - -A BLAKE2b-256 hash of the remaining subset of OrchardZSA Action information **not** intended -for inclusion in an updated version of the the ZIP 307 [#zip-0307]_ ``CompactBlock`` -format, for all OrchardZSA Actions belonging to the Action Group. For each Action, -the following elements are included in the hash:: - - T.4a.iii.1 : cv (field encoding bytes) - T.4a.iii.2 : rk (field encoding bytes) - T.4a.iii.3 : encCiphertext[596..] (post-memo suffix of field encoding) [UPDATED FOR ZSA] - T.4a.iii.4 : outCiphertext (field encoding bytes) - -The personalization field of this hash is defined identically to ZIP 244:: - - "ZTxIdOrcActNHash" - -T.4b: orchard_zsa_burn_digest -''''''''''''''''''''''''''''' - -A BLAKE2b-256 hash of the data from the burn fields of the transaction. For each tuple in -the $\mathsf{assetBurn}$ set, the following elements are included in the hash:: - - T.4b.i : assetBase (field encoding bytes) - T.4b.ii: valueBurn (field encoding bytes) - -The personalization field of this hash is set to:: - - "ZTxIdOrcBurnHash" - -In case the transaction does not perform the burning of any Assets (i.e. the -$\mathsf{assetBurn}$ set is empty), the ''orchard_zsa_burn_digest'' is:: - - BLAKE2b-256("ZTxIdOrcBurnHash", []) - -T.4b.i: assetBase -................. -The Asset Base being burnt encoded as the 32-byte representation of a point on the -Pallas curve. - -T.4b.ii: valueBurn -.................. -Value of the Asset Base being burnt encoded as little-endian 8-byte representation -of 64-bit unsigned integer (e.g. u64 in Rust) raw value. - - -T.5: issuance_digest -```````````````````` -The details of the computation of this value are in ZIP 227 [#zip-0227-txiddigest]_. - -Signature Digest -================ - -The details of the changes to this algorithm are in ZIP 227 [#zip-0227-sigdigest]_. - -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 OrchardZSA protocol to have the structure specified in this section. -There is a new branch added for issuance information, along with modifications within the ``orchard_auth_digest`` to account for the presence of Action Groups. - -We highlight the changes for the OrchardZSA protocol via the ``[UPDATED FOR ZSA]`` or ``[ADDED FOR ZSA]`` text label, and we omit the descriptions of the sections that do not change for the OrchardZSA protocol:: - - auth_digest - ├── transparent_scripts_digest - ├── sapling_auth_digest - ├── orchard_auth_digest [UPDATED FOR ZSA] - └── issuance_auth_digest [ADDED FOR ZSA] - -The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block. - -auth_digest ------------ -A BLAKE2b-256 hash of the following values :: - - A.1: transparent_scripts_digest (32-byte hash output) - A.2: sapling_auth_digest (32-byte hash output) - A.3: orchard_auth_digest (32-byte hash output) [UPDATED FOR ZSA] - A.4: issuance_auth_digest (32-byte hash output) [ADDED FOR ZSA] - -The personalization field of this hash remains the same as in ZIP 244. - - -A.3: orchard_auth_digest -```````````````````````` - -In the case that OrchardZSA Action Groups are present, this is a BLAKE2b-256 hash of the following values:: - - A.3a: orchard_action_groups_auth_digest (32-byte hash output) [ADDED FOR ZSA] - A.3b: bindingSigOrchard (field encoding bytes) - -The personalization field of this hash is the same as in ZIP 244, that is:: - - "ZTxAuthOrchaHash" - -In case that the transaction has no OrchardZSA Action Groups, ``orchard_auth_digest`` is:: - - BLAKE2b-256("ZTxAuthOrchaHash", []) - -A.3a: orchard_action_groups_auth_digest -''''''''''''''''''''''''''''''''''''''' - -This is a BLAKE2b-256 hash of the ``proofsOrchard`` and ``spendAuthSigsOrchard`` fields of all OrchardZSA Action Groups belonging to the transaction:: - - A.3a.i: proofsOrchard (field encoding bytes) - A.3a.ii: spendAuthSigsOrchard (field encoding bytes) - -The personalization field of this hash is set to:: - - "ZTxAuthOrcAGHash" - -A.4: issuance_auth_digest -````````````````````````` +Modifications relative to ZIP 244 [#zip-0244]_ +============================================== -The details of the computation of this value are in ZIP 227 [#zip-0227-authcommitment]_. +Relative to the sighash algorithm defined in ZIP 244 [#zip-0244]_, the sighash algorithm +that applies to v6 transactions differs by altering the Orchard bundle within +the tree hash to match the corresponding OrchardZSA changes. See ZIP 246 [#zip-0246]_ +for details. Security and Privacy Considerations @@ -604,12 +412,11 @@ References .. [#zip-0227-consensus] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Consensus Rule Changes `_ .. [#zip-0227-note-commitment-order] `ZIP 227: Issuance of Zcash Shielded Assets: Addition to the Note Commitment Tree `_ .. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance `_ -.. [#zip-0227-sigdigest] `ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest `_ .. [#zip-0227-authcommitment] `ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment `_ .. [#zip-0227-orchardzsa-fee-calculation] `ZIP 227: Issuance of Zcash Shielded Assets: OrchardZSA Fee Calculation `_ .. [#zip-0230] `ZIP 230: Version 6 Transaction Format `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ -.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment `_ +.. [#zip-0246] `ZIP 246: Digests for the Version 6 Transaction Format `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ .. [#protocol-notes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes `_ .. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.7: Action Transfers and their Descriptions `_ diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 36315685a..91ff21fec 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -288,7 +288,9 @@ An Issue Note is a tuple $(\mathsf{d}, \mathsf{pk_d}, \mathsf{v}, \mathsf{AssetB - $\text{ρ}: \mathbb{F}_{q_{\mathbb{P}}}$ is used to derive the nullifier of the note, and is computed as in `Computation of ρ`_. - $\mathsf{rseed}: \mathbb{B}^{[\mathbb{Y}^{32}]}$ MUST be sampled uniformly at random by the issuer. -The complete encoding of these fields into an ``IssueNote`` is defined in ZIP 230 [#zip-0230-issue-note]_. +ZIP 230 [#zip-0230-issue-note]_ defines, in ``IssueNote``, field encodings which together with +$\mathsf{ik}$ from the parent `Issuance Bundle`_ and $\mathsf{AssetDescHash} from the parent +`Issuance Action`_, specify an Issue Note. Let $\mathsf{Note^{Issue}}$ be the type of an Issue Note, i.e. @@ -545,215 +547,30 @@ Concrete Applications -TxId Digest - Issuance -====================== +Modifications relative to ZIP 244 [#zip-0244]_ +============================================== -This section details the construction of the subtree of hashes in the transaction digest that corresponds to issuance transaction data. -Details of the overall changes to the transaction digest due to the OrchardZSA protocol can be found in ZIP 226 [#zip-0226-txiddigest]_. -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. +Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm +that applies to v6 transactions differs by including the issuance bundle +components within the tree hash. See ZIP 246 [#zip-0246]_ for details. -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 - │   ├── assetDescHash - │   └── flagsIssuance - └── issuanceValidatingKey +Changes to ZIP 317 [#zip-0317]_ +=============================== -In the specification below, nodes of the tree are presented in depth-first order. +The conventional fee in ZEC is altered to take into account both the presence of +issuance actions within a transaction, and the creation of new Custom Assets +within the global chain state. See the Fee calculation section of ZIP 317 +[#zip-0317-fee-calculation]_ for details. -T.5: issuance_digest --------------------- -A BLAKE2b-256 hash of the following values :: - T.5a: issue_actions_digest (32-byte hash output) - T.5b: issuanceValidatingKey (32 bytes) +Rationale for paying fees in ZEC +-------------------------------- -The personalization field of this hash is set to:: +.. raw:: html - "ZTxIdSAIssueHash" - -In case the transaction has no issuance components, ''issuance_digest'' is:: - - BLAKE2b-256("ZTxIdSAIssueHash", []) - -T.5a: 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.5a.i : notes_digest (32-byte hash output) - T.5a.ii : assetDescHash (32-byte hash output) - T.5a.iii: flagsIssuance (1 byte) - -The personalization field of this hash is set to:: - - "ZTxIdIssuActHash" - -T.5a.i: issue_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.5a.i.1: recipient (field encoding bytes) - T.5a.i.2: value (field encoding bytes) - T.5a.i.3: assetBase (field encoding bytes) - T.5a.i.4: rho (field encoding bytes) - T.5a.i.5: rseed (field encoding bytes) - -The personalization field of this hash is set to:: - - "ZTxIdIAcNoteHash" - -In case the transaction has no Issue Notes, ''issue_notes_digest'' is:: - - BLAKE2b-256("ZTxIdIAcNoteHash", []) - -T.5a.i.1: recipient -................... -This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification [#protocol-orchardpaymentaddrencoding]_. - -T.5a.i.2: value -............... -Note value encoded as little-endian 8-byte representation of 64-bit unsigned integer (e.g. u64 in Rust) raw value. - -T.5a.i.3: assetBase -................... -Asset Base encoded as the 32-byte representation of a point on the Pallas curve. - -T.5a.i.4: rho -............. -Nullifier encoded as 32-byte representation of a point on the Pallas curve. - -T.5a.i.5: rseed -............... -The ZIP 212 32-byte seed randomness for a note. - -T.5a.ii: assetDescription -''''''''''''''''''''''''' -The Asset description byte string. - -T.5a.iii: flagsIssuance -''''''''''''''''''''''' -An 8-bit value representing a set of flags. Ordered from LSB to MSB: - -- $\mathsf{finalize}$ -- The remaining bits are set to `0\!`. - - -T.5b: issuanceValidatingKey -``````````````````````````` -A byte encoding of issuance validating key for the bundle as defined in the `Issuance Key Derivation`_ section. - -Signature Digest -================ - -The per-input transaction digest algorithm to generate the signature digest in ZIP 244 [#zip-0244-sigdigest]_ is modified so that a signature digest is produced for each transparent input, each Sapling input, each Orchard action, and additionally for each Issuance Action. -For Issuance Actions, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly. - -The overall structure of the hash is as follows. We highlight the changes for the OrchardZSA protocol via the ``[ADDED FOR ZSA]`` text label, and we omit the descriptions of the sections that do not change for the OrchardZSA protocol:: - - signature_digest - ├── header_digest - ├── transparent_sig_digest - ├── sapling_digest - ├── orchard_digest - └── issuance_digest [ADDED FOR ZSA] - -signature_digest ----------------- -A BLAKE2b-256 hash of the following values :: - - S.1: header_digest (32-byte hash output) - S.2: transparent_sig_digest (32-byte hash output) - S.3: sapling_digest (32-byte hash output) - S.4: orchard_digest (32-byte hash output) - S.5: issuance_digest (32-byte hash output) [ADDED FOR ZSA] - -The personalization field remains the same as in ZIP 244 [#zip-0244]_. - -S.5: issuance_digest -```````````````````` -Identical to that specified for the transaction identifier. - -Authorizing Data Commitment - Issuance -====================================== - -This section covers the construction of the subtree of hashes in the authorizing data commitment that corresponds to issuance transaction data. -Details of the overall changes to the authorizing data commitment due to the OrchardZSA protocol can be found in ZIP 226 [#zip-0226-authcommitment]_. - -A.4: issuance_auth_digest -------------------------- - -In the case that Issuance Actions are present, this is a BLAKE2b-256 hash of the field encoding of the ``issueAuthSig`` field of the transaction:: - - A.4a: issueAuthSig (field encoding bytes) - -The personalization field of this hash is set to:: - - "ZTxAuthZSAOrHash" - -In the case that the transaction has no Orchard Actions, ``issuance_auth_digest`` is :: - - BLAKE2b-256("ZTxAuthZSAOrHash", []) - - -OrchardZSA Fee Calculation -========================== - -In addition to the parameters defined in the Fee calculation section of ZIP 317 [#zip-0317-fee-calc]_, the OrchardZSA protocol upgrade defines the following additional parameters: - -===================================== ========================================================================== -Parameter Value -===================================== ========================================================================== -:math:`issuance\_fee` :math:`100 \cdot marginal\_fee` per issuance action (as defined below) -===================================== ========================================================================== - -Wallets implementing this specification SHOULD use a conventional fee, viz. $zsa\_conventional\_fee$, that is -calculated in zatoshis. Additional definitions that are used in the formula for the calculation are in the table below: - -================================ ====== ==================================================================================================================== -Input Units Description -================================ ====== ==================================================================================================================== -:math:`nOrchardActions` number the number of OrchardZSA transfer actions (including ZEC actions) -:math:`nTotalOutputsZSAIssuance` number the total number of OrchardZSA issuance outputs (added across issuance actions) -:math:`nCreateActions` number the number of OrchardZSA issuance actions that issue a Custom Asset that is not present in the Global Issuance State -================================ ====== ==================================================================================================================== - -The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification [#protocol-txnencoding]_ and the global state. -They are defined in the Fee calculation section of ZIP 317 [#zip-0317-fee-calc]_. -Note that $nOrchardActions$, that is used in the computation of $logical\_actions$, is redefined in the above table, and now combines the actions for native ZEC as well as OrchardZSA transfer actions for Custom Assets. - -The formula for the computation of the $zsa\_logical\_actions$ (with the updated computation of $logical\_actions$ as described above) is: - -.. math:: - zsa\_logical\_actions = logical\_actions \;+ nTotalOutputsZSAIssuance - -The formula for the computation of the $zsa\_conventional\_fee$ is: - -.. math:: - \begin{array}{rcl} - zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ - & & issuance\_fee \cdot nCreateActions - \end{array} - - - - -It is not a consensus requirement that fees follow this formula; however, -wallets SHOULD create transactions that pay this fee, in order to reduce -information leakage, unless overridden by the user. - -Rationale for OrchardZSA Fee calculation ----------------------------------------- - -The OrchardZSA fee calculation accounts for the additions to the Global Issuance State that are required for the OrchardZSA protocol. -Every newly created Custom Asset adds a new row to the Global Issuance State. -Subsequent issuance, finalization, or burn of existing Custom Assets only changes the values in the corresponding row. - -This explains the need for a higher fee for the creation of entirely new Custom Assets, in order to disincentivize the creation of "junk" assets. - -OrchardZSA Fee Considerations ------------------------------ +
+ Click to show/hide We choose to maintain the native ZEC Asset as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem. @@ -761,6 +578,10 @@ An alternative proposal for the OrchardZSA fee mechanism that was not adopted wa In the context of transparent transactions, such a fee allows miners to “tap into” the ZSA value of the transactions, rather than the ZEC value of transactions. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. +.. raw:: html + +
+ Security and Privacy Considerations =================================== @@ -790,11 +611,6 @@ 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 $\mathsf{issuanceSupplyInfoMap}$ from $\mathsf{AssetId}$ to $(\mathsf{totalSupply}, \mathsf{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 --------------- - -The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317, and is described in ZIP 230 [#zip-0230-orchardzsa-fee-calculation]_. - Test Vectors ============ @@ -833,12 +649,12 @@ References .. [#zip-0230-issuance-action-description] `ZIP 230: Version 6 Transaction Format: Issuance Action Description (IssueAction) `_ .. [#zip-0230-issue-note] `ZIP 230: Version 6 Transaction Format: Issue Note (IssueNote) `_ .. [#zip-0230-transaction-format] `ZIP 230: Version 6 Transaction Format: Transaction Format `_ -.. [#zip-0230-orchardzsa-fee-calculation] `ZIP 230: Version 6 Transaction Format: OrchardZSA Fee Calculation `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ -.. [#zip-0244-sigdigest] `ZIP 244: Transaction Identifier Non-Malleability: Signature Digest `_ -.. [#zip-0317-fee-calc] `ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation `_ +.. [#zip-0246] `ZIP 246: Digests for the Version 6 Transaction Format `_ +.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_ +.. [#zip-0317-fee-calculation] `ZIP 317: Proportional Transfer Fee Mechanism - Fee calculation `_ .. [#bip-0043] `BIP 43: Purpose Field for Deterministic Wallets `_ -.. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 `_ +.. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 `_ .. [#protocol-notation] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation `_ .. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.1: Payment Addresses and Keys `_ .. [#protocol-notes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes `_ diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index 21f03babe..ff6dcf59d 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -28,10 +28,6 @@ The terms "Zcash Shielded Asset", "OrchardZSA", "ZSA" and "Asset" in this docume The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 [#zip-0227]_. -We define the following additional terms: - -- Issuance Fee: This is the specific fixed fee that has to be paid to the network for every given issuance action. - The character § is used when referring to sections of the Zcash Protocol Specification [#protocol]_. @@ -39,19 +35,9 @@ The character § is used when referring to sections of the Zcash Protocol Specif Abstract ======== -This proposal defines a new Zcash peer-to-peer transaction format, which includes -data that supports the OrchardZSA protocol and all operations related to Zcash -Shielded Assets (ZSAs). The new format adds and describes new fields containing -ZSA-specific elements. Like the existing v5 transaction format, it keeps well-bounded -regions of the serialized form to serve each pool of funds. - -This ZIP also depends upon and defines modifications to the computation of the values -**TxId Digest**, **Signature Digest**, and **Authorizing Data Commitment** defined by -ZIP 244 [#zip-0244]_. - -This ZIP additionally defines the fee mechanism associated with the Orchard Zcash Shielded Assets (OrchardZSA) protocol -as described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. -The fee mechanism is defined in terms of modifications to the Proportionak Transfer Fee Mechanism [#zip-0317]_. +This proposal defines a new Zcash peer-to-peer transaction format, which supports the +changes being deployed in Network Upgrade 7 [#zip-0254]_. It follows the same design +pattern as the v5 transaction format [#zip-0225]_. Motivation @@ -63,15 +49,6 @@ 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. -The upgrade to the OrchardZSA protocol will also need to define a fee structure consistent with the objectives of ZIP 317 [#zip-0317]_. -This involves adaptation for the transfer protocol [#zip-0226]_, as well as additional considerations for the issuance protocol [#zip-0227]_ such as fees for asset issuance. -Specifically, the OrchardZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. -When it comes to Issuance of ZSA, however, there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. -In the case of Issuance, the computational power needed to verify the bundle is not large. -The transaction size, however, can be an issue as the number of output notes can be large. -Furthermore, as defined in ZIP 227 [#zip-0227]_, there is an additional data structure in the global state that needs to be maintained as part of the consensus. -This motivates further the addition of an Issuance-specific fee. - Requirements ============ @@ -87,14 +64,6 @@ newly incorporated elements except those that attest to transaction validity. The computation of the commitment to authorizing data for a transaction must include all newly incorporated elements that attest to transaction validity. -In addition to the requirements of ZIP 317 [#zip-0317]_, the fee mechanism for the OrchardZSA protocol should satisfy the following requirements: - -* The conventional fee should not leak private information used in - constructing the transaction; that is, it should be computable from only - the public data of the transaction. -* Users should be discouraged from issuing new “garbage” custom Assets. - The fee should reflect the cost of adding new data to the global state. - Non-requirements ================ @@ -113,90 +82,102 @@ The Zcash transaction format for transaction version 6 is as follows: Transaction Format ------------------ -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+====================================+==========================+==================================================+===========================================================================+ -| **Common Transaction Fields** | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``4`` |``header`` |``uint32`` |Contains: | -| | | | * ``fOverwintered`` flag (bit 31, always set) | -| | | | * ``version`` (bits 30 .. 0) – transaction version. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``4`` |``nVersionGroupId`` |``uint32`` |Version group ID (nonzero). | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``4`` |``nConsensusBranchId`` |``uint32`` |Consensus branch ID (nonzero). | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``4`` |``lock_time`` |``uint32`` |Unix-epoch UTC time or block height, encoded as in Bitcoin. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``4`` |``nExpiryHeight`` |``uint32`` |A block height in the range {1 .. 499999999} after which | -| | | |the transaction will expire, or 0 to disable expiry. | -| | | |[ZIP-203] | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``8`` |``fee`` |``int64`` |The fee to be paid by this transaction, in zatoshis. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| **Transparent Transaction Fields** | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``tx_in_count`` |``compactSize`` |Number of transparent inputs in ``tx_in``. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``tx_in`` |``tx_in`` |Transparent inputs, encoded as in Bitcoin. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``tx_out_count`` |``compactSize`` |Number of transparent outputs in ``tx_out``. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``tx_out`` |``tx_out`` |Transparent outputs, encoded as in Bitcoin. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| **Sapling Transaction Fields** | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``nSpendsSapling`` |``compactSize`` |Number of Sapling Spend descriptions in ``vSpendsSapling``. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``96 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV6[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per | -| | | |protocol §7.3 ‘Spend Description Encoding and Consensus’. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``nOutputsSapling`` |``compactSize`` |Number of Sapling Output Decriptions in ``vOutputsSapling``. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``756 * nOutputsSapling`` |``vOutputsSapling`` |``OutputDescriptionV6[nOutputsSapling]`` |A sequence of Sapling Output descriptions, encoded per | -| | | |protocol §7.4 ‘Output Description Encoding and Consensus’. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``8`` |``valueBalanceSapling`` |``int64`` |The net value of Sapling Spends minus Outputs | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``32`` |``anchorSapling`` |``byte[32]`` |A root of the Sapling note commitment tree | -| | | |at some block height in the past. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``192 * nSpendsSapling`` |``vSpendProofsSapling`` |``byte[192 * nSpendsSapling]`` |Encodings of the zk-SNARK proofs for each Sapling Spend. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``64 * nSpendsSapling`` |``vSpendAuthSigsSapling`` |``byte[64 * nSpendsSapling]`` |Authorizing signatures for each Sapling Spend. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``192 * nOutputsSapling`` |``vOutputProofsSapling`` |``byte[192 * nOutputsSapling]`` |Encodings of the zk-SNARK proofs for each Sapling Output. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``64`` |``bindingSigSapling`` |``byte[64]`` |A Sapling binding signature on the SIGHASH transaction hash. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| **OrchardZSA Transaction Fields** | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``nActionGroupsOrchard`` |``compactSize`` |The number of Action Group descriptions in ``vActionGroupsOrchard``. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``vActionGroupsOrchard`` |``ActionGroupDescription[nActionGroupsOrchard]`` |A sequence of Action Group descriptions, encoded as per the | -| | | |`OrchardZSA Action Group Description`_. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``8`` |``valueBalanceOrchard`` |``int64`` |The net value of Orchard spends minus outputs. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| ``varies`` | ``nAssetBurn`` | ``compactSize`` | The number of Assets burnt. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| ``40 * nAssetBurn`` | ``vAssetBurn`` | ``AssetBurn[nAssetBurn]`` | A sequence of Asset Burn descriptions, | -| | | | encoded per `OrchardZSA Asset Burn Description`_. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``64`` |``bindingSigOrchard`` |``byte[64]`` |An OrchardZSA binding signature on the SIGHASH transaction hash. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -| **OrchardZSA Issuance Fields** | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``varies`` |``nIssueActions`` |``compactSize`` |The number of issuance actions in the bundle. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``IssueActionSize * nIssueActions`` |``vIssueActions`` |``IssueAction[nIssueActions]`` |A sequence of issuance action descriptions, where IssueActionSize is | -| | | |the size, in bytes, of an IssueAction description. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``32`` |``ik`` |``byte[32]`` |The issuance validating key of the issuer, used to validate the signature. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ -|``64`` |``issueAuthSig`` |``byte[64]`` |The signature of the transaction SIGHASH, signed by the issuer, | -| | | |validated as in Issuance Authorization Signature Scheme [#zip-0227]_. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------------+ ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| **Common Transaction Fields** | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 4 |``header`` |``uint32`` |Contains: | +| | | | | +| | | |* ``fOverwintered`` flag (bit 31, always set) | +| | | |* ``version`` (bits 30 .. 0) – transaction version. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 4 |``nVersionGroupId`` |``uint32`` |Version group ID (nonzero). | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 4 |``nConsensusBranchId`` |``uint32`` |Consensus branch ID (nonzero). | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 4 |``lock_time`` |``uint32`` |Unix-epoch UTC time or block height, encoded as in Bitcoin. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 4 |``nExpiryHeight`` |``uint32`` |A block height in the range {1 .. 499999999} after which | +| | | |the transaction will expire, or 0 to disable expiry. [#zip-0203]_ | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 8 |``fee`` |``uint64`` |The fee to be paid by this transaction, in zatoshis. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 8 |``burnAmount`` |``uint64`` |The value to be burned in this transaction, in zatoshis. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| **Transparent Transaction Fields** | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``tx_in_count`` |``compactSize`` |Number of transparent inputs in ``tx_in``. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``tx_in`` |``tx_in`` |Transparent inputs, encoded as in Bitcoin. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``tx_out_count`` |``compactSize`` |Number of transparent outputs in ``tx_out``. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``tx_out`` |``tx_out`` |Transparent outputs, encoded as in Bitcoin. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| **Sapling Transaction Fields** | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``nSpendsSapling`` |``compactSize`` |Number of Sapling Spend descriptions in ``vSpendsSapling``. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 96 × ``nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV5[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per | +| | | |protocol §7.3 ‘Spend Description Encoding and Consensus’ | +| | | |(unchanged from V5). | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``nOutputsSapling`` |``compactSize`` |Number of Sapling Output Decriptions in ``vOutputsSapling``. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 276 × ``nOutputsSapling`` |``vOutputsSapling`` |``OutputDescriptionV6[nOutputsSapling]`` |A sequence of Sapling Output descriptions, encoded per | +| | | |protocol §7.4 ‘Output Description Encoding and Consensus’. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 8 |``valueBalanceSapling`` |``int64`` |The net value of Sapling Spends minus Outputs | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``anchorSapling`` |``byte[32]`` |A root of the Sapling note commitment tree | +| | | |at some block height in the past. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 192 × ``nSpendsSapling`` |``vSpendProofsSapling`` |``byte[192 * nSpendsSapling]`` |Encodings of the zk-SNARK proofs for each Sapling Spend. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 64 × ``nSpendsSapling`` |``vSpendAuthSigsSapling`` |``byte[64 * nSpendsSapling]`` |Authorizing signatures for each Sapling Spend. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 192 × ``nOutputsSapling`` |``vOutputProofsSapling`` |``byte[192 * nOutputsSapling]`` |Encodings of the zk-SNARK proofs for each Sapling Output. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 64 |``bindingSigSapling`` |``byte[64]`` |A Sapling binding signature on the SIGHASH transaction hash. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| **Orchard Transaction Fields** | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``nActionGroupsOrchard`` |``compactSize`` |The number of Action Group descriptions in ``vActionGroupsOrchard``. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``vActionGroupsOrchard`` |``ActionGroupDescription[nActionGroupsOrchard]``|A sequence of Action Group descriptions, encoded as per the | +| | | |`OrchardZSA Action Group Description`_. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 8 |``valueBalanceOrchard`` |``int64`` |The net value of Orchard spends minus outputs. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 64 |``bindingSigOrchard`` |``byte[64]`` |An OrchardZSA binding signature on the SIGHASH transaction hash. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| **ZSA Issuance Fields** | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``nIssueActions`` |``compactSize`` |The number of issuance actions in the bundle. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``vIssueActions`` |``IssueAction[nIssueActions]`` |A sequence of issuance action descriptions. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``ik`` |``byte[32]`` |The issuance validating key of the issuer, used to validate the | +| | | |signature. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 64 |``issueAuthSig`` |``byte[64]`` |The signature of the transaction SIGHASH, signed by the issuer, | +| | | |validated as in Issuance Authorization Signature Scheme [#zip-0227]_.| ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| **Memo Bundle Fields** | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 1 |``fAllPruned`` |``uint8`` |1 if all chunks have been pruned, otherwise 0. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``nonceOrHash`` |``byte[32]`` |The nonce for deriving encryption keys, or the overall hash. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``nMemoChunks`` |``compactSize`` |The number of memo chunks. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``pruned`` |``byte[`` |Bitflags indicating the type of each entry in ``vMemoChunks``. | +| | |:math:`\mathsf{ceiling}(\mathtt{nMemoChunks}/8)`| | +| | |``]`` | | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``vMemoChunks`` |``MemoChunk[nMemoChunks]`` |A sequence of encrypted memo chunks. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ * The fields ``valueBalanceSapling`` and ``bindingSigSapling`` are present if and only if @@ -222,91 +203,103 @@ Transaction Format * For coinbase transactions, the ``enableSpendsOrchard`` and ``enableZSAs`` bits MUST be set to $0$. -The encodings of ``tx_in``, and ``tx_out`` are as in a version 4 transaction (i.e. -unchanged from Canopy). The encodings of ``SpendDescriptionV6``, ``OutputDescriptionV6`` -, ``ActionGroupDescription``, ``AssetBurn`` and ``IssueAction`` are described below. -The encoding of Sapling Spends and Outputs has changed relative to prior versions in order -to better separate data that describe the effects of the transaction from the proofs of and -commitments to those effects, and for symmetry with this separation in the Orchard-related parts -of the transaction format. +* The fields ``nMemoChunks``, ``pruned``, and ``vMemoChunks`` are present if and only if + ``fAllPruned == 0``. + +* If ``fAllPruned == 0``, then: -Sapling Spend Description (``SpendDescriptionV6``) --------------------------------------------------- + * ``nonceOrHash`` contains the ZIP 231 nonce for deriving encryption keys. -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=============================+==========================+======================================+============================================================+ -|``32`` |``cv`` |``byte[32]`` |A value commitment to the net value of the input note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``nullifier`` |``byte[32]`` |The nullifier of the input note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``rk`` |``byte[32]`` |The randomized validating key for the element of | -| | | |spendAuthSigsSapling corresponding to this Spend. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ + * Each bit of ``pruned``, in little-endian order, indicates the type of the corresponding + entry in ``vMemoChunks``. -The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding -and Consensus’ of the Zcash Protocol Specification [#protocol-spenddesc]_. + * A bit value of 0 indicates that the entry will be of type ``byte[272]`` representing an + encrypted memo chunk. + + * A bit value of 1 indicates the entry will be a ``byte[32]`` and contains the ZIP 246 + ``memo_chunk_digest`` for a pruned chunk. + +* If ``fAllPruned == 1``, then: + + * ``nonceOrHash`` contains the ZIP 246 ``memo_digest`` for the pruned memo bundle. + +The encodings of ``tx_in``, and ``tx_out`` are as in a version 4 transaction (i.e. +unchanged from Canopy). The encodings of ``SpendDescriptionV6``, ``OutputDescriptionV6`` +, ``ActionGroupDescription``, ``AssetBurn`` and ``IssueAction`` are described below. +The encoding of Sapling Spends and Outputs has changed relative to prior versions in order +to better separate data that describe the effects of the transaction from the proofs of and +commitments to those effects, and for symmetry with this separation in the Orchard-related parts +of the transaction format. Sapling Output Description (``OutputDescriptionV6``) ---------------------------------------------------- -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=============================+==========================+======================================+============================================================+ -|``32`` |``cv`` |``byte[32]`` |A value commitment to the net value of the output note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``cmu`` |``byte[32]`` |The :math:`u\!`-coordinate of the note commitment for the | -| | | |output note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``ephemeralKey`` |``byte[32]`` |An encoding of an ephemeral Jubjub public key. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``80`` |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by | -| | | |concatenation of the transmission key with the ephemeral | -| | | |secret key. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| 32 |``cv`` |``byte[32]`` |A value commitment to the net value of the output note. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``cmu`` |``byte[32]`` |The :math:`u\!`-coordinate of the note commitment for the output | +| | | |note. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``ephemeralKey`` |``byte[32]`` |An encoding of an ephemeral Jubjub public key. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 100 |``encCiphertext`` |``byte[100]`` |The encrypted contents of the note plaintext. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 80 |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by concatenation | +| | | |of the transmission key with the ephemeral secret key. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification [#protocol-outputdesc]_. -OrchardZSA Action Group Description +OrchardZSA Action Group Description ----------------------------------- The OrchardZSA Action Group Description is encoded in a transaction as an instance of an ``ActionGroupDescription`` type: -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+====================================+==========================+==================================================+=====================================================================+ -|``varies`` |``nActionsOrchard`` |``compactSize`` |The number of Action descriptions in ``vActionsOrchard``. | -| | | |This MUST have a value strictly greater than ``0``. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``852 * nActionsOrchard`` |``vActionsOrchard`` |``OrchardZSAAction[nActionsOrchard]`` |A sequence of OrchardZSA Action descriptions in the Action Group. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``1`` |``flagsOrchard`` |``byte`` |As defined in Section 7.1 of the Protocol | -| | | |Specification [#protocol-txnencoding]_. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``32`` |``anchorOrchard`` |``byte[32]`` |As defined in Section 7.1 of the Protocol | -| | | |Specification [#protocol-txnencoding]_. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``varies`` |``sizeProofsOrchard`` |``compactSize`` |As defined in Section 7.1 of the Protocol | -| | | |Specification [#protocol-txnencoding]_. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``sizeProofsOrchard`` |``proofsOrchard`` |``byte[sizeProofsOrchard]`` |The aggregated zk-SNARK proof for all Actions in the Action Group. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``4`` |``nAGExpiryHeight`` |``uint32`` |A block height (in the future) after which the Actions of the | -| | | |Action Group become invalid and should be rejected by consensus. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ -|``64 * nActionsOrchard`` |``vSpendAuthSigsOrchard`` |``byte[64 * nActionsOrchard]`` |Authorizing signatures for each Action of the Action Group in a | -| | | |transaction. | -+------------------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+ - -The encoding of ``OrchardZSAAction`` is described below. ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| varies |``nActionsOrchard`` |``compactSize`` |The number of Action descriptions in ``vActionsOrchard``. | +| | | |This MUST have a value strictly greater than ``0``. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 372 × ``nActionsOrchard`` |``vActionsOrchard`` |``OrchardZSAAction[nActionsOrchard]`` |A sequence of OrchardZSA Action descriptions in the Action Group. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 1 |``flagsOrchard`` |``byte`` |As defined in Section 7.1 of the Protocol Specification | +| | | |[#protocol-txnencoding]_. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``anchorOrchard`` |``byte[32]`` |As defined in Section 7.1 of the Protocol Specification | +| | | |[#protocol-txnencoding]_. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 4 |``nAGExpiryHeight`` |``uint32`` |A block height in the range {1 .. 499999999} after which any | +| | | |transaction including this Action Group cannot be mined, or 0 if | +| | | |this Action Group places no constraint on transaction expiry. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies | ``nAssetBurn`` | ``compactSize`` |The number of Assets burnt. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 40 × ``nAssetBurn`` | ``vAssetBurn`` | ``AssetBurn[nAssetBurn]`` |A sequence of Asset Burn descriptions, encoded per | +| | | | encoded per `OrchardZSA Asset Burn Description`_. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``sizeProofsOrchard`` |``compactSize`` |As defined in Section 7.1 of the Protocol Specification | +| | | |[#protocol-txnencoding]_. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| ``sizeProofsOrchard`` |``proofsOrchard`` |``byte[sizeProofsOrchard]`` |The aggregated zk-SNARK proof for all Actions in the Action Group. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 64 × ``nActionsOrchard`` |``vSpendAuthSigsOrchard`` |``byte[64 * nActionsOrchard]`` |Authorizing signatures for each Action of the Action Group in a | +| | | |transaction. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ + +The encodings of ``OrchardZSAAction`` and ``AssetBurn`` are described below. * The proofs aggregated in ``proofsOrchardZSA``, and the elements of ``vSpendAuthSigsOrchard``, each have a 1:1 correspondence to the elements of ``vActionsOrchard`` and MUST be ordered such that the proof or signature at a given index corresponds to the ``OrchardZSAAction`` at the same index. +* If thee value of ``nAGExpiryHeight`` is nonzero, it MUST be consistent with + the ``nExpiryHeight`` of the overall transaction. +* In NU7, ``nExpiryHeight`` MUST be set to ``0``; this restriction is expected + to be lifted in a future network upgrade. Rationale for nAGExpiryHeight ````````````````````````````` @@ -315,31 +308,39 @@ We introduce the ``nAGExpiryHeight`` field in this transaction format in order t For the OrchardZSA protocol, which does not make use of an additional expiry height for transactions, we set the value of ``nAGExpiryHeight`` to be ``0`` by consensus. This serves as a default value to represent the situation where there is no expiry, analogous to the convention adopted for ``nExpiryHeight`` in ZIP 203 [#zip-0203]. +Rationale for including Burn fields inside OrchardZSA Action Groups +``````````````````````````````````````````````````````````````````` + +Note that the V6 transaction format includes the burn fields of the transaction inside the OrchardZSA Action Group rather than at the transaction level. +This is a design choice that considers the future scenario where Action Groups may be generated by different parties before being bundled together into a transaction. +In such a scenario, the individual parties can burn Assets of their choice in their corresponding Action Groups. +Maintaining the burn fields at the transaction level would provide the ability to burn Assets only to the party performing the bundling of the Action Groups. + + OrchardZSA Action Description (``OrchardZSAAction``) ---------------------------------------------------- -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=============================+==========================+======================================+============================================================+ -|``32`` |``cv`` |``byte[32]`` |A value commitment to the net value of the input note minus | -| | | |the output note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``nullifier`` |``byte[32]`` |The nullifier of the input note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``rk`` |``byte[32]`` |The randomized validating key for the element of | -| | | |spendAuthSigsOrchard corresponding to this Action. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``cmx`` |``byte[32]`` |The :math:`x\!`-coordinate of the note commitment for the | -| | | |output note. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``32`` |``ephemeralKey`` |``byte[32]`` |An encoding of an ephemeral Pallas public key. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``612`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``80`` |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by | -| | | |concatenation of the transmission key with the ephemeral | -| | | |secret key. | -+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| 32 |``cv`` |``byte[32]`` |A value commitment to the net value of the input note minus the | +| | | |output note. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``nullifier`` |``byte[32]`` |The nullifier of the input note. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``rk`` |``byte[32]`` |The randomized validating key for the element of | +| | | |``spendAuthSigsOrchard`` corresponding to this Action. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``cmx`` |``byte[32]`` |The :math:`x\!`-coordinate of the note commitment for the output | +| | | |note. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``ephemeralKey`` |``byte[32]`` |An encoding of an ephemeral Pallas public key. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 132 |``encCiphertext`` |``byte[132]`` |The encrypted contents of the note plaintext. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 80 |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by concatenation | +| | | |of the transmission key with the ephemeral secret key. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification [#protocol-actiondesc]_. @@ -349,13 +350,15 @@ OrchardZSA Asset Burn Description An OrchardZSA Asset Burn description is encoded in a transaction as an instance of an ``AssetBurn`` type: -+-------+---------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=======+===============+=============================+====================================================================================================================+ -| 32 | ``AssetBase`` | ``byte[32]`` | For the OrchardZSA protocol, this is the encoding of the Asset Base :math:`\mathsf{AssetBase^{Orchard}}\!`. | -+-------+---------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------+ -| 8 | ``valueBurn`` | ``uint64`` | The amount being burnt. The value is checked by consensus to be non-zero. | -+-------+---------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------+ ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| 32 |``AssetBase`` |``byte[32]`` |For the OrchardZSA protocol, this is the encoding of the Asset Base | +| | | |:math:`\mathsf{AssetBase^{Orchard}}\!`. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 8 |``valueBurn`` |``uint64`` |The amount being burnt. The value is checked by consensus to be | +| | | |non-zero. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ The encodings of each of these elements are defined in ZIP 226 [#zip-0226]_. @@ -364,52 +367,50 @@ Issuance Action Description (``IssueAction``) An issuance action, ``IssueAction``, is the instance of issuing a specific Custom Asset, and contains the following fields: -+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=============================+==========================+===========================================+=====================================================================+ -|``32`` |``assetDescHash`` |``byte[32]`` |A hash of the description of the Custom Asset. | -+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+ -|``varies`` |``nNotes`` |``compactSize`` |The number of notes in the Issuance Action. | -+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+ -|``147 * nNotes`` |``vNotes`` |``IssueNote[nNotes]`` |A sequence of note descriptions within the Issuance Action. | -+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+ -|``1`` |``flagsIssuance`` |``byte`` |An 8-bit value representing a set of flags. Ordered from LSB to MSB: | -| | | | * :math:`\mathsf{finalize}` | -| | | | * The remaining bits are set to :math:`0\!`. | -+-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+ ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| 32 |``assetDescHash`` |``byte[32]`` |A hash of the description of the Custom Asset. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| varies |``nNotes`` |``compactSize`` |The number of notes in the Issuance Action. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 147 × ``nNotes`` |``vNotes`` |``IssueNote[nNotes]`` |A sequence of note descriptions within the Issuance Action. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 1 |``flagsIssuance`` |``byte`` |An 8-bit value representing a set of flags. Ordered from LSB to MSB: | +| | | | | +| | | |* :math:`\mathsf{finalize}` | +| | | |* The remaining bits are set to :math:`0\!`. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ The encoding of ``IssueNote`` is described below. -Note that we allow the number of notes (represented by ``nNotes``) to be zero. -This allows for issuers to create Issuance Actions to only finalize an issued Asset, without needing them to simultaneously issue more of that Asset. +Note that we allow the number of notes (represented by ``nNotes``) to be zero. +This allows for issuers to create Issuance Actions to only finalize an issued Asset, without needing them to simultaneously issue more of that Asset. Issue Note Description (``IssueNote``) -------------------------------------- An issuance note, ``IssueNote`` contains the following fields: -+-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=============================+==========================+======================================+====================================================================+ -|``43`` |``recipient`` |``byte[43]`` |The encoding of a recipient's diversified payment address, as | -| | | |:math:`\mathsf{LEBS2OSP}_{88}(\mathsf{d})\| | -| | | |\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}} | -| | | |(\mathsf{pk}_\mathsf{d}))\!`, where :math:`\mathsf{d}` is the | -| | | |diversifier and :math:`\mathsf{pk_d}` is the diversified | -| | | |transmission key. **Non Normative Note**: This is the same as the | -| | | |encoding of an Orchard Raw Payment Address, as defined in the | -| | | |protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’. | -+-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ -|``8`` |``value`` |``uint64`` |The amount being issued in this note. | -+-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ -|``32`` |``assetBase`` |``byte[32]`` |The encoding of the Asset Base | -| | | |:math:`\mathsf{AssetBase^{Orchard}}\!`, as defined in 'ZIP 227'. | -+-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ -|``32`` |``rho`` |``byte[32]`` |This is defined and encoded in the same manner as for Orchard | -| | | |notes in protocol §3.2.1 'Note Plaintexts and Memo Fields'. | -+-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ -|``32`` |``rseed`` |``byte[32]`` |The ``rseed`` field of the note, encoded as for Orchard notes in | -| | | |protocol §3.2.1 'Note Plaintexts and Memo Fields'. | -+-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| Bytes | Name | Data Type | Description | ++=============================+==============================+================================================+=====================================================================+ +| 43 |``recipient`` |``byte[43]`` |The encoding of a recipient's diversified payment address, as | +| | | |:math:`\mathsf{LEBS2OSP}_{88}(\mathsf{d})\| | +| | | |\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}} | +| | | |(\mathsf{pk}_\mathsf{d}))\!`, where :math:`\mathsf{d}` is the | +| | | |diversifier and :math:`\mathsf{pk_d}` is the diversified | +| | | |transmission key. **Non Normative Note**: This is the same as the | +| | | |encoding of an Orchard Raw Payment Address, as defined in the | +| | | |protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 8 |``value`` |``uint64`` |The amount being issued in this note. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``rho`` |``byte[32]`` |This is defined and encoded in the same manner as for Orchard notes | +| | | |in protocol §3.2.1 'Note Plaintexts and Memo Fields'. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ +| 32 |``rseed`` |``byte[32]`` |The ``rseed`` field of the note, encoded as for Orchard notes in | +| | | |protocol §3.2.1 'Note Plaintexts and Memo Fields'. | ++-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+ Deployment @@ -435,10 +436,9 @@ References .. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.6: Action Descriptions `_ .. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0203] `ZIP 203: Transaction Expiry `_ +.. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0228] `ZIP 228: Asset Swaps for Zcash Shielded Assets `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0254] `ZIP 254: Deployment of the NU7 Network Upgrade `_ -.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_ -.. [#zip-0317-fee-calc] `ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation `_ diff --git a/zips/zip-0231.md b/zips/zip-0231.md index 2853cad32..a859da019 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -284,13 +284,12 @@ where all memo chunks in a transaction have been pruned. TODO: finish this to be a modification to the equivalent of ZIP 244 for transaction v6. -## Transaction fees +## Changes to ZIP 317 [^zip-0317] -(This section will become a modification to ZIP 317.) - -A memo bundle may contain two free chunks if there are any shielded outputs in -the transaction. Otherwise, each memo chunk requires `marginal_fee` as defined -in ZIP 317 [^zip-0317]. +The conventional fee in ZEC is altered such that a memo bundle may contain two +free chunks if there are any shielded outputs in the transaction. Any memo chunk +beyond this requires `marginal_fee`. See the Fee calculation section of ZIP 317 +[^zip-0317-fee-calculation] for details. ## Network protocol @@ -532,23 +531,6 @@ chunks within specific transactions, however shielded transactions do not reveal their senders, recipients, or amounts, and thus also cannot be individually targeted for censorship. -## Transaction fees - -Making the fee linear in the number of chunks has the following properties: - -- The required fee to add more memo chunks scales at the same rate as adding - logical actions, so it isn't a cheaper mechanism for an adversary to bloat - chain size. -- A "baseline transaction" (one spent note, one output to an external recipient - with a memo, one change output without a memo) has the same fee as before. -- A "broadcast transaction" (many outputs to different recipients all given the - same memo) is the same fee as before (but a smaller transaction). -- A "many memos transaction" (many outputs to different recipients all with - unique memos) is at most around twice the fee as before. - -Combined with the memo bundle size restriction, the maximum additional fee for -a memo bundle over prior transactions is 0.0019 ZEC. - # Deployment @@ -596,6 +578,8 @@ TBD [^zip-0317]: [ZIP 317: Proportional Transfer Fee Mechanism](zip-0317.rst) +[^zip-0317-fee-calculation]: [ZIP 317: Proportional Transfer Fee Mechanism - Fee calculation](zip-0317.rst#fee-calculation) + [^stream]: [Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance](https://eprint.iacr.org/2015/189) [^pczt]: [zcash/zips issue #693: Standardize a protocol for creating shielded transactions offline](https://github.com/zcash/zips/issues/693) diff --git a/zips/zip-0246.rst b/zips/zip-0246.rst new file mode 100644 index 000000000..dc89efa8a --- /dev/null +++ b/zips/zip-0246.rst @@ -0,0 +1,569 @@ +:: + + ZIP: 246 + Title: Digests for the Version 6 Transaction Format + Owners: Arya + Conrado Gouvea + Daira-Emma Hopwood + Jack Grigg + Kris Nuttycombe + Status: Draft + Category: Consensus + Created: 2025-02-12 + License: MIT + + +=========== +Terminology +=========== + +The key words "MUST" and "MUST NOT" in this document are to be interpreted as described +in BCP 14 [#BCP14]_ when, and only when, they appear in all capitals. + +The terms "consensus branch", "epoch", and "network upgrade" in this document are to be +interpreted as described in ZIP 200. [#zip-0200]_ + +The term "field encoding" refers to the binary serialized form of a Zcash transaction +field, as specified in section 7.1 of the Zcash protocol specification +[#protocol-txnencoding]_. + + +======== +Abstract +======== + +This ZIP defines the digest algorithms associated with the v6 transaction format. + +This proposal also defines the new concept of "sighash versioning": where previously +each transaction version had a single associated digest algorithm, going forward it +will be possible for signers to use any digest algorithm within the closed set +specified for a given transaction version (and made available in consensus via network +upgrades). + + +========== +Motivation +========== + +TBD + +TODO: Motivate sighash versioning + + +============ +Requirements +============ + +- Continue to support existing functionality of the protocol (multisig, + signing modes for transparent inputs). + +- It should be possible to update this ZIP with additional digest versions after the first + version has been deployed in a network upgrade. + + +================ +Non-requirements +================ + +TBD + + +============= +Specification +============= + +------------------ +Sighash versioning +------------------ + +Rough summary: + +- Sighash versions are numbered starting from 0 for each tx version. +- v0 is by convention the "commit to everything" sighash digest. Other versions can commit to whatever makes sense for desired functionality within that tx version. +- Have a single byte encoded alongside the signature (not appended the way transparent does) that permits the signer to specify which sighash version they are using. +- Consensus rules choose the digest algorithm for each signer based on that byte. + +---------- +v0 Digests +---------- + +The v0 digests are based on the v5 transaction digest algorithm defined in ZIP 244 [#zip-0244]_. + +TxId Digest +=========== + +The overall structure of the TxID digest is as follows; each name referenced here will either be +referenced or described in detail below:: + + txid_digest + ├── header_digest * + ├── transparent_digest + │   ├── prevouts_digest + │   ├── sequence_digest + │   └── outputs_digest + ├── sapling_digest + │   ├── sapling_spends_digest + │   │   ├── sapling_spends_compact_digest + │   │   └── sapling_spends_noncompact_digest + │   ├── sapling_outputs_digest * + │   │   ├── sapling_outputs_compact_digest * + │   │   └── sapling_outputs_noncompact_digest * + │   └── valueBalance + ├── orchard_digest * + │   ├── orchard_action_groups_digest * + │   │   ├── orchard_actions_compact_digest * + │   │   ├── orchard_actions_noncompact_digest * + │   │   ├── flagsOrchard + │   │   ├── anchorOrchard + │   │   ├── nAGExpiryHeight * + │   │   └── orchard_burn_digest * + │   └── valueBalanceOrchard + ├── issuance_digest * + │   ├── issue_actions_digest * + │   │   ├── issue_notes_digest * + │   │   ├── assetDescHash * + │   │   └── flagsIssuance * + │   └── issuanceValidatingKey * + └── memo_digest * +    ├── nonce * +    └── memo_chunks_digest * +       └── memo_chunk_digest * + +Each node written as ``snake_case`` in this tree is a BLAKE2b-256 hash of its +children, initialized with a personalization string specific to that branch +of the tree. Nodes that are not themselves digests are written in ``camelCase``. +In the specification below, nodes of the tree are presented in depth-first order. + +The nodes with a ``*`` have new definitions given below. All other nodes have the +same definition as in ZIP 244 [#zip-0244]_. + +txid_digest +----------- +A BLAKE2b-256 hash of the following values :: + + T.1: header_digest (32-byte hash output) + T.2: transparent_digest (32-byte hash output) + T.3: sapling_digest (32-byte hash output) + T.4: orchard_digest (32-byte hash output) + T.5: issuance_digest (32-byte hash output) + T.6: memo_digest (32-byte hash output) + +The personalization field of this hash is set to:: + + "ZcashTxHash_" || CONSENSUS_BRANCH_ID + +``ZcashTxHash_`` has 1 underscore character. + +As in ZIP 244 [#zip-0244]_, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of +the consensus branch ID for the epoch of the block containing the transaction. + +T.1: header_digest +`````````````````` +A BLAKE2b-256 hash of the following values :: + + T.1a: version (4-byte little-endian version identifier including overwinter flag) + T.1b: version_group_id (4-byte little-endian version group identifier) + T.1c: consensus_branch_id (4-byte little-endian consensus branch id) + T.1d: lock_time (4-byte little-endian nLockTime value) + T.1e: expiry_height (4-byte little-endian block height) + T.1f: fee (8-byte little-endian fee amount) + T.1g: burn_amount (8-byte little-endian burn amount) + +The personalization field of this hash is set to:: + + "ZTxIdHeadersHash" + +T.3b: sapling_outputs_digest +'''''''''''''''''''''''''''' +In the case that Sapling outputs are present, this digest is a BLAKE2b-256 hash of the +following values :: + + T.3b.i: sapling_outputs_compact_digest (32-byte hash) + T.3b.ii: sapling_outputs_noncompact_digest (32-byte hash) + +The personalization field of this hash is set to:: + + "ZTxIdSOutputHash" + +In the case that the transaction has Sapling spends but no Sapling outputs, +``sapling_outputs_digest`` is :: + + BLAKE2b-256("ZTxIdSOutputHash", []) + +T.3b.i: sapling_outputs_compact_digest +...................................... +A BLAKE2b-256 hash of the subset of Sapling output information included in the +ZIP-307 [#zip-0307]_ ``CompactBlock`` format for all Sapling shielded outputs +belonging to the transaction. For each output, the following elements are included +in the hash:: + + T.3b.i.1: cmu (field encoding bytes) + T.3b.i.2: ephemeral_key (field encoding bytes) + T.3b.i.3: enc_ciphertext (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxId6SOutC_Hash" (1 underscore character) + +The field encodings are specified in ZIP 230 [#zip-0230-sapling-output-field-encodings]_. + +T.3b.ii: sapling_outputs_noncompact_digest +........................................... +A BLAKE2b-256 hash of the remaining subset of Sapling output information **not** included +in the ZIP 307 [#zip-0307]_ ``CompactBlock`` format, excluding zkproof data, for all +Sapling shielded outputs belonging to the transaction. For each output, the following +elements are included in the hash:: + + T.3b.ii.1: cv (field encoding bytes) + T.3b.ii.3: out_ciphertext (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxId6SOutN_Hash" (1 underscore character) + +The field encodings are specified in ZIP 230 [#zip-0230-sapling-output-field-encodings]_. + +T.4: orchard_digest +``````````````````` +When OrchardZSA Actions Groups are present in the transaction, this digest is a BLAKE2b-256 hash of the following values:: + + T.4a: orchard_action_groups_digest (32-byte hash output) + T.4b: valueBalanceOrchard (64-bit signed little-endian) + +The personalization field of this hash is set to:: + + "ZTxIdOrchardHash" + +In the case that the transaction has no OrchardZSA Action Groups, ``orchard_digest`` is :: + + BLAKE2b-256("ZTxIdOrchardHash", []) + +T.4a: orchard_action_groups_digest +'''''''''''''''''''''''''''''''''' + +A BLAKE2b-256 hash of the subset of OrchardZSA Action Groups information for all OrchardZSA Action Groups belonging to the transaction. +For each Action Group, the following elements are included in the hash:: + + T.4a.i : orchard_actions_compact_digest (32-byte hash output) + T.4a.ii : orchard_actions_noncompact_digest (32-byte hash output) + T.4a.iii : flagsOrchard (1 byte) + T.4a.iv : anchorOrchard (32 bytes) + T.4a.v : nAGExpiryHeight (4 bytes) + T.4a.vi : orchard_burn_digest (32-byte hash output) + +The personalization field of this hash is set to:: + + "ZTxIdOrcActGHash" + +T.4a.i: orchard_actions_compact_digest +...................................... + +A BLAKE2b-256 hash of the subset of OrchardZSA Action information intended to be included in +an updated version of the ZIP-307 [#zip-0307]_ ``CompactBlock`` format for all OrchardZSA +Actions belonging to the Action Group. For each Action, the following elements are included +in the hash:: + + T.4a.i.1 : nullifier (field encoding bytes) + T.4a.i.2 : cmx (field encoding bytes) + T.4a.i.3 : ephemeralKey (field encoding bytes) + T.4a.i.4 : encCiphertext (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxId6OActC_Hash" (1 underscore character) + +The field encodings are specified in ZIP 230 [#zip-0230-orchard-action-field-encodings]_. + +T.4a.ii: orchard_actions_noncompact_digest +.......................................... + +A BLAKE2b-256 hash of the remaining subset of OrchardZSA Action information **not** intended +for inclusion in an updated version of the the ZIP 307 [#zip-0307]_ ``CompactBlock`` +format, for all OrchardZSA Actions belonging to the Action Group. For each Action, +the following elements are included in the hash:: + + T.4a.ii.1 : cv (field encoding bytes) + T.4a.ii.2 : rk (field encoding bytes) + T.4a.ii.3 : outCiphertext (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxId6OActN_Hash" (1 underscore character) + +The field encodings are specified in ZIP 230 [#zip-0230-orchard-action-field-encodings]_. + + +T.4a.vi: orchard_burn_digest +'''''''''''''''''''''''''''' + +A BLAKE2b-256 hash of the data from the burn fields of the transaction. For each tuple in +the $\mathsf{assetBurn}$ set, the following elements are included in the hash:: + + T.4b.i : assetBase (field encoding bytes) + T.4b.ii: valueBurn (64-bit unsigned little-endian) + +The personalization field of this hash is set to:: + + "ZTxIdOrcBurnHash" + +In case the transaction does not perform the burning of any Assets (i.e. the +$\mathsf{assetBurn}$ set is empty), the ``orchard_burn_digest`` is:: + + BLAKE2b-256("ZTxIdOrcBurnHash", []) + +The field encodings are specified in ZIP 230 [#zip-0230-orchard-asset-burn-field-encodings]_. + + +T.5: issuance_digest +```````````````````` +A BLAKE2b-256 hash of the following values :: + + T.5a: issue_actions_digest (32-byte hash output) + T.5b: issuanceValidatingKey (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxIdSAIssueHash" + +In case the transaction has no issuance components, ``issuance_digest`` is:: + + BLAKE2b-256("ZTxIdSAIssueHash", []) + +The field encodings are specified in ZIP 230 [#zip-0230-transaction-field-encodings]_. + +T.5a: 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.5a.i : notes_digest (32-byte hash output) + T.5a.ii : assetDescHash (field encoding bytes) + T.5a.iii: flagsIssuance (1 byte) + +The personalization field of this hash is set to:: + + "ZTxIdIssuActHash" + +The field encodings are specified in ZIP 230 [#zip-0230-issue-actions-field-encodings]_. + +T.5a.i: issue_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.5a.i.1: recipient (field encoding bytes) + T.5a.i.2: value (field encoding bytes) + T.5a.i.3: rho (field encoding bytes) + T.5a.i.4: rseed (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxIdIAcNoteHash" + +In case the transaction has no Issue Notes, ``issue_notes_digest`` is:: + + BLAKE2b-256("ZTxIdIAcNoteHash", []) + +The field encodings are specified in ZIP 230 [#zip-0230-issue-notes-field-encodings]_. + +T.6: memo_digest +```````````````` +A BLAKE2b-256 hash of the following values :: + + T.6a: nonce (field encoding bytes) + T.6b: memo_chunks_digest (32-byte hash output) + +The personalization field of this hash is set to:: + + "ZTxIdMemo___Hash" (3 underscore characters) + +In case the transaction has no memo chunks, ``memo_digest`` is:: + + BLAKE2b-256("ZTxIdMemo___Hash", []) + +The field encodings are specified in ZIP 230 [#zip-0230-transaction-field-encodings]_. + +T.6b: memo_chunks_digest +'''''''''''''''''''''''' +A BLAKE2b-256 hash of the concatenated ``memo_chunk_digest`` values of all memo chunks +within the memo bundle. + +The personalization field of this hash is set to:: + + "ZTxIdMemoCksHash" + +In the case that the transaction has transparent inputs but no transparent outputs, +``outputs_digest`` is :: + + BLAKE2b-256("ZTxIdMemoCksHash", []) + +T.6b.i: memo_chunk_digest +......................... +A BLAKE2b-256 hash of the field encoding of a single encrypted Memo Chunk. + +The personalization field of this hash is set to:: + + "ZTxIdMemoCk_Hash" (1 underscore character) + +The field encodings are specified in ZIP 230 [#zip-0230-issue-actions-field-encodings]_. + + +Signature Digest +================ + +The per-input transaction digest algorithm to generate the signature digest in ZIP 244 [#zip-0244-sigdigest]_ is modified so that a signature digest is produced for each transparent input, each Sapling input, each OrchardZSA Action, and additionally for each Issuance Action. +The modifications replace the ``orchard_digest`` in ZIP 244 with a new ``orchard_digest``, and add a new branch, ``issuance_digest``, for the Issuance Action information. + +The overall structure of the hash is as follows. We omit the descriptions of the sections that do not change for the OrchardZSA protocol:: + + signature_digest + ├── header_digest + ├── transparent_sig_digest + ├── sapling_digest + ├── orchard_digest + ├── issuance_digest + └── memo_digest + +signature_digest +---------------- +A BLAKE2b-256 hash of the following values :: + + S.1: header_digest (32-byte hash output) + S.2: transparent_sig_digest (32-byte hash output) + S.3: sapling_digest (32-byte hash output) + S.4: orchard_digest (32-byte hash output) + S.5: issuance_digest (32-byte hash output) + S.6: memo_digest (32-byte hash output) + +The personalization field remains the same as in ZIP 244 [#zip-0244]_, namely:: + + "ZcashTxHash_" || CONSENSUS_BRANCH_ID + +``ZcashTxHash_`` has 1 underscore character. + +S.4: orchard_digest +``````````````````` +Identical to that specified for the transaction identifier. + +S.5: issuance_digest +```````````````````` +Identical to the ``issuance_digest`` specified for the transaction identifier in ZIP 227 [zip-0227-txiddigest]_. + +S.6: memo_digest +```````````````` +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 OrchardZSA protocol to have the structure specified in this section. +There is a new branch added for issuance information, and the ``orchard_auth_digest`` in ZIP 244 is replaced with ``orchard_auth_digest`` to account for the presence of Action Groups. + +We omit the descriptions of the sections that do not change for the OrchardZSA protocol:: + + auth_digest + ├── transparent_scripts_digest + ├── sapling_auth_digest + ├── orchard_auth_digest + └── issuance_auth_digest + +The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block. + +auth_digest +----------- +A BLAKE2b-256 hash of the following values :: + + A.1: transparent_scripts_digest (32-byte hash output) + A.2: sapling_auth_digest (32-byte hash output) + A.3: orchard_auth_digest (32-byte hash output) + A.4: issuance_auth_digest (32-byte hash output) + +The personalization field of this hash remains the same as in ZIP 244. + + +A.3: orchard_auth_digest +```````````````````````` + +In the case that OrchardZSA Action Groups are present, this is a BLAKE2b-256 hash of the following values:: + + A.3a: orchard_action_groups_auth_digest (32-byte hash output) + A.3b: bindingSigOrchard (field encoding bytes) + +The personalization field of this hash is the same as in ZIP 244, that is:: + + "ZTxAuthOrchaHash" + +In case that the transaction has no OrchardZSA Action Groups, ``orchard_auth_digest`` is:: + + BLAKE2b-256("ZTxAuthOrchaHash", []) + +The field encodings are specified in ZIP 230 [#zip-0230-transaction-field-encodings]_. + +A.3a: orchard_action_groups_auth_digest +''''''''''''''''''''''''''''''''''''''' + +This is a BLAKE2b-256 hash of the ``proofsOrchard`` field of all OrchardZSA Action Groups belonging to the transaction; followed by the ``spendAuthSigsOrchard`` fields corresponding to every OrchardZSA Action in the OrchardZSA Action Group, for all OrchardZSA Action Groups belonging to the transaction:: + + A.3a.i: proofsOrchard (field encoding bytes) + A.3a.ii: spendAuthSigsOrchard (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxAuthOrcAGHash" + +The field encodings are specified in ZIP 230 [#zip-0230-orchard-action-group-field-encodings]_. + +A.4: issuance_auth_digest +------------------------- + +In the case that Issuance Actions are present, this is a BLAKE2b-256 hash of the field encoding of the ``issueAuthSig`` field of the transaction:: + + A.4a: issueAuthSig (field encoding bytes) + +The personalization field of this hash is set to:: + + "ZTxAuthZSAOrHash" + +In the case that the transaction has no Orchard Actions, ``issuance_auth_digest`` is :: + + BLAKE2b-256("ZTxAuthZSAOrHash", []) + +The field encodings are specified in ZIP 230 [#zip-0230-transaction-field-encodings]_. + + +========= +Rationale +========= + +TBD + + +======================== +Reference implementation +======================== + +TBD + + +========== +References +========== + +.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_ +.. [#protocol] `Zcash Protocol Specification, Version 2024.5.1 or later [NU6] `_ +.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.4: Spend Descriptions `_ +.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.5: Output Descriptions `_ +.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.6: Action Descriptions `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TODO (issuance digest anchor missing) `_ +.. [#zip-0230-transaction-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Transaction Format `_ +.. [#zip-0230-orchard-action-group-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Action Group Description `_ +.. [#zip-0230-orchard-action-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Action Description `_ +.. [#zip-0230-orchard-asset-burn-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Asset Burn Description `_ +.. [#zip-0230-sapling-output-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Sapling Output Description (OutputDescriptionV6) `_ +.. [#zip-0230-issue-actions-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issuance Action Description `_ +.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description `_ +.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ +.. [#zip-0244-sigdigest] `ZIP 244: Transaction Identifier Non-Malleability: Signature Digest `_ +.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment `_ +.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index d60facef5..7a8a21437 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -78,6 +78,8 @@ Requirements * The conventional fee should not leak private information used in constructing the transaction; that is, it should be computable from only the public data of the transaction. +* Users should be discouraged from issuing new “garbage” Custom Assets. + The fee should reflect the cost of adding new data to the global state. Specification @@ -108,6 +110,7 @@ Parameter Value Units :math:`grace\_actions` :math:`2` logical actions :math:`p2pkh\_standard\_input\_size` :math:`150` bytes :math:`p2pkh\_standard\_output\_size` :math:`34` bytes +:math:`creation\_cost` :math:`100` logical actions ===================================== ============= ============================================== Wallets implementing this specification SHOULD use a conventional fee @@ -115,18 +118,29 @@ calculated in zatoshis per the following formula: .. math:: - \begin{array}{rcl} - contribution_{\,\mathsf{Transparent}} &=& - \mathsf{max}\big(\mathsf{ceiling}\big(\frac{tx\_in\_total\_size}{p2pkh\_standard\_input\_size}\big),\, - \mathsf{ceiling}\big(\frac{tx\_out\_total\_size}{p2pkh\_standard\_output\_size}\big)\big) \\ - contribution_{\,\rlap{\mathsf{Sprout}}\phantom{\mathsf{Transparent}}} &=& 2 \cdot nJoinSplit \\ - contribution_{\,\rlap{\mathsf{Sapling}}\phantom{\mathsf{Transparent}}} &=& \mathsf{max}(nSpendsSapling,\, nOutputsSapling) \\ - contribution_{\,\rlap{\mathsf{Orchard}}\phantom{\mathsf{Transparent}}} &=& nActionsOrchard \\ + \begin{array}{lcl} + free\_memo\_chunks &=& \begin{cases} + 2, &\!\!\text{if } nOutputsSapling + nActionsOrchard > 0, \\ + 0, &\!\!\text{otherwise} + \end{cases} + \\ + contribution_{\,\mathsf{Transparent}} &=& \mathsf{max}\big(\mathsf{ceiling}\big(\frac{tx\_in\_total\_size}{p2pkh\_standard\_input\_size}\big),\, + \mathsf{ceiling}\big(\frac{tx\_out\_total\_size}{p2pkh\_standard\_output\_size}\big)\big) \\ + contribution_{\,\mathsf{Sprout}} &=& 2 \cdot nJoinSplit \\ + contribution_{\,\mathsf{Sapling}} &=& \mathsf{max}(nSpendsSapling,\, nOutputsSapling) \\ + contribution_{\,\mathsf{Orchard}} &=& nActionsOrchard \\ + contribution_{\,\mathsf{ZSAIssuance}} &=& nZSAIssueNotes \\ + contribution_{\,\mathsf{ZSACreation}} &=& creation\_cost \cdot nAssetCreations \\ + contribution_{\,\mathsf{Memos}} &=& \mathsf{max}\big(0, nMemoChunks - free\_memo\_chunks\big) \\ \\ logical\_actions &=& contribution_{\,\mathsf{Transparent}} + contribution_{\,\mathsf{Sprout}} + contribution_{\,\mathsf{Sapling}} + contribution_{\,\mathsf{Orchard}} \\ + & & \hspace{1em} +\; contribution_{\,\mathsf{ZSAIssuance}} + + contribution_{\,\mathsf{ZSACreation}} + + contribution_{\,\mathsf{Memos}} \\ + \\ conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions,\, logical\_actions) \end{array} @@ -142,6 +156,9 @@ Input Units Description :math:`nSpendsSapling` number the number of Sapling spends :math:`nOutputsSapling` number the number of Sapling outputs :math:`nActionsOrchard` number the number of Orchard actions +:math:`nZSAIssueNotes` number the number of ``IssueNote`` outputs +:math:`nAssetCreations` number the number of Custom Assets newly added to the Global Issuance State +:math:`nMemoChunks` number the number of memo chunks ============================ ====== =========================================== It is not a consensus requirement that fees follow this formula; however, @@ -181,9 +198,6 @@ Rationale for the chosen parameters
Click to show/hide -Grace Actions -~~~~~~~~~~~~~ - **Why not just charge per-action, without a grace window?** * This ensures that there is no penalty to padding a 1-action @@ -221,8 +235,7 @@ ensures that a denial-of-service adversary does not gain a significant per-logical-action cost advantage by using transactions with a smaller or larger number of logical actions. -Transparent Contribution -~~~~~~~~~~~~~~~~~~~~~~~~ +**Transparent Contribution** The specified formula calculates the contribution of transparent inputs and outputs based on their total size relative to a typical input or @@ -257,14 +270,39 @@ may be larger than P2PKH inputs. For example a 2-of-3 multisig input is around 70% larger, and is counted as such when computing the number of logical actions. -Marginal Fee -~~~~~~~~~~~~ +**Marginal Fee** This returns the conventional fee for a minimal transaction (as described above) to the original conventional fee of 10000 zatoshis specified in [#zip-0313]_, and imposes a non-trivial cost for potential denial-of-service attacks. +**ZSA Creation Cost** + +Every newly created Custom Asset adds a new row to the Global Issuance +State [#zip-0227-global-issuance-state]_ that full validators need to +track in perpetuity. Subsequent issuance, finalization, or burn of +existing Custom Assets only changes the values in the corresponding row. +Imposing a higher cost on Custom Asset creation events disincentivizes +the creation of "junk" assets. + +**Memo Chunks** + +Making the fee linear in the number of memo chunks has the following properties: + +- The required fee to add more memo chunks scales at the same rate as adding + logical actions, so it isn't a cheaper mechanism for an adversary to bloat + chain size. +- A "baseline transaction" (one spent note, one output to an external recipient + with a memo, one change output without a memo) has the same fee as before. +- A "broadcast transaction" (many outputs to different recipients all given the + same memo) is the same fee as before (but a smaller transaction). +- A "many memos transaction" (many outputs to different recipients all with + unique memos) is at most around twice the fee as before. + +Combined with the memo bundle size restriction, the maximum additional fee for +a ZIP 231 memo bundle [#zip-0231]_ over prior transactions is 0.0019 ZEC. + .. raw:: html
@@ -582,5 +620,7 @@ References .. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus `_ .. [#sigop-limit] `zcash/zips issue #568 - Document block transparent sigops limit consensus rule `_ .. [#madars-1] `Madars concrete soft-fork proposal `_ +.. [#zip-0227-global-issuance-state] `ZIP 227: Issuance of Zcash Shielded Assets - Global Issuance State `_ +.. [#zip-0231] `ZIP 231: Memo Bundles `_ .. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis `_ .. [#zip-0401] `ZIP 401: Addressing Mempool Denial-of-Service `_