diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index e839ed4a6..139369b2a 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -73,7 +73,7 @@

Specification: Issuance Keys and Issuance Authorization Signature Scheme

-

The OrchardZSA Protocol adds the following keys to the key components 22 23:

+

The OrchardZSA Protocol adds the following keys to the key components 23 24:

  1. The issuance authorizing key, denoted as \(\mathsf{isk}\!\) @@ -90,7 +90,7 @@

    Issuance Authorization Signature Scheme

    We instantiate the issuance authorization signature scheme \(\mathsf{IssueAuthSig}\) - as a BIP-340 Schnorr signature over the secp256k1 curve. The signing and validation algorithms, signature encoding, and public key encoding MUST follow BIP 340 20.

    + as a BIP-340 Schnorr signature over the secp256k1 curve. The signing and validation algorithms, signature encoding, and public key encoding MUST follow BIP 340 21.

    Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results; for example, for a given verification key \(pk\) and @@ -120,7 +120,7 @@ \(k\) bytes, and \(\mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}\) - denotes the type of byte sequences of arbitrary length, as defined in the Zcash protocol specification 21.

    + denotes the type of byte sequences of arbitrary length, as defined in the Zcash protocol specification 22.

    The issuance authorizing key generation algorithm and the issuance validating key derivation algorithm are defined in the Issuance Key Derivation section, while the corresponding signing and validation algorithms are defined in the Issuance Authorization Signing and Validation section.

    Issuance Key Derivation

    @@ -200,7 +200,7 @@

    where the \(\textit{PubKey}\) - algorithm is defined in BIP 340 20. Note that the byte representation of + algorithm is defined in BIP 340 21. Note that the byte representation of \(\mathsf{ik}\) is in big-endian order as defined in BIP 340.

    It is possible for the @@ -238,7 +238,7 @@ \(\mathsf{Sign}\) algorithm is defined in BIP 340 and \(a\) - denotes the auxiliary data used in BIP 340 20. Note that + denotes the auxiliary data used in BIP 340 21. Note that \(\mathsf{IssueAuthSig}.\!\mathsf{Sign}\) could return \(\bot\) @@ -262,7 +262,7 @@

    where the \(\mathsf{Verify}\) - algorithm is defined in BIP 340 20.

    + algorithm is defined in BIP 340 21.

Specification: Asset Identifier

@@ -307,7 +307,7 @@ \(\mathsf{ZSAValueBase}(\mathsf{AssetDigest_{AssetId}}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{AssetDigest_{AssetId}})\) where \(\mathsf{GroupHash}^\mathbb{P}\) - is defined as in 25.

+ is defined as in 26.

The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

@@ -507,7 +507,7 @@ .
  • Let \(\mathsf{SigHash}\) - be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification 24 with the modifications described in ZIP 226 13, using + be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification 25 with the modifications described in ZIP 226 13, using \(\mathsf{SIGHASH\_ALL}\!\) .
  • The issuance authorization signature, @@ -674,7 +674,7 @@

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

    +

    This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification 27.

    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.

    @@ -740,6 +740,89 @@ 
    BLAKE2b-256("ZTxAuthZSAOrHash", [])
    • +

    OrchardZSA Fee Calculation

    +

    In addition to the parameters defined in the Fee calculation section of ZIP 317 20, the OrchardZSA protocol upgrade defines the following additional parameters:

    + + + + + + + + + + + + + +
    ParameterValue
    + \(issuance\_fee\) + + \(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:

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    InputUnitsDescription
    + \(nOrchardActions\) + numberthe number of OrchardZSA transfer actions (including ZEC actions)
    + \(nTotalOutputsZSAIssuance\) + numberthe total number of OrchardZSA issuance outputs (added across issuance actions)
    + \(nCreateActions\) + numberthe 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 28 and the global state. They are defined in the Fee calculation section of ZIP 317 20. 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:

    +
    \(zsa\_logical\_actions = logical\_actions \;+ nTotalOutputsZSAIssuance\)
    +

    The formula for the computation of the + \(zsa\_conventional\_fee\) + is:

    +
    \(\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

    +

    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.

    +

    An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. 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.

    +
    +

    Security and Privacy Considerations

    Displaying Asset Identifier information to users

    Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the Specification: Asset Identifier section.

    @@ -757,7 +840,7 @@

    Bridging Assets

    -

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

    +

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

    Other Considerations

    @@ -771,7 +854,7 @@ in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

    Fee Structures

    -

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317, and is described in ZIP 230 17.

    +

    The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317, and is described in ZIP 230 17.

    Test Vectors

    @@ -941,10 +1024,18 @@ - +
    + + + +
    20ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation
    + + + + @@ -952,7 +1043,7 @@
    21 BIP 340: Schnorr Signatures for secp256k1
    - + @@ -960,7 +1051,7 @@
    2122 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation
    - + @@ -968,7 +1059,7 @@
    2223 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.1: Payment Addresses and Keys
    - + @@ -976,7 +1067,7 @@
    2324 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.2.3: Orchard Key Components
    - + @@ -984,7 +1075,7 @@
    2425 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.10: SIGHASH Transaction Hashing
    - + @@ -992,7 +1083,7 @@
    2526 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.8: Group Hash into Pallas and Vesta
    - + @@ -1000,7 +1091,7 @@
    2627 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.6.4.2: Orchard Raw Payment Addresses
    - + diff --git a/rendered/zip-0230.html b/rendered/zip-0230.html index afc891216..9877595db 100644 --- a/rendered/zip-0230.html +++ b/rendered/zip-0230.html @@ -661,89 +661,6 @@
    2728 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1: Transaction Encoding and Consensus
    -

    OrchardZSA Fee Calculation

    -

    In addition to the parameters defined in the Fee calculation section of ZIP 317 13, the OrchardZSA protocol upgrade defines the following additional parameters:

    - - - - - - - - - - - - - -
    ParameterValue
    - \(issuance\_fee\) - - \(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:

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    InputUnitsDescription
    - \(nOrchardActions\) - numberthe number of OrchardZSA transfer actions (including ZEC actions)
    - \(nTotalOutputsZSAIssuance\) - numberthe total number of OrchardZSA issuance outputs (added across issuance actions)
    - \(nCreateActions\) - numberthe 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 6 and the global state. They are defined in the Fee calculation section of ZIP 317 13. 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:

    -
    \(zsa\_logical\_actions = logical\_actions \;+ nTotalOutputsZSAIssuance\)
    -

    The formula for the computation of the - \(zsa\_conventional\_fee\) - is:

    -
    \(\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

    -

    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.

    -

    An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. 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.

    -
    -

    Reference implementation

    TODO

    diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index f75764ffb..f5e05edda 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -550,6 +550,72 @@ In the case that the transaction has no Orchard Actions, ``issuance_auth_digest` 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. :math:`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 :math:`nOrchardActions`, that is used in the computation of :math:`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 :math:`zsa\_logical\_actions` (with the updated computation of :math:`logical\_actions` as described above) is: + +.. math:: + zsa\_logical\_actions = logical\_actions \;+ nTotalOutputsZSAIssuance + +The formula for the computation of the :math:`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 +----------------------------- + +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. + +An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. +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. + + Security and Privacy Considerations =================================== @@ -623,6 +689,7 @@ References .. [#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 `_ .. [#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 `_ diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index ca2ecb1ef..5d0bfce85 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -417,70 +417,6 @@ An issuance note, ``IssueNote`` contains the following fields: | | | |protocol §3.2.1 'Note Plaintexts and Memo Fields'. | +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ -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. :math:`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 :math:`nOrchardActions`, that is used in the computation of :math:`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 :math:`zsa\_logical\_actions` (with the updated computation of :math:`logical\_actions` as described above) is: - -.. math:: - zsa\_logical\_actions = logical\_actions \;+ nTotalOutputsZSAIssuance - -The formula for the computation of the :math:`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 ------------------------------ - -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. - -An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. -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. - Reference implementation ========================