From 0da1b348ea5991cf0ad9d0486207dd84aba2c095 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 25 Sep 2024 15:03:24 +0530 Subject: [PATCH 01/12] commenting out CI token lines to allow CI to build --- .github/workflows/render.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/render.yml b/.github/workflows/render.yml index 11fbb8ccc..817429aaa 100644 --- a/.github/workflows/render.yml +++ b/.github/workflows/render.yml @@ -13,8 +13,8 @@ jobs: steps: - name: Checkout repository uses: actions/checkout@v4.1.7 - with: - token: ${{ secrets.CI_TOKEN }} + # with: + # token: ${{ secrets.CI_TOKEN }} - name: Compile ZIPs and Zcash Protocol Specification uses: ./.github/actions/render From a92e9b344f9fa020b48e51b246ee2db639af9411 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Mon, 28 Nov 2022 12:48:02 +0100 Subject: [PATCH 02/12] adds initial zip fees zsa --- zip-0317b.html | 278 +++++++++++++++++++++++++++++++++++++++++++++++++ zip-0317b.rst | 161 ++++++++++++++++++++++++++++ 2 files changed, 439 insertions(+) create mode 100644 zip-0317b.html create mode 100644 zip-0317b.rst diff --git a/zip-0317b.html b/zip-0317b.html new file mode 100644 index 000000000..37dc5f586 --- /dev/null +++ b/zip-0317b.html @@ -0,0 +1,278 @@ + + + + ZIP 317b: ZSA Extension Proportional Fee Mechanism + + + + +
+ 
ZIP: 0317b
+Title: ZSA Extension Proportional Fee Mechanism
+Owners: Daniel Benarroch <daniel@qed-it.com>
+        Pablo Kogan <pablo@qed-it.com>
+        Jonathan Rouach <jon@qed-it.com>
+Credits: Daira Hopwood
+         Jack Grigg
+         Aditya Bharadwaj
+Status: Draft
+Category: Standards / Wallet
+Created: 2022-11-25
+License: MIT
+Discussions-To: <>
+

Terminology

+

The key words "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. 1

+

The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Zcash network to accept for including a transaction in a block.

+

We define the following additional terms:

+
    +
  • The term "network upgrade" in this document is to be interpreted as described in ZIP 200 2.
    • +
  • The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.
    • +
  • The term "ZSA" in this document is to be interpreted as described in ZIP 226 4.
    • +
  • The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 5.
    • +
  • The term "Proportional Fee" in this document is to be interpreted as described in ZIP 317 6
    • +
  • Issuance Fee: is the specific fixed fee that has to be paid to the network for every given issuance action
    • +
+
+

Abstract

+

This ZIP aims at defining explicitly the fee mechanism associated with the Zcash Shielded Assets protocol (ZSA) as described in ZIP 226 4 and ZIP 227 5. We will be basing this ZIP as an extension of the latest fee-related ZIP, ZIP 317 6.

+
+

Motivation

+

As the Zcash blockchain moves towards the Proportional Transfer Fee Mechanism proposed ZIP 317 6, transactions that use the ZSA protocol must adapt to this mechanism and include fees consistent with ZIP 317 6.

+

In this ZIP we propose an adaptation of ZIP 317 6 as it applies to ZSA transfer transactions and explore ZSA-specific considerations such as fees for asset issuance.

+

Specifically, the ZSA 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, we believe that there should be a preventative incentive that will stop users from flooding the chain with useless asset identifiers.

+

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

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

In the case of Issuance, the latter is not so relevant as 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 5, there is a new struct in the global state that needs to be maintained as part of the consensus, which motivates further the addition of an Issuance-specific fee.

+
+

Requirements

+
    +
  • The conventional fee formula should not favour or discriminate against any of the Orchard, Sapling, or transparent protocols.
    • +
  • The fee for a transaction should scale linearly with the number of inputs and/or outputs.
    • +
  • Users should be discouraged from creating new “garbage” custom assets
    • +
  • Users should not be penalised for sending transactions constructed with padding of inputs and outputs to reduce information leakage. (The default policy employed by zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool used by the transaction).
    • +
  • Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input.
    • +
+
+

Specification

+

The specification of this ZIP is based on the Proportional Transfer Fee Mechanism ZIP 317 6. We expand on how this mechanism will be affected by the replacement of the ZSA protocol for the Orchard protocol.

+

Issuance Action Fee

+

As reasoned above, we propose a fee for each issuance action, issuance_fee, in order to prevent users from issuing "garbage" assets and to incentivize miners to maintain a more complex blockchain state. The proposed fee mechanism is that for each new asset type (i.e.: for each issuance action), the issuer will pay a fixed fee for the action itself, of 0.01 ZEC or 1,000,000 ZATS, and a proportional fee for each output note generated for that asset (which is kept in line with the proportional fee mechanism from ZIP 317 6).

+
+

ZSA Fee calculation

+

The overall conventional_fee for a transaction is calculated as the sum of the issuance_fee and the transfer_fee: As in ZIP 317 6, this specification defines several parameters that are used to calculate the conventional fee:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterUnits
+ \(marginal\_fee\) + zatoshis per logical action (as defined below)
+ \(issusnce\_fee\) + zatoshis per issuance action (as defined below)
+ \(grace\_actions\) + logical actions
+ \(p2pkh\_standard\_input\_size\) + bytes
+ \(p2pkh\_standard\_output\_size\) + bytes
+

Wallets implementing this specification SHOULD use a conventional fee calculated in zatoshis per the following formula:

+
\(\begin{array}{rcl} + logical\_actions &=& \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) \;+ \\ + & & 2 \cdot nJoinSplit \;+ \\ + & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ + & & nActionsZsaTransfer \;+ \\ + & & nTotalOutputsZsaIssuance \\ + conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ + & & issuance\_fee \cdot nActionsIssuance +\end{array}\)
+

The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification [#protocol-txnencoding]_:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
InputUnitsDescription
+ \(tx\_in\_total\_size\) + bytestotal size in bytes of the tx_in field
+ \(tx\_out\_total\_size\) + bytestotal size in bytes of the tx_out field
+ \(nJoinSplit\) + numberthe number of Sprout JoinSplits
+ \(nSpendsSapling\) + numberthe number of Sapling spends
+ \(nOutputsSapling\) + numberthe number of Sapling outputs
+ \(nActionsZsaTransfer\) + numberthe number of ZSA transfer actions
+ \(nTotalOutputsZsaIssuance\) + numberthe total number of ZSA issuance outputs (added across issuance actions)
+ \(nActionsZsaIssuance\) + numberthe number of ZSA issuance actions
+

The parameters are set to the following values:

+
    +
  • + \(marginal\_fee = 5000\) + ;
    • +
  • + \(issuance\_fee = 1000000\) + ;
    • +
  • + \(grace\_actions = 2\) + ;
    • +
  • + \(p2pkh\_standard\_input\_size = 150\) + bytes;
    • +
  • + \(p2pkh\_standard\_output\_size = 34\) + bytes.
    • +
+

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.

+
+
+

Other Considerations

+
+

System Message: WARNING/2 (zip-0317b.rst line 149)

+

Title underline too short.

+ 
Other Considerations
+================
+
+

We also briefly considered, and propose to reject, the opportunity for a new type of fee, denominated in the ZSA token itself. In the context of transparent transactions, this type of fee allows to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.

+
+

References

+ + + + + + + +
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
3ZIP 224: Orchard
+ + + + + + + +
4ZIP 226: Transfer and Burn of Zcash Shielded Assets
+ + + + + + + +
5ZIP 227: Issuance of Zcash Shielded Assets
+ + + + + + + +
6ZIP 317: Proportional Transfer Fee Mechanism
+
+
+
+

Docutils System Messages

+
+

System Message: ERROR/3 (zip-0317b.rst line 119)

+

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

+
+
+

System Message: ERROR/3 (zip-0317b.rst line 119) id17

+

Unknown target name: "protocol-txnencoding".

+
+
+ + \ No newline at end of file diff --git a/zip-0317b.rst b/zip-0317b.rst new file mode 100644 index 000000000..1bf4bf74d --- /dev/null +++ b/zip-0317b.rst @@ -0,0 +1,161 @@ +:: + + ZIP: 0317b + Title: ZSA Extension Proportional Fee Mechanism + Owners: Daniel Benarroch + Pablo Kogan + Jonathan Rouach + Credits: Daira Hopwood + Jack Grigg + Aditya Bharadwaj + Status: Draft + Category: Standards / Wallet + Created: 2022-11-25 + License: MIT + Discussions-To: <> + + +Terminology +=========== + +The key words "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document +are to be interpreted as described in RFC 2119. [#RFC2119]_ + +The term "conventional transaction fee" in this document is in reference +to the value of a transaction fee that is conventionally used by wallets, +and that a user can reasonably expect miners on the Zcash network to accept +for including a transaction in a block. + +We define the following additional terms: + +- The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. +- The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. +- The term "ZSA" in this document is to be interpreted as described in ZIP 226 [#zip-0226]_. +- The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 [#zip-0227]_. +- The term "Proportional Fee" in this document is to be interpreted as described in ZIP 317 [#zip-0317]_ +- Issuance Fee: is the specific fixed fee that has to be paid to the network for every given issuance action + +Abstract +======== + +This ZIP aims at defining explicitly the fee mechanism associated with the Zcash Shielded Assets protocol (ZSA) as described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. We will be basing this ZIP as an extension of the latest fee-related ZIP, ZIP 317 [#zip-0317]_. + +Motivation +========== + +As the Zcash blockchain moves towards the Proportional Transfer Fee Mechanism proposed ZIP 317 [#zip-0317]_, transactions that use the ZSA protocol must adapt to this mechanism and include fees consistent with ZIP 317 [#zip-0317]_. + +In this ZIP we propose an adaptation of ZIP 317 [#zip-0317]_ as it applies to ZSA transfer transactions and explore ZSA-specific considerations such as fees for asset issuance. + +Specifically, the ZSA 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, we believe that there should be a preventative incentive that will stop users from flooding the chain with useless asset identifiers. + +There are two main factors that will affect the fee mechanism: + +- The transaction size, which may take a big part of the block +- The computational power needed to verify and mine the transaction + +In the case of Issuance, the latter is not so relevant as 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 a new struct in the global state that needs to be maintained as part of the consensus, which motivates further the addition of an Issuance-specific fee. + +Requirements +============ + +* The conventional fee formula should not favour or discriminate against any + of the Orchard, Sapling, or transparent protocols. +* The fee for a transaction should scale linearly with the number of inputs + and/or outputs. +* Users should be discouraged from creating new “garbage” custom assets +* Users should not be penalised for sending transactions constructed + with padding of inputs and outputs to reduce information leakage. + (The default policy employed by zcashd and the mobile SDKs pads to + two inputs and two outputs for each shielded pool used by the transaction). +* Users should be able to spend a small number of UTXOs or notes with value + below the marginal fee per input. + + +Specification +============= + +The specification of this ZIP is based on the Proportional Transfer Fee Mechanism ZIP 317 [#zip-0317]_. We expand on how this mechanism will be affected by the replacement of the ZSA protocol for the Orchard protocol. + +Issuance Action Fee +------------------- + +As reasoned above, we propose a fee for each issuance action, `issuance_fee`, in order to prevent users from issuing "garbage" assets and to incentivize miners to maintain a more complex blockchain state. +The proposed fee mechanism is that for each new asset type (i.e.: for each issuance action), the issuer will pay a fixed fee for the action itself, of `0.01 ZEC` or `1,000,000 ZATS`, and a proportional fee for each output note generated for that asset (which is kept in line with the proportional fee mechanism from ZIP 317 [#zip-0317]_). + +ZSA Fee calculation +------------------- + +The overall `conventional_fee` for a transaction is calculated as the sum of the `issuance_fee` and the `transfer_fee`: +As in ZIP 317 [#zip-0317]_, this specification defines several parameters that are used to calculate the +conventional fee: + +===================================== =============================================== +Parameter Units +===================================== =============================================== +:math:`marginal\_fee` zatoshis per logical action (as defined below) +:math:`issusnce\_fee` zatoshis per issuance action (as defined below) +:math:`grace\_actions` logical actions +:math:`p2pkh\_standard\_input\_size` bytes +:math:`p2pkh\_standard\_output\_size` bytes +===================================== =============================================== + +Wallets implementing this specification SHOULD use a conventional fee +calculated in zatoshis per the following formula: + +.. math:: + + \begin{array}{rcl} + logical\_actions &=& \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) \;+ \\ + & & 2 \cdot nJoinSplit \;+ \\ + & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ + & & nActionsZsaTransfer \;+ \\ + & & nTotalOutputsZsaIssuance \\ + conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ + & & issuance\_fee \cdot nActionsIssuance + \end{array} + +The inputs to this formula are taken from transaction fields defined in the Zcash protocol +specification [#protocol-txnencoding]_: + +================================ ====== ======================================================================== +Input Units Description +================================ ====== ======================================================================== +:math:`tx\_in\_total\_size` bytes total size in bytes of the ``tx_in`` field +:math:`tx\_out\_total\_size` bytes total size in bytes of the ``tx_out`` field +:math:`nJoinSplit` number the number of Sprout JoinSplits +:math:`nSpendsSapling` number the number of Sapling spends +:math:`nOutputsSapling` number the number of Sapling outputs +:math:`nActionsZsaTransfer` number the number of ZSA transfer actions +:math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) +:math:`nActionsZsaIssuance` number the number of ZSA issuance actions +================================ ====== ======================================================================== + +The parameters are set to the following values: + +* :math:`marginal\_fee = 5000`; +* :math:`issuance\_fee = 1000000`; +* :math:`grace\_actions = 2`; +* :math:`p2pkh\_standard\_input\_size = 150` bytes; +* :math:`p2pkh\_standard\_output\_size = 34` bytes. + +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. + + +Other Considerations +================ + +We also briefly considered, and propose to reject, the opportunity for a new type of fee, denominated in the ZSA token itself. In the context of transparent transactions, this type of fee allows to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem. + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0224] `ZIP 224: Orchard `_ +.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ +.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_ \ No newline at end of file From 05ce72170bd7c09d542c7be695e1836ed9c8f344 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 14:29:48 +0100 Subject: [PATCH 03/12] commits to create new branch --- zip-0317b.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0317b.rst b/zip-0317b.rst index 1bf4bf74d..023ac21f7 100644 --- a/zip-0317b.rst +++ b/zip-0317b.rst @@ -94,7 +94,7 @@ conventional fee: Parameter Units ===================================== =============================================== :math:`marginal\_fee` zatoshis per logical action (as defined below) -:math:`issusnce\_fee` zatoshis per issuance action (as defined below) +:math:`issuance\_fee` zatoshis per issuance action (as defined below) :math:`grace\_actions` logical actions :math:`p2pkh\_standard\_input\_size` bytes :math:`p2pkh\_standard\_output\_size` bytes @@ -113,7 +113,7 @@ calculated in zatoshis per the following formula: & & nActionsZsaTransfer \;+ \\ & & nTotalOutputsZsaIssuance \\ conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ - & & issuance\_fee \cdot nActionsIssuance + & & issuance\_fee \cdot nIssueActions \end{array} The inputs to this formula are taken from transaction fields defined in the Zcash protocol @@ -129,7 +129,7 @@ Input Units Description :math:`nOutputsSapling` number the number of Sapling outputs :math:`nActionsZsaTransfer` number the number of ZSA transfer actions :math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) -:math:`nActionsZsaIssuance` number the number of ZSA issuance actions +:math:`nIssueActions` number the number of ZSA issuance actions ================================ ====== ======================================================================== The parameters are set to the following values: From bc4bafb0bdcae89c13dcad3e9c6c16c527494622 Mon Sep 17 00:00:00 2001 From: daniben31 Date: Wed, 30 Nov 2022 16:41:02 +0100 Subject: [PATCH 04/12] further fee zip edits --- zip-0317b.html | 6 +++--- zip-0317b.rst | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0317b.html b/zip-0317b.html index 37dc5f586..a551fc1ed 100644 --- a/zip-0317b.html +++ b/zip-0317b.html @@ -79,7 +79,7 @@ - \(issusnce\_fee\) + \(issuance\_fee\) zatoshis per issuance action (as defined below) @@ -112,7 +112,7 @@ & & nActionsZsaTransfer \;+ \\ & & nTotalOutputsZsaIssuance \\ conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ - & & issuance\_fee \cdot nActionsIssuance + & & issuance\_fee \cdot nIssueActions \end{array}\)

The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification [#protocol-txnencoding]_:

@@ -175,7 +175,7 @@ diff --git a/zip-0317b.rst b/zip-0317b.rst index 023ac21f7..237c0bd2a 100644 --- a/zip-0317b.rst +++ b/zip-0317b.rst @@ -146,7 +146,7 @@ information leakage, unless overridden by the user. Other Considerations -================ +==================== We also briefly considered, and propose to reject, the opportunity for a new type of fee, denominated in the ZSA token itself. In the context of transparent transactions, this type of fee allows to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem. From 38d36783b0c0037cb819627127bee3232a40583d Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 10 Jan 2023 14:45:13 +0530 Subject: [PATCH 05/12] changing 317b rst file as per comments on PR#649 --- zip-0317b.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0317b.rst b/zip-0317b.rst index 237c0bd2a..dc01ab338 100644 --- a/zip-0317b.rst +++ b/zip-0317b.rst @@ -81,7 +81,7 @@ Issuance Action Fee ------------------- As reasoned above, we propose a fee for each issuance action, `issuance_fee`, in order to prevent users from issuing "garbage" assets and to incentivize miners to maintain a more complex blockchain state. -The proposed fee mechanism is that for each new asset type (i.e.: for each issuance action), the issuer will pay a fixed fee for the action itself, of `0.01 ZEC` or `1,000,000 ZATS`, and a proportional fee for each output note generated for that asset (which is kept in line with the proportional fee mechanism from ZIP 317 [#zip-0317]_). +The proposed fee mechanism is that for each new asset type (i.e.: for each issuance action), the issuer will pay a fixed fee for the action itself, of `0.01 ZEC` or `1,000,000 ZATS`, and a proportional fee for each output note generated for that asset, including issuance outputs (which is kept in line with the proportional fee mechanism from ZIP 317 [#zip-0317]_). ZSA Fee calculation ------------------- From 9d8a3f6e9d740d030aeccff64afc65ca854f7136 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 15 Jan 2023 15:49:32 +0530 Subject: [PATCH 06/12] adding credits for ZSA changes --- zips/zip-0317.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 4bb9986d1..5d81816fb 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -8,7 +8,11 @@ Kris Nuttycombe Jack Grigg Francisco Gindre - Status: Active + Daniel Benarroch + Jonathan Rouach + Pablo Kogan + Vivek Arte + Status: Draft Category: Standards / Wallet Obsoletes: ZIP 313 Created: 2022-08-15 From 67fa995c7c7bdcd0dab70bd0a1a9fbc0d781e6e3 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Mon, 16 Jan 2023 10:23:40 +0530 Subject: [PATCH 07/12] merging ZIP 317b into ZIP 317 for Fees ZIP --- rendered/zip-0317.html | 169 +++++++++++++++++++++++-- zip-0317b.html | 278 ----------------------------------------- zip-0317b.rst | 161 ------------------------ zips/zip-0317.rst | 84 +++++++++++++ 4 files changed, 241 insertions(+), 451 deletions(-) delete mode 100644 zip-0317b.html delete mode 100644 zip-0317b.rst diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index 1ada72c08..22ea5436e 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -15,7 +15,11 @@ Kris Nuttycombe Jack Grigg Francisco Gindre -Status: Active + Daniel Benarroch + Jonathan Rouach + Pablo Kogan + Vivek Arte +Status: Draft Category: Standards / Wallet Obsoletes: ZIP 313 Created: 2022-08-15 @@ -26,14 +30,29 @@

The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Zcash network to accept for including a transaction in a block.

The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined as in 2.

+

The terms "Zcash Shielded Asset", "ZSA" and "Asset" in this document are to be interpreted as described in ZIP 226 6.

+

The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 7.

+

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.
    • +

Abstract

The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users.

+

This ZIP also explicitly defines the fee mechanism associated with the Zcash Shielded Assets (ZSA) protocol as described in ZIP 226 6 and ZIP 227 7.

Motivation

-

In light of recent Mainnet network activity, it is time to review and update the standard 1,000 zatoshi transaction fee set in ZIP 313 6.

+

In light of recent Mainnet network activity, it is time to review and update the standard 1,000 zatoshi transaction fee set in ZIP 313 8.

The conventional transaction fee presently is 0.00001 ZEC or 1,000 zatoshis, as specified in ZIP 313. This allowed exploration of novel use cases of the Zcash blockchain. The Zcash network has operated for almost 2 years at a conventional transaction fee of 1,000 zatoshis, without consideration for the total number of inputs and outputs in each transaction. Under this conventional fee, some usage of the chain has been characterized by high-output transactions with 1,100 outputs, paying the same conventional fee as a transaction with 2 outputs.

The objective of the new fee policy, once it is enforced, is for fees paid by transactions to fairly reflect the processing costs that their inputs and outputs impose on various participants in the network. This will tend to discourage usage patterns that cause either intentional or unintentional denial of service, while still allowing low fees for regular transaction use cases.

+

The proposed upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. This involves adaptation for the transfer protocol 6, as well as additional considerations for the issuance protocol 7 such as fees for asset issuance.

+

Specifically, the ZSA 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, we believe that there should be a disincentive that will stop users from flooding the chain with useless asset identifiers.

+

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

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

In the case of Issuance, the latter is not so relevant as 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 7, there is an additional data structure in the global state that needs to be maintained as part of the consensus, which motivates further the addition of an Issuance-specific fee.

Requirements

    @@ -41,6 +60,7 @@
  • The fee for a transaction should scale linearly with the number of inputs and/or outputs.
  • Users should not be penalised for sending transactions constructed with padding of inputs and outputs to reduce information leakage. (The default policy employed by zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool used by the transaction).
  • Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input.
    • +
  • Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets.

Specification

@@ -131,7 +151,7 @@ contribution_{\,\mathsf{Orchard}} \\ conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions,\, logical\_actions) \end{array}\) -

The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3:

+

The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3:

- \(nActionsZsaIssuance\) + \(nIssueActions\) number the number of ZSA issuance actions
@@ -265,10 +285,113 @@

P2SH outputs are smaller than P2PKH outputs, but P2SH inputs 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
-

This returns the conventional fee for a minimal transaction (as described above) to the original conventional fee of 10000 zatoshis specified in 6, and imposes a non-trivial cost for potential denial-of-service attacks.

+

This returns the conventional fee for a minimal transaction (as described above) to the original conventional fee of 10000 zatoshis specified in 8, and imposes a non-trivial cost for potential denial-of-service attacks.

+

ZSA Fee calculation

+

In addition to the parameters defined in the Fee calculation section, the ZSA protocol upgrade defines the following additional parameter:

+
+ + + + + + + + + + + + + + +
ParameterValueUnits
+ \(issuance\_fee\) + + \(1000000\) + zatoshis per issuance action (as defined below)
+

Wallets implementing this specification SHOULD use a conventional fee calculated in zatoshis per the following formula:

+
\(\begin{array}{rcl} + logical\_actions &=& \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) \;+ \\ + & & 2 \cdot nJoinSplit \;+ \\ + & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ + & & nActionsZsaTransfer \;+ \\ + & & nTotalOutputsZsaIssuance \\ + conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ + & & issuance\_fee \cdot nIssueActions +\end{array}\)
+

The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
InputUnitsDescription
+ \(tx\_in\_total\_size\) + bytestotal size in bytes of the tx_in field
+ \(tx\_out\_total\_size\) + bytestotal size in bytes of the tx_out field
+ \(nJoinSplit\) + numberthe number of Sprout JoinSplits
+ \(nSpendsSapling\) + numberthe number of Sapling spends
+ \(nOutputsSapling\) + numberthe number of Sapling outputs
+ \(nActionsZsaTransfer\) + numberthe number of ZSA transfer actions
+ \(nTotalOutputsZsaIssuance\) + numberthe total number of ZSA issuance outputs (added across issuance actions)
+ \(nIssueActions\) + numberthe number of ZSA issuance actions
+

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.

+

Transaction relaying

zcashd, zebrad, and potentially other node implementations, implement fee-based restrictions on relaying of mempool transactions. Nodes that normally relay transactions are expected to do so for transactions that pay at least the conventional fee as specified in this ZIP, unless there are other reasons not to do so for robustness or denial-of-service mitigation.

If a transaction has more than @@ -276,7 +399,7 @@ "unpaid actions" as defined by the Recommended algorithm for block template construction, it will never be mined by that algorithm. Nodes MAY drop these transactions, or transactions with more unpaid actions than a configurable limit (see the Deployment section for actual behaviour of node implementations).

Mempool size limiting

-

zcashd and zebrad limit the size of the mempool as described in 7. This specifies a +

zcashd and zebrad limit the size of the mempool as described in 9. This specifies a \(low\_fee\_penalty\) that is added to the "eviction weight" if the transaction pays a fee less than the conventional transaction fee. This threshold is modified to use the new conventional fee formula.

@@ -320,7 +443,7 @@ with this transaction included.
  • If \(B\) - would be within the block size limit and block sigop limit 4, set + would be within the block size limit and block sigop limit 4, set \(T := B\!\) .
    • @@ -336,7 +459,7 @@ with this transaction included.
  • If \(B\) - would be within the block size limit and block sigop limit 4 and + would be within the block size limit and block sigop limit 4 and \(block\_unpaid\_actions(B) \leq block\_unpaid\_action\_limit\!\) , set \(T := B\!\) @@ -355,7 +478,7 @@ times the marginal fee, we count that as \(k\) unpaid logical actions.

    -

    Regardless of how full the mempool is (according to the ZIP 401 7 cost limiting), and regardless of what strategy a denial-of-service adversary may use, the number of unpaid logical actions in each block is always limited to at most +

    Regardless of how full the mempool is (according to the ZIP 401 9 cost limiting), and regardless of what strategy a denial-of-service adversary may use, the number of unpaid logical actions in each block is always limited to at most \(block\_unpaid\_action\_limit\!\) .

    The weighting in step 2 does not create a situation where the adversary gains a significant advantage over other users by paying more than the conventional fee, for two reasons:

    @@ -461,6 +584,9 @@

    zebra uses a similar relay threshold rule to zcashd, but additionally enforces a minimum fee of 100 zatoshis (this differs from zcashd only for valid transactions of less than 1000 bytes, assuming that zcashd uses its default value for -minrelaytxfee).

    +

    Deployment of ZSA changes

    +

    The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of the deployment of the ZSA protocol (ZIP 226 6 and ZIP 227 7), which is currently projected to be with Network Upgrade 6.

    +

    Considered Alternatives

    This section describes alternative proposals that have not been adopted.

    @@ -472,7 +598,7 @@ in @nuttycom's proposal.
  • \(marginal\_fee = 1000\) - adapted from @madars' proposal 5.
    • + adapted from @madars' proposal 5.
  • \(marginal\_fee = 2500\) in @daira's proposal.
    • @@ -487,6 +613,9 @@ parameter that caused the relationship between fee and number of inputs/outputs to be non-proportional above the \(grace\_actions\) threshold. This is no longer expressible with the formula specified above.)

    +

    ZSA Fee Considerations

    +

    One alternative proposal for the ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.

    +

    Endorsements

    The following entities and developers of the listed software expressed their support for the updated fee mechanism:

    @@ -498,7 +627,7 @@

    Acknowledgements

    -

    Thanks to Madars Virza for initially proposing a fee mechanism similar to that proposed in this ZIP 5, and for finding a potential weakness in an earlier version of the block template construction algorithm. Thanks also to Kris Nuttycombe, Jack Grigg, Francisco Gindre, Greg Pfeil, Teor, and Deirdre Connolly for reviews and suggested improvements.

    +

    Thanks to Madars Virza for initially proposing a fee mechanism similar to that proposed in this ZIP 5, and for finding a potential weakness in an earlier version of the block template construction algorithm. Thanks also to Kris Nuttycombe, Jack Grigg, Francisco Gindre, Greg Pfeil, Teor, and Deirdre Connolly for reviews and suggested improvements.

    References

    @@ -541,10 +670,26 @@
    - +
    + + + +
    6ZIP 226: Transfer and Burn of Zcash Shielded Assets
    + + + + + + + +
    7ZIP 227: Issuance of Zcash Shielded Assets
    + + + + @@ -552,7 +697,7 @@
    8 ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis
    - + diff --git a/zip-0317b.html b/zip-0317b.html deleted file mode 100644 index a551fc1ed..000000000 --- a/zip-0317b.html +++ /dev/null @@ -1,278 +0,0 @@ - - - - ZIP 317b: ZSA Extension Proportional Fee Mechanism - - - - -
    - 
    ZIP: 0317b
-Title: ZSA Extension Proportional Fee Mechanism
-Owners: Daniel Benarroch <daniel@qed-it.com>
-        Pablo Kogan <pablo@qed-it.com>
-        Jonathan Rouach <jon@qed-it.com>
-Credits: Daira Hopwood
-         Jack Grigg
-         Aditya Bharadwaj
-Status: Draft
-Category: Standards / Wallet
-Created: 2022-11-25
-License: MIT
-Discussions-To: <>
    -

    Terminology

    -

    The key words "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. 1

    -

    The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Zcash network to accept for including a transaction in a block.

    -

    We define the following additional terms:

    -
      -
    • The term "network upgrade" in this document is to be interpreted as described in ZIP 200 2.
      • -
    • The term "Orchard" in this document is to be interpreted as described in ZIP 224 3.
      • -
    • The term "ZSA" in this document is to be interpreted as described in ZIP 226 4.
      • -
    • The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 5.
      • -
    • The term "Proportional Fee" in this document is to be interpreted as described in ZIP 317 6
      • -
    • Issuance Fee: is the specific fixed fee that has to be paid to the network for every given issuance action
      • -
    -
    -

    Abstract

    -

    This ZIP aims at defining explicitly the fee mechanism associated with the Zcash Shielded Assets protocol (ZSA) as described in ZIP 226 4 and ZIP 227 5. We will be basing this ZIP as an extension of the latest fee-related ZIP, ZIP 317 6.

    -
    -

    Motivation

    -

    As the Zcash blockchain moves towards the Proportional Transfer Fee Mechanism proposed ZIP 317 6, transactions that use the ZSA protocol must adapt to this mechanism and include fees consistent with ZIP 317 6.

    -

    In this ZIP we propose an adaptation of ZIP 317 6 as it applies to ZSA transfer transactions and explore ZSA-specific considerations such as fees for asset issuance.

    -

    Specifically, the ZSA 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, we believe that there should be a preventative incentive that will stop users from flooding the chain with useless asset identifiers.

    -

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

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

    In the case of Issuance, the latter is not so relevant as 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 5, there is a new struct in the global state that needs to be maintained as part of the consensus, which motivates further the addition of an Issuance-specific fee.

    -
    -

    Requirements

    -
      -
    • The conventional fee formula should not favour or discriminate against any of the Orchard, Sapling, or transparent protocols.
      • -
    • The fee for a transaction should scale linearly with the number of inputs and/or outputs.
      • -
    • Users should be discouraged from creating new “garbage” custom assets
      • -
    • Users should not be penalised for sending transactions constructed with padding of inputs and outputs to reduce information leakage. (The default policy employed by zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool used by the transaction).
      • -
    • Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input.
      • -
    -
    -

    Specification

    -

    The specification of this ZIP is based on the Proportional Transfer Fee Mechanism ZIP 317 6. We expand on how this mechanism will be affected by the replacement of the ZSA protocol for the Orchard protocol.

    -

    Issuance Action Fee

    -

    As reasoned above, we propose a fee for each issuance action, issuance_fee, in order to prevent users from issuing "garbage" assets and to incentivize miners to maintain a more complex blockchain state. The proposed fee mechanism is that for each new asset type (i.e.: for each issuance action), the issuer will pay a fixed fee for the action itself, of 0.01 ZEC or 1,000,000 ZATS, and a proportional fee for each output note generated for that asset (which is kept in line with the proportional fee mechanism from ZIP 317 6).

    -
    -

    ZSA Fee calculation

    -

    The overall conventional_fee for a transaction is calculated as the sum of the issuance_fee and the transfer_fee: As in ZIP 317 6, this specification defines several parameters that are used to calculate the conventional fee:

    -
    79 ZIP 401: Addressing Mempool Denial-of-Service
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterUnits
    - \(marginal\_fee\) - zatoshis per logical action (as defined below)
    - \(issuance\_fee\) - zatoshis per issuance action (as defined below)
    - \(grace\_actions\) - logical actions
    - \(p2pkh\_standard\_input\_size\) - bytes
    - \(p2pkh\_standard\_output\_size\) - bytes
    -

    Wallets implementing this specification SHOULD use a conventional fee calculated in zatoshis per the following formula:

    -
    \(\begin{array}{rcl} - logical\_actions &=& \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) \;+ \\ - & & 2 \cdot nJoinSplit \;+ \\ - & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ - & & nActionsZsaTransfer \;+ \\ - & & nTotalOutputsZsaIssuance \\ - conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions -\end{array}\)
    -

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification [#protocol-txnencoding]_:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    InputUnitsDescription
    - \(tx\_in\_total\_size\) - bytestotal size in bytes of the tx_in field
    - \(tx\_out\_total\_size\) - bytestotal size in bytes of the tx_out field
    - \(nJoinSplit\) - numberthe number of Sprout JoinSplits
    - \(nSpendsSapling\) - numberthe number of Sapling spends
    - \(nOutputsSapling\) - numberthe number of Sapling outputs
    - \(nActionsZsaTransfer\) - numberthe number of ZSA transfer actions
    - \(nTotalOutputsZsaIssuance\) - numberthe total number of ZSA issuance outputs (added across issuance actions)
    - \(nIssueActions\) - numberthe number of ZSA issuance actions
    -

    The parameters are set to the following values:

    -
      -
    • - \(marginal\_fee = 5000\) - ;
      • -
    • - \(issuance\_fee = 1000000\) - ;
      • -
    • - \(grace\_actions = 2\) - ;
      • -
    • - \(p2pkh\_standard\_input\_size = 150\) - bytes;
      • -
    • - \(p2pkh\_standard\_output\_size = 34\) - bytes.
      • -
    -

    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.

    -
    - -

    Other Considerations

    -
    -

    System Message: WARNING/2 (zip-0317b.rst line 149)

    -

    Title underline too short.

    - 
    Other Considerations
-================
    -
    -

    We also briefly considered, and propose to reject, the opportunity for a new type of fee, denominated in the ZSA token itself. In the context of transparent transactions, this type of fee allows to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.

    -
    -

    References

    - - - - - - - -
    1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
    - - - - - - - -
    2ZIP 200: Network Upgrade Mechanism
    - - - - - - - -
    3ZIP 224: Orchard
    - - - - - - - -
    4ZIP 226: Transfer and Burn of Zcash Shielded Assets
    - - - - - - - -
    5ZIP 227: Issuance of Zcash Shielded Assets
    - - - - - - - -
    6ZIP 317: Proportional Transfer Fee Mechanism
    -
    - -
    -

    Docutils System Messages

    -
    -

    System Message: ERROR/3 (zip-0317b.rst line 119)

    -

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

    -
    -
    -

    System Message: ERROR/3 (zip-0317b.rst line 119) id17

    -

    Unknown target name: "protocol-txnencoding".

    -
    -
    - - \ No newline at end of file diff --git a/zip-0317b.rst b/zip-0317b.rst deleted file mode 100644 index dc01ab338..000000000 --- a/zip-0317b.rst +++ /dev/null @@ -1,161 +0,0 @@ -:: - - ZIP: 0317b - Title: ZSA Extension Proportional Fee Mechanism - Owners: Daniel Benarroch - Pablo Kogan - Jonathan Rouach - Credits: Daira Hopwood - Jack Grigg - Aditya Bharadwaj - Status: Draft - Category: Standards / Wallet - Created: 2022-11-25 - License: MIT - Discussions-To: <> - - -Terminology -=========== - -The key words "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document -are to be interpreted as described in RFC 2119. [#RFC2119]_ - -The term "conventional transaction fee" in this document is in reference -to the value of a transaction fee that is conventionally used by wallets, -and that a user can reasonably expect miners on the Zcash network to accept -for including a transaction in a block. - -We define the following additional terms: - -- The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. -- The term "Orchard" in this document is to be interpreted as described in ZIP 224 [#zip-0224]_. -- The term "ZSA" in this document is to be interpreted as described in ZIP 226 [#zip-0226]_. -- The term "Issuance" and "Issuance Action" in this document are to be interpreted as described in ZIP 227 [#zip-0227]_. -- The term "Proportional Fee" in this document is to be interpreted as described in ZIP 317 [#zip-0317]_ -- Issuance Fee: is the specific fixed fee that has to be paid to the network for every given issuance action - -Abstract -======== - -This ZIP aims at defining explicitly the fee mechanism associated with the Zcash Shielded Assets protocol (ZSA) as described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. We will be basing this ZIP as an extension of the latest fee-related ZIP, ZIP 317 [#zip-0317]_. - -Motivation -========== - -As the Zcash blockchain moves towards the Proportional Transfer Fee Mechanism proposed ZIP 317 [#zip-0317]_, transactions that use the ZSA protocol must adapt to this mechanism and include fees consistent with ZIP 317 [#zip-0317]_. - -In this ZIP we propose an adaptation of ZIP 317 [#zip-0317]_ as it applies to ZSA transfer transactions and explore ZSA-specific considerations such as fees for asset issuance. - -Specifically, the ZSA 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, we believe that there should be a preventative incentive that will stop users from flooding the chain with useless asset identifiers. - -There are two main factors that will affect the fee mechanism: - -- The transaction size, which may take a big part of the block -- The computational power needed to verify and mine the transaction - -In the case of Issuance, the latter is not so relevant as 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 a new struct in the global state that needs to be maintained as part of the consensus, which motivates further the addition of an Issuance-specific fee. - -Requirements -============ - -* The conventional fee formula should not favour or discriminate against any - of the Orchard, Sapling, or transparent protocols. -* The fee for a transaction should scale linearly with the number of inputs - and/or outputs. -* Users should be discouraged from creating new “garbage” custom assets -* Users should not be penalised for sending transactions constructed - with padding of inputs and outputs to reduce information leakage. - (The default policy employed by zcashd and the mobile SDKs pads to - two inputs and two outputs for each shielded pool used by the transaction). -* Users should be able to spend a small number of UTXOs or notes with value - below the marginal fee per input. - - -Specification -============= - -The specification of this ZIP is based on the Proportional Transfer Fee Mechanism ZIP 317 [#zip-0317]_. We expand on how this mechanism will be affected by the replacement of the ZSA protocol for the Orchard protocol. - -Issuance Action Fee -------------------- - -As reasoned above, we propose a fee for each issuance action, `issuance_fee`, in order to prevent users from issuing "garbage" assets and to incentivize miners to maintain a more complex blockchain state. -The proposed fee mechanism is that for each new asset type (i.e.: for each issuance action), the issuer will pay a fixed fee for the action itself, of `0.01 ZEC` or `1,000,000 ZATS`, and a proportional fee for each output note generated for that asset, including issuance outputs (which is kept in line with the proportional fee mechanism from ZIP 317 [#zip-0317]_). - -ZSA Fee calculation -------------------- - -The overall `conventional_fee` for a transaction is calculated as the sum of the `issuance_fee` and the `transfer_fee`: -As in ZIP 317 [#zip-0317]_, this specification defines several parameters that are used to calculate the -conventional fee: - -===================================== =============================================== -Parameter Units -===================================== =============================================== -:math:`marginal\_fee` zatoshis per logical action (as defined below) -:math:`issuance\_fee` zatoshis per issuance action (as defined below) -:math:`grace\_actions` logical actions -:math:`p2pkh\_standard\_input\_size` bytes -:math:`p2pkh\_standard\_output\_size` bytes -===================================== =============================================== - -Wallets implementing this specification SHOULD use a conventional fee -calculated in zatoshis per the following formula: - -.. math:: - - \begin{array}{rcl} - logical\_actions &=& \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) \;+ \\ - & & 2 \cdot nJoinSplit \;+ \\ - & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ - & & nActionsZsaTransfer \;+ \\ - & & nTotalOutputsZsaIssuance \\ - conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions - \end{array} - -The inputs to this formula are taken from transaction fields defined in the Zcash protocol -specification [#protocol-txnencoding]_: - -================================ ====== ======================================================================== -Input Units Description -================================ ====== ======================================================================== -:math:`tx\_in\_total\_size` bytes total size in bytes of the ``tx_in`` field -:math:`tx\_out\_total\_size` bytes total size in bytes of the ``tx_out`` field -:math:`nJoinSplit` number the number of Sprout JoinSplits -:math:`nSpendsSapling` number the number of Sapling spends -:math:`nOutputsSapling` number the number of Sapling outputs -:math:`nActionsZsaTransfer` number the number of ZSA transfer actions -:math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) -:math:`nIssueActions` number the number of ZSA issuance actions -================================ ====== ======================================================================== - -The parameters are set to the following values: - -* :math:`marginal\_fee = 5000`; -* :math:`issuance\_fee = 1000000`; -* :math:`grace\_actions = 2`; -* :math:`p2pkh\_standard\_input\_size = 150` bytes; -* :math:`p2pkh\_standard\_output\_size = 34` bytes. - -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. - - -Other Considerations -==================== - -We also briefly considered, and propose to reject, the opportunity for a new type of fee, denominated in the ZSA token itself. In the context of transparent transactions, this type of fee allows to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem. - -References -========== - -.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ -.. [#zip-0224] `ZIP 224: Orchard `_ -.. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ -.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ -.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_ \ No newline at end of file diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 5d81816fb..3602356b1 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -36,6 +36,14 @@ for including a transaction in a block. The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined as in [#protocol-networks]_. +The terms "Zcash Shielded Asset", "ZSA" and "Asset" in this document are to be interpreted as described in ZIP 226 [#zip-0226]_. + +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. + Abstract ======== @@ -44,6 +52,8 @@ The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users. +This ZIP also explicitly defines the fee mechanism associated with the Zcash Shielded Assets (ZSA) protocol as described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. + Motivation ========== @@ -65,6 +75,17 @@ impose on various participants in the network. This will tend to discourage usage patterns that cause either intentional or unintentional denial of service, while still allowing low fees for regular transaction use cases. +The proposed upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. 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 ZSA 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, we believe that there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. + +The two main factors that will affect the fee mechanism are: + +- The transaction size, which may take a big part of the block. +- The computational power needed to verify and mine the transaction. + +In the case of Issuance, the latter is not so relevant as 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, which motivates further the addition of an Issuance-specific fee. + Requirements ============ @@ -79,6 +100,8 @@ Requirements two inputs and two outputs for each shielded pool used by the transaction). * Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input. +* Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets. + Specification @@ -270,6 +293,53 @@ potential denial-of-service attacks. + +ZSA Fee calculation +------------------- +In addition to the parameters defined in the `Fee calculation`_ section, the ZSA protocol upgrade defines the following additional parameter: + +===================================== =============== =============================================== +Parameter Value Units +===================================== =============== =============================================== +:math:`issuance\_fee` :math:`1000000` zatoshis per issuance action (as defined below) +===================================== =============== =============================================== + +Wallets implementing this specification SHOULD use a conventional fee +calculated in zatoshis per the following formula: + +.. math:: + + \begin{array}{rcl} + logical\_actions &=& \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) \;+ \\ + & & 2 \cdot nJoinSplit \;+ \\ + & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ + & & nActionsZsaTransfer \;+ \\ + & & nTotalOutputsZsaIssuance \\ + conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ + & & issuance\_fee \cdot nIssueActions + \end{array} + +The inputs to this formula are taken from transaction fields defined in the Zcash protocol +specification [#protocol-txnencoding]_: + +================================ ====== ======================================================================== +Input Units Description +================================ ====== ======================================================================== +:math:`tx\_in\_total\_size` bytes total size in bytes of the ``tx_in`` field +:math:`tx\_out\_total\_size` bytes total size in bytes of the ``tx_out`` field +:math:`nJoinSplit` number the number of Sprout JoinSplits +:math:`nSpendsSapling` number the number of Sapling spends +:math:`nOutputsSapling` number the number of Sapling outputs +:math:`nActionsZsaTransfer` number the number of ZSA transfer actions +:math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) +:math:`nIssueActions` number the number of ZSA issuance actions +================================ ====== ======================================================================== + +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. + Transaction relaying -------------------- @@ -528,6 +598,11 @@ enforces a minimum fee of 100 zatoshis (this differs from `zcashd` only for valid transactions of less than 1000 bytes, assuming that `zcashd` uses its default value for ``-minrelaytxfee``). +Deployment of ZSA changes +------------------------- + +The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of the deployment of the ZSA protocol (ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_), which is currently projected to be with Network Upgrade 6. + Considered Alternatives ======================= @@ -552,6 +627,13 @@ Possible alternatives for the parameters: of inputs/outputs to be non-proportional above the :math:`grace\_actions` threshold. This is no longer expressible with the formula specified above.) +ZSA Fee Considerations +---------------------- + +One alternative proposal for the ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. +However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem. + Endorsements ============ @@ -583,5 +665,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-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis `_ .. [#zip-0401] `ZIP 401: Addressing Mempool Denial-of-Service `_ From 40261f5c41c45aa07163338b67f47ce279a86182 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 18 Jan 2023 10:49:17 +0530 Subject: [PATCH 08/12] adding finalization fee and other edits to fees ZIP --- rendered/zip-0317.html | 79 +++++++++++++++--------------------------- zips/zip-0317.rst | 38 +++++++++----------- 2 files changed, 44 insertions(+), 73 deletions(-) diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index 22ea5436e..d0bd71aae 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -47,12 +47,7 @@

    The objective of the new fee policy, once it is enforced, is for fees paid by transactions to fairly reflect the processing costs that their inputs and outputs impose on various participants in the network. This will tend to discourage usage patterns that cause either intentional or unintentional denial of service, while still allowing low fees for regular transaction use cases.

    The proposed upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. This involves adaptation for the transfer protocol 6, as well as additional considerations for the issuance protocol 7 such as fees for asset issuance.

    Specifically, the ZSA 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, we believe that there should be a disincentive that will stop users from flooding the chain with useless asset identifiers.

    -

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

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

    In the case of Issuance, the latter is not so relevant as 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 7, there is an additional data structure in the global state that needs to be maintained as part of the consensus, which motivates further the addition of an Issuance-specific fee.

    +

    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 7, 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

      @@ -61,6 +56,7 @@
    • Users should not be penalised for sending transactions constructed with padding of inputs and outputs to reduce information leakage. (The default policy employed by zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool used by the transaction).
    • Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input.
    • Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets.
      • +
    • Post the upgrade to the ZSA protocol, users should be discouraged from finalizing Assets frivolously.

    Specification

    @@ -309,20 +305,28 @@ zatoshis per issuance action (as defined below) + + + \(finalize\_fee\) + + + \(1000000\) + + zatoshis per issuance action (as defined below) +

    Wallets implementing this specification SHOULD use a conventional fee calculated in zatoshis per the following formula:

    \(\begin{array}{rcl} - logical\_actions &=& \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) \;+ \\ - & & 2 \cdot nJoinSplit \;+ \\ - & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ + zsa\_logical\_actions &=& logical\_actions \;- \\ + & & nActionsOrchard \;+ \\ & & nActionsZsaTransfer \;+ \\ & & nTotalOutputsZsaIssuance \\ - conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions + zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ + & & issuance\_fee \cdot nIssueActions \;+ \\ + & & finalize\_fee \cdot nFinalizeActions \end{array}\)
    -

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3:

    +

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3. They are defined in the Fee calculation section above, with additional definitions in the table below:

    @@ -332,41 +336,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - + + + + +
    - \(tx\_in\_total\_size\) - bytestotal size in bytes of the tx_in field
    - \(tx\_out\_total\_size\) - bytestotal size in bytes of the tx_out field
    - \(nJoinSplit\) - numberthe number of Sprout JoinSplits
    - \(nSpendsSapling\) - numberthe number of Sapling spends
    - \(nOutputsSapling\) - numberthe number of Sapling outputs
    \(nActionsZsaTransfer\) @@ -388,6 +357,13 @@ number the number of ZSA issuance actions
    + \(nFinalizeActions\) + numberthe number of ZSA issuance actions that set the finalize flag

    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.

    @@ -613,9 +589,10 @@ parameter that caused the relationship between fee and number of inputs/outputs to be non-proportional above the \(grace\_actions\) threshold. This is no longer expressible with the formula specified above.)

    -

    ZSA Fee Considerations

    -

    One alternative proposal for the ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.

    -
    +
    +

    ZSA 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 ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.

    Endorsements

    The following entities and developers of the listed software expressed their support for the updated fee mechanism:

    diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 3602356b1..01adbb4bb 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -79,12 +79,7 @@ The proposed upgrade to the ZSA protocol will also need to define a fee structur Specifically, the ZSA 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, we believe that there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. -The two main factors that will affect the fee mechanism are: - -- The transaction size, which may take a big part of the block. -- The computational power needed to verify and mine the transaction. - -In the case of Issuance, the latter is not so relevant as 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, which motivates further the addition of an Issuance-specific fee. +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 @@ -101,6 +96,7 @@ Requirements * Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input. * Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets. +* Post the upgrade to the ZSA protocol, users should be discouraged from finalizing Assets frivolously. @@ -302,6 +298,7 @@ In addition to the parameters defined in the `Fee calculation`_ section, the ZSA Parameter Value Units ===================================== =============== =============================================== :math:`issuance\_fee` :math:`1000000` zatoshis per issuance action (as defined below) +:math:`finalize\_fee` :math:`1000000` zatoshis per issuance action (as defined below) ===================================== =============== =============================================== Wallets implementing this specification SHOULD use a conventional fee @@ -310,36 +307,32 @@ calculated in zatoshis per the following formula: .. math:: \begin{array}{rcl} - logical\_actions &=& \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) \;+ \\ - & & 2 \cdot nJoinSplit \;+ \\ - & & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\ + zsa\_logical\_actions &=& logical\_actions \;- \\ + & & nActionsOrchard \;+ \\ & & nActionsZsaTransfer \;+ \\ & & nTotalOutputsZsaIssuance \\ - conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions + zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ + & & issuance\_fee \cdot nIssueActions \;+ \\ + & & finalize\_fee \cdot nFinalizeActions \end{array} The inputs to this formula are taken from transaction fields defined in the Zcash protocol -specification [#protocol-txnencoding]_: +specification [#protocol-txnencoding]_. They are defined in the `Fee calculation`_ section above, with additional definitions in the table below: ================================ ====== ======================================================================== Input Units Description ================================ ====== ======================================================================== -:math:`tx\_in\_total\_size` bytes total size in bytes of the ``tx_in`` field -:math:`tx\_out\_total\_size` bytes total size in bytes of the ``tx_out`` field -:math:`nJoinSplit` number the number of Sprout JoinSplits -:math:`nSpendsSapling` number the number of Sapling spends -:math:`nOutputsSapling` number the number of Sapling outputs :math:`nActionsZsaTransfer` number the number of ZSA transfer actions :math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) :math:`nIssueActions` number the number of ZSA issuance actions +:math:`nFinalizeActions` number the number of ZSA issuance actions that set the ``finalize`` flag ================================ ====== ======================================================================== 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. + Transaction relaying -------------------- @@ -628,12 +621,13 @@ of inputs/outputs to be non-proportional above the :math:`grace\_actions` threshold. This is no longer expressible with the formula specified above.) ZSA Fee Considerations ----------------------- +====================== -One alternative proposal for the ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. -However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Another consideration against ZSA-denominated fees is to maintain the ZEC as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem. +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 ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. +However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. Endorsements ============ From ee1c5020474d265861825d5426aa6fac362e25a4 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Tue, 24 Jan 2023 21:41:25 +0530 Subject: [PATCH 09/12] Update zip-0317.rst Co-authored-by: teor --- zips/zip-0317.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 01adbb4bb..e13b688f9 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -626,7 +626,7 @@ ZSA 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 ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. +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. Endorsements From 372b971068f357c3a9f7b765392bf0939c70b37f Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Tue, 24 Jan 2023 21:48:08 +0530 Subject: [PATCH 10/12] Update zip-0317.rst Co-authored-by: teor --- zips/zip-0317.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index e13b688f9..39097fa33 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -292,7 +292,7 @@ potential denial-of-service attacks. ZSA Fee calculation ------------------- -In addition to the parameters defined in the `Fee calculation`_ section, the ZSA protocol upgrade defines the following additional parameter: +In addition to the parameters defined in the `Fee calculation`_ section, the ZSA protocol upgrade defines the following additional parameters: ===================================== =============== =============================================== Parameter Value Units From 6e5bf3d3f0a8b55b970752b381f565fc3865daba Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 24 Jan 2023 23:29:06 +0530 Subject: [PATCH 11/12] Updates based on review --- rendered/zip-0317.html | 20 +++++++++++--------- zips/zip-0317.rst | 10 ++++------ 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index d0bd71aae..1646228c1 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -286,7 +286,7 @@

    ZSA Fee calculation

    -

    In addition to the parameters defined in the Fee calculation section, the ZSA protocol upgrade defines the following additional parameter:

    +

    In addition to the parameters defined in the Fee calculation section, the ZSA protocol upgrade defines the following additional parameters:

    @@ -316,17 +316,19 @@
    -

    Wallets implementing this specification SHOULD use a conventional fee calculated in zatoshis per the following formula:

    +

    Wallets implementing this specification SHOULD use a conventional fee, viz. + \(zsa\_conventional\_fee\) + , that is calculated in zatoshis per the following formula:

    \(\begin{array}{rcl} - zsa\_logical\_actions &=& logical\_actions \;- \\ - & & nActionsOrchard \;+ \\ - & & nActionsZsaTransfer \;+ \\ + zsa\_logical\_actions &=& logical\_actions \;+ \\ & & nTotalOutputsZsaIssuance \\ zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ & & issuance\_fee \cdot nIssueActions \;+ \\ & & finalize\_fee \cdot nFinalizeActions \end{array}\)
    -

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3. They are defined in the Fee calculation section above, with additional definitions in the table below:

    +

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3. They are defined in the Fee calculation section above, with additional definitions in the table below. Note that + \(nOrchardActions\) + is redefined and now combines both the Orchard actions for ZEC values as well as ZSA transfer actions for transfer of Assets.

    @@ -338,10 +340,10 @@ - +
    - \(nActionsZsaTransfer\) + \(nOrchardActions\) numberthe number of ZSA transfer actionsthe number of ZSA transfer actions (including ZEC actions)
    @@ -592,7 +594,7 @@

    ZSA 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 ZSA 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 to “tap into” the value of the transactions for the benefit of the miners. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.

    +

    An alternative proposal for the ZSA 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.

    Endorsements

    The following entities and developers of the listed software expressed their support for the updated fee mechanism:

    diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 39097fa33..664789243 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -301,15 +301,13 @@ Parameter Value Units :math:`finalize\_fee` :math:`1000000` zatoshis per issuance action (as defined below) ===================================== =============== =============================================== -Wallets implementing this specification SHOULD use a conventional fee +Wallets implementing this specification SHOULD use a conventional fee, viz. :math:`zsa\_conventional\_fee`, that is calculated in zatoshis per the following formula: .. math:: \begin{array}{rcl} - zsa\_logical\_actions &=& logical\_actions \;- \\ - & & nActionsOrchard \;+ \\ - & & nActionsZsaTransfer \;+ \\ + zsa\_logical\_actions &=& logical\_actions \;+ \\ & & nTotalOutputsZsaIssuance \\ zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ & & issuance\_fee \cdot nIssueActions \;+ \\ @@ -317,12 +315,12 @@ calculated in zatoshis per the following formula: \end{array} The inputs to this formula are taken from transaction fields defined in the Zcash protocol -specification [#protocol-txnencoding]_. They are defined in the `Fee calculation`_ section above, with additional definitions in the table below: +specification [#protocol-txnencoding]_. They are defined in the `Fee calculation`_ section above, with additional definitions in the table below. Note that :math:`nOrchardActions` is redefined and now combines both the Orchard actions for ZEC values as well as ZSA transfer actions for transfer of Assets. ================================ ====== ======================================================================== Input Units Description ================================ ====== ======================================================================== -:math:`nActionsZsaTransfer` number the number of ZSA transfer actions +:math:`nOrchardActions` number the number of ZSA transfer actions (including ZEC actions) :math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) :math:`nIssueActions` number the number of ZSA issuance actions :math:`nFinalizeActions` number the number of ZSA issuance actions that set the ``finalize`` flag From e26af6edf0da98dd22b745f198918157972e2ca5 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Sun, 3 Nov 2024 17:56:34 +0530 Subject: [PATCH 12/12] [ZSA][Fees] Refactoring the ZSA Fees (#71) - This PR rewrites ZIP 317 in order to specify which are the revisions made for the ZSA Protocol. - It also rewrites the issuance_fee as a multiple of the marginal_fee for easier analysis. - The finalization fee is also removed, based on our discussions. --------- Co-authored-by: Daira-Emma Hopwood --- rendered/zip-0317.html | 75 ++++++++++++++++------------------- zips/zip-0317.rst | 90 +++++++++++++++++++++++++++--------------- 2 files changed, 92 insertions(+), 73 deletions(-) diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index 1646228c1..3305e9203 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -19,7 +19,7 @@ Jonathan Rouach Pablo Kogan Vivek Arte -Status: Draft +Status: Revision 0: Active, Revision 1: Draft Category: Standards / Wallet Obsoletes: ZIP 313 Created: 2022-08-15 @@ -39,15 +39,17 @@

    Abstract

    The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users.

    -

    This ZIP also explicitly defines the fee mechanism associated with the Zcash Shielded Assets (ZSA) protocol as described in ZIP 226 6 and ZIP 227 7.

    +

    Revision 1 of this ZIP additionally defines the fee mechanism associated with the Orchard Zcash Shielded Assets (OrchardZSA) protocol as described in ZIP 226 6 and ZIP 227 7.

    Motivation

    In light of recent Mainnet network activity, it is time to review and update the standard 1,000 zatoshi transaction fee set in ZIP 313 8.

    The conventional transaction fee presently is 0.00001 ZEC or 1,000 zatoshis, as specified in ZIP 313. This allowed exploration of novel use cases of the Zcash blockchain. The Zcash network has operated for almost 2 years at a conventional transaction fee of 1,000 zatoshis, without consideration for the total number of inputs and outputs in each transaction. Under this conventional fee, some usage of the chain has been characterized by high-output transactions with 1,100 outputs, paying the same conventional fee as a transaction with 2 outputs.

    The objective of the new fee policy, once it is enforced, is for fees paid by transactions to fairly reflect the processing costs that their inputs and outputs impose on various participants in the network. This will tend to discourage usage patterns that cause either intentional or unintentional denial of service, while still allowing low fees for regular transaction use cases.

    -

    The proposed upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. This involves adaptation for the transfer protocol 6, as well as additional considerations for the issuance protocol 7 such as fees for asset issuance.

    -

    Specifically, the ZSA 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, we believe that 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 7, 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.

    +

    Revision 1:

    +

    The upgrade to the OrchardZSA protocol will also need to define a fee structure consistent with the above objectives. This involves adaptation for the transfer protocol 6, as well as additional considerations for the issuance protocol 7 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 7, 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

      @@ -55,11 +57,17 @@
    • The fee for a transaction should scale linearly with the number of inputs and/or outputs.
    • Users should not be penalised for sending transactions constructed with padding of inputs and outputs to reduce information leakage. (The default policy employed by zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool used by the transaction).
    • Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input.
      • -
    • Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets.
      • -
    • Post the upgrade to the ZSA protocol, users should be discouraged from finalizing Assets frivolously.
      • +
    • 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.
      • +
    • Revision 1: 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

    +

    Revisions

    +
      +
    • Revision 0: The initial version of this specification.
      • +
    • Revision 1: This version adds to the fees mechanism post the adoption of the OrchardZSA Protocol. It adds additional fee considerations for the issuance and finalization of custom Zcash Shielded Assets.
      • +
    +

    Notation

    Let \(\mathsf{min}(a, b)\) @@ -285,14 +293,13 @@

    -

    ZSA Fee calculation

    -

    In addition to the parameters defined in the Fee calculation section, the ZSA protocol upgrade defines the following additional parameters:

    +

    Revision 1: OrchardZSA Fee calculation

    +

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

    - @@ -301,18 +308,8 @@ \(issuance\_fee\) - - - - - - + \(100 \cdot marginal\_fee\) + per issuance action (as defined below)
    Parameter ValueUnits
    - \(1000000\) - zatoshis per issuance action (as defined below)
    - \(finalize\_fee\) - - \(1000000\) - zatoshis per issuance action (as defined below)
    @@ -323,12 +320,11 @@ zsa\_logical\_actions &=& logical\_actions \;+ \\ & & nTotalOutputsZsaIssuance \\ zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions \;+ \\ - & & finalize\_fee \cdot nFinalizeActions + & & issuance\_fee \cdot nCreateActions \end{array}\) -

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3. They are defined in the Fee calculation section above, with additional definitions in the table below. Note that +

    The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 3 and the global . They are defined in the Fee calculation section above, with additional definitions in the table below. Note that \(nOrchardActions\) - is redefined and now combines both the Orchard actions for ZEC values as well as ZSA transfer actions for transfer of Assets.

    + is redefined and now combines the actions for native ZEC as well as OrchardZSA transfer actions for Custom Assets.

    @@ -343,32 +339,29 @@ \(nOrchardActions\) - + - + - - - - - - +
    numberthe number of ZSA transfer actions (including ZEC actions)the number of OrchardZSA transfer actions (including ZEC actions)
    \(nTotalOutputsZsaIssuance\) numberthe total number of ZSA issuance outputs (added across issuance actions)the total number of OrchardZSA issuance outputs (added across issuance actions)
    - \(nIssueActions\) + \(nCreateActions\) numberthe number of ZSA issuance actions
    - \(nFinalizeActions\) - numberthe number of ZSA issuance actions that set the finalize flagthe number of OrchardZSA issuance actions that issue a Custom Asset that is not present in the Global Issuance State

    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.

    +

    Transaction relaying

    zcashd, zebrad, and potentially other node implementations, implement fee-based restrictions on relaying of mempool transactions. Nodes that normally relay transactions are expected to do so for transactions that pay at least the conventional fee as specified in this ZIP, unless there are other reasons not to do so for robustness or denial-of-service mitigation.

    @@ -562,8 +555,8 @@

    zebra uses a similar relay threshold rule to zcashd, but additionally enforces a minimum fee of 100 zatoshis (this differs from zcashd only for valid transactions of less than 1000 bytes, assuming that zcashd uses its default value for -minrelaytxfee).

    -

    Deployment of ZSA changes

    -

    The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of the deployment of the ZSA protocol (ZIP 226 6 and ZIP 227 7), which is currently projected to be with Network Upgrade 6.

    +

    Revision 1: Deployment of OrchardZSA changes

    +

    The parts of this ZIP that list out changes to the fee mechanism for the OrchardZSA protocol SHOULD be deployed at the time of deployment of the OrchardZSA protocol (ZIP 226 6 and ZIP 227 7), which is currently projected to be with Network Upgrade 7.

    Considered Alternatives

    @@ -592,9 +585,9 @@ \(grace\_actions\) threshold. This is no longer expressible with the formula specified above.)

    -

    ZSA Fee Considerations

    +

    Revision 1: 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 ZSA 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.

    +

    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.

    Endorsements

    The following entities and developers of the listed software expressed their support for the updated fee mechanism:

    diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 664789243..40b00e571 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -12,7 +12,7 @@ Jonathan Rouach Pablo Kogan Vivek Arte - Status: Draft + Status: Revision 0: Active, Revision 1: Draft Category: Standards / Wallet Obsoletes: ZIP 313 Created: 2022-08-15 @@ -52,7 +52,7 @@ The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users. -This ZIP also explicitly defines the fee mechanism associated with the Zcash Shielded Assets (ZSA) protocol as described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. +Revision 1 of 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]_. Motivation @@ -75,11 +75,19 @@ impose on various participants in the network. This will tend to discourage usage patterns that cause either intentional or unintentional denial of service, while still allowing low fees for regular transaction use cases. -The proposed upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. 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. +Revision 1: +----------- -Specifically, the ZSA 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, we believe that there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. +The upgrade to the OrchardZSA protocol will also need to define a fee structure consistent with the above objectives. +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. -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. +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 @@ -95,14 +103,24 @@ Requirements two inputs and two outputs for each shielded pool used by the transaction). * Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input. -* Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets. -* Post the upgrade to the ZSA protocol, users should be discouraged from finalizing Assets frivolously. +* 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. +* Revision 1: 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 ============= +Revisions +--------- + +* Revision 0: The initial version of this specification. +* Revision 1: This version adds to the fees mechanism post the adoption of the OrchardZSA Protocol. + It adds additional fee considerations for the issuance and finalization of custom Zcash Shielded Assets. + Notation -------- @@ -290,16 +308,15 @@ potential denial-of-service attacks. -ZSA Fee calculation -------------------- -In addition to the parameters defined in the `Fee calculation`_ section, the ZSA protocol upgrade defines the following additional parameters: +Revision 1: OrchardZSA Fee calculation +-------------------------------------- +In addition to the parameters defined in the `Fee calculation`_ section, the OrchardZSA protocol upgrade defines the following additional parameters: -===================================== =============== =============================================== -Parameter Value Units -===================================== =============== =============================================== -:math:`issuance\_fee` :math:`1000000` zatoshis per issuance action (as defined below) -:math:`finalize\_fee` :math:`1000000` zatoshis per issuance action (as defined below) -===================================== =============== =============================================== +===================================== ========================================================================== +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 per the following formula: @@ -310,26 +327,34 @@ calculated in zatoshis per the following formula: zsa\_logical\_actions &=& logical\_actions \;+ \\ & & nTotalOutputsZsaIssuance \\ zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions \;+ \\ - & & finalize\_fee \cdot nFinalizeActions + & & issuance\_fee \cdot nCreateActions \end{array} The inputs to this formula are taken from transaction fields defined in the Zcash protocol -specification [#protocol-txnencoding]_. They are defined in the `Fee calculation`_ section above, with additional definitions in the table below. Note that :math:`nOrchardActions` is redefined and now combines both the Orchard actions for ZEC values as well as ZSA transfer actions for transfer of Assets. +specification [#protocol-txnencoding]_ and the global . They are defined in the `Fee calculation`_ section above, with additional definitions in the table below. +Note that :math:`nOrchardActions` is redefined and now combines the actions for native ZEC as well as OrchardZSA transfer actions for Custom Assets. -================================ ====== ======================================================================== +================================ ====== ============================================================================================================= Input Units Description -================================ ====== ======================================================================== -:math:`nOrchardActions` number the number of ZSA transfer actions (including ZEC actions) -:math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) -:math:`nIssueActions` number the number of ZSA issuance actions -:math:`nFinalizeActions` number the number of ZSA issuance actions that set the ``finalize`` flag -================================ ====== ======================================================================== +================================ ====== ============================================================================================================= +: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 +================================ ====== ============================================================================================================= 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. + Transaction relaying -------------------- @@ -589,10 +614,11 @@ enforces a minimum fee of 100 zatoshis (this differs from `zcashd` only for valid transactions of less than 1000 bytes, assuming that `zcashd` uses its default value for ``-minrelaytxfee``). -Deployment of ZSA changes -------------------------- +Revision 1: Deployment of OrchardZSA changes +-------------------------------------------- -The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of the deployment of the ZSA protocol (ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_), which is currently projected to be with Network Upgrade 6. +The parts of this ZIP that list out changes to the fee mechanism for the OrchardZSA protocol SHOULD be deployed at the time of deployment +of the OrchardZSA protocol (ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_), which is currently projected to be with Network Upgrade 7. Considered Alternatives @@ -618,12 +644,12 @@ Possible alternatives for the parameters: of inputs/outputs to be non-proportional above the :math:`grace\_actions` threshold. This is no longer expressible with the formula specified above.) -ZSA Fee Considerations -====================== +Revision 1: 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 ZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. +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.