From 27f84b54f8b813a9fd596ced2bb67921afd07537 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 5 Oct 2024 02:23:21 +0530 Subject: [PATCH 1/5] re-writing in the form of Revisions to the original ZIP. Also writing the issuance_fee as a multiple of the marginal_fee --- rendered/zip-0317.html | 35 +++++++++++++++----------- zips/zip-0317.rst | 57 ++++++++++++++++++++++++++---------------- 2 files changed, 57 insertions(+), 35 deletions(-) diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index 1646228c1..bda666c8f 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 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 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 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, 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

Specification

+

Revisions

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

Notation

Let \(\mathsf{min}(a, b)\) @@ -285,7 +292,7 @@

-

ZSA Fee calculation

+

Revision 1: ZSA Fee calculation

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

@@ -301,7 +308,7 @@ \(issuance\_fee\) @@ -310,7 +317,7 @@ \(finalize\_fee\) @@ -323,7 +330,7 @@ zsa\_logical\_actions &=& logical\_actions \;+ \\ & & nTotalOutputsZsaIssuance \\ zsa\_conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\ - & & issuance\_fee \cdot nIssueActions \;+ \\ + & & 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. Note that @@ -562,8 +569,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 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 7.

Considered Alternatives

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

-

ZSA Fee Considerations

+

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

diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 664789243..13287bd66 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 Zcash Shielded Assets (ZSA) 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 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. -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 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, 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,21 @@ 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. +* 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 ZSA Protocol. + It adds additional fee considerations for the issuance and finalization of custom Zcash Shielded Assets. + Notation -------- @@ -290,16 +305,16 @@ potential denial-of-service attacks. -ZSA Fee calculation -------------------- +Revision 1: ZSA Fee calculation +------------------------------- In addition to the parameters defined in the `Fee calculation`_ section, the ZSA 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 Units +===================================== ================================ =============================================== +:math:`issuance\_fee` :math:`100 \cdot marginal\_fee` zatoshis per issuance action (as defined below) +:math:`finalize\_fee` :math:`20 \cdot marginal\_fee` zatoshis 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,7 +325,7 @@ 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 \;+ \\ + & & issuance\_fee \cdot nIssueActions \;- \\ & & finalize\_fee \cdot nFinalizeActions \end{array} @@ -589,10 +604,10 @@ 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 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. +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 7. Considered Alternatives @@ -618,8 +633,8 @@ 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: 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. From 98fb4d003c3435c1be7b18cb92b72a0846875e84 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 2 Nov 2024 11:22:34 +0530 Subject: [PATCH 2/5] adding rationale and removing the finalization fee --- rendered/zip-0317.html | 39 ++++++++++++--------------------------- zips/zip-0317.rst | 40 ++++++++++++++++++++++++---------------- 2 files changed, 36 insertions(+), 43 deletions(-) diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index bda666c8f..56dd90f09 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -299,7 +299,6 @@
- @@ -309,17 +308,7 @@ - - - - - - + per issuance action (as defined below)
- \(1000000\) + \(100 \cdot marginal\_fee\) zatoshis per issuance action (as defined below)
- \(1000000\) + \(20 \cdot marginal\_fee\) zatoshis per issuance action (as defined below)
Parameter ValueUnits
\(100 \cdot marginal\_fee\) - zatoshis per issuance action (as defined below)
- \(finalize\_fee\) - - \(20 \cdot marginal\_fee\) - zatoshis per issuance action (as defined below)
@@ -330,12 +319,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 ZSA transfer actions for Custom Assets.

@@ -350,7 +338,7 @@ \(nOrchardActions\) - + - - - - - - +
numberthe number of ZSA transfer actions (including ZEC actions)the number of OrchardZSA transfer actions (including ZEC actions)
@@ -361,21 +349,18 @@
- \(nIssueActions\) + \(nCreateActions\) numberthe number of ZSA issuance actions
- \(nFinalizeActions\) - numberthe number of ZSA issuance actions that set the finalize flagthe number of ZSA 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 ZSA Fee calculation

+

The ZSA fee calculation accounts for the additions to the Global Issuance State that are required for the ZSA 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.

@@ -570,7 +555,7 @@

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

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

+

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

Considered Alternatives

diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 13287bd66..e1bae5ecf 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -309,12 +309,11 @@ Revision 1: ZSA Fee calculation ------------------------------- In addition to the parameters defined in the `Fee calculation`_ section, the ZSA protocol upgrade defines the following additional parameters: -===================================== ================================ =============================================== -Parameter Value Units -===================================== ================================ =============================================== -:math:`issuance\_fee` :math:`100 \cdot marginal\_fee` zatoshis per issuance action (as defined below) -:math:`finalize\_fee` :math:`20 \cdot marginal\_fee` 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: @@ -325,26 +324,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 ZSA transfer actions for Custom Assets. -================================ ====== ======================================================================== +================================ ====== ============================================================================================================= Input Units Description -================================ ====== ======================================================================== -:math:`nOrchardActions` number the number of ZSA transfer actions (including ZEC actions) +================================ ====== ============================================================================================================= +:math:`nOrchardActions` number the number of OrchardZSA 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:`nCreateActions` number the number of ZSA 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 ZSA Fee calculation +''''''''''''''''''''''''''''''''' + +The ZSA fee calculation accounts for the additions to the Global Issuance State that are required for the ZSA 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 -------------------- @@ -607,7 +614,8 @@ default value for ``-minrelaytxfee``). Revision 1: 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 7. +The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of deployment +of the ZSA protocol (ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_), which is currently projected to be with Network Upgrade 7. Considered Alternatives From 6593ac64d4e5aad561bb55c3c9cc34ae699f0741 Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Sun, 3 Nov 2024 17:34:24 +0530 Subject: [PATCH 3/5] Update zips/zip-0317.rst based on review Co-authored-by: Daira-Emma Hopwood --- 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 e1bae5ecf..4b6b6fb29 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -78,7 +78,7 @@ while still allowing low fees for regular transaction use cases. Revision 1: ----------- -The upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. +The upgrade introducing 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. From abe1fb53fa28f665198f109db19351d4f966c25c Mon Sep 17 00:00:00 2001 From: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> Date: Sun, 3 Nov 2024 17:39:00 +0530 Subject: [PATCH 4/5] Update zips/zip-0317.rst based on review Co-authored-by: Daira-Emma Hopwood --- zips/zip-0317.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst index 4b6b6fb29..7d5e9b39f 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -103,6 +103,9 @@ 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. +* 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. From 441d9154a1a2dbade4a52536a78b7521b03a1f41 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 3 Nov 2024 17:51:43 +0530 Subject: [PATCH 5/5] further review changes --- rendered/zip-0317.html | 31 ++++++++++++++++--------------- zips/zip-0317.rst | 40 ++++++++++++++++++++-------------------- 2 files changed, 36 insertions(+), 35 deletions(-) diff --git a/rendered/zip-0317.html b/rendered/zip-0317.html index 56dd90f09..3305e9203 100644 --- a/rendered/zip-0317.html +++ b/rendered/zip-0317.html @@ -39,15 +39,15 @@

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.

-

Revision 1 of this ZIP additionally 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.

Revision 1:

-

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

@@ -57,6 +57,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.
    • +
  • 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.
    • @@ -64,7 +65,7 @@

    Revisions

    Notation

    @@ -292,8 +293,8 @@
    -

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

    @@ -323,7 +324,7 @@ \end{array}\)

    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 the actions for native ZEC as well as ZSA transfer actions for Custom Assets.

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

    @@ -345,20 +346,20 @@ \(nTotalOutputsZsaIssuance\) - + - +
    numberthe total number of ZSA issuance outputs (added across issuance actions)the total number of OrchardZSA issuance outputs (added across issuance actions)
    \(nCreateActions\) numberthe number of ZSA issuance actions that issue a Custom Asset that is not present in the Global Issuance Statethe 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 ZSA Fee calculation

    -

    The ZSA fee calculation accounts for the additions to the Global Issuance State that are required for the ZSA 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.

    +

    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.

    @@ -554,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).

    -

    Revision 1: 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 deployment of the ZSA protocol (ZIP 226 6 and ZIP 227 7), which is currently projected to be with Network Upgrade 7.

    +

    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

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

    -

    Revision 1: 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 7d5e9b39f..40b00e571 100644 --- a/zips/zip-0317.rst +++ b/zips/zip-0317.rst @@ -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. -Revision 1 of this ZIP additionally 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 @@ -78,10 +78,10 @@ while still allowing low fees for regular transaction use cases. Revision 1: ----------- -The upgrade introducing the ZSA protocol will also need to define a fee structure consistent with the above objectives. +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. -Specifically, the ZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. +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. @@ -118,7 +118,7 @@ Revisions --------- * Revision 0: The initial version of this specification. -* Revision 1: This version adds to the fees mechanism post the adoption of the ZSA Protocol. +* 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 @@ -308,9 +308,9 @@ potential denial-of-service attacks. -Revision 1: 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 @@ -332,24 +332,24 @@ calculated in zatoshis per the following formula: The inputs to this formula are taken from transaction fields defined in the Zcash protocol 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 ZSA transfer actions for Custom Assets. +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 OrchardZSA transfer actions (including ZEC actions) -:math:`nTotalOutputsZsaIssuance` number the total number of ZSA issuance outputs (added across issuance actions) -:math:`nCreateActions` number the number of ZSA issuance actions that issue a Custom Asset that is not present in the Global Issuance State +: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 ZSA Fee calculation -''''''''''''''''''''''''''''''''' +Rationale for OrchardZSA Fee calculation +'''''''''''''''''''''''''''''''''''''''' -The ZSA fee calculation accounts for the additions to the Global Issuance State that are required for the ZSA protocol. +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. @@ -614,11 +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``). -Revision 1: 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 deployment -of the ZSA protocol (ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_), which is currently projected to be with Network Upgrade 7. +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 @@ -644,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.) -Revision 1: 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.