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:
+
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 Orchard Zcash Shielded Assets (OrchardZSA) protocol as described in ZIP 226 6 and ZIP 227 7.
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 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.
+Let \(\mathsf{min}(a, b)\) @@ -131,7 +155,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:
| Parameter | +Value | +
|---|---|
| + \(issuance\_fee\) + | ++ \(100 \cdot marginal\_fee\) + per issuance action (as defined below) | +
Wallets implementing this specification SHOULD use a conventional fee, viz. + \(zsa\_conventional\_fee\) + , that is calculated in zatoshis per the following formula:
+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 OrchardZSA transfer actions for Custom Assets.
+| Input | +Units | +Description | +
|---|---|---|
| + \(nOrchardActions\) + | +number | +the number of OrchardZSA transfer actions (including ZEC actions) | +
| + \(nTotalOutputsZsaIssuance\) + | +number | +the total number of OrchardZSA issuance outputs (added across issuance actions) | +
| + \(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.
+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.
+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 +370,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).
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.
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 +555,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).
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.
+This section describes alternative proposals that have not been adopted.
@@ -472,7 +569,7 @@ in @nuttycom's proposal.We choose to maintain the native ZEC Asset as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.
+An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. In the context of transparent transactions, such a fee allows miners to “tap into” the ZSA value of the transactions, rather than the ZEC value of transactions. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.
+The following entities and developers of the listed software expressed their support for the updated fee mechanism:
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.
| 6 | +ZIP 226: Transfer and Burn of Zcash Shielded Assets | +
|---|
| 7 | +ZIP 227: Issuance of Zcash Shielded Assets | +
|---|
| 8 | ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis |
|---|
| 7 | +9 | ZIP 401: Addressing Mempool Denial-of-Service |
|---|