[ZIP 317] Proportional Transfer Fee Mechanism

[nighthawk24]

Pinging @daira & @nuttycom for help with updating the wording and spec for this ZIP.

[pacu]

There's an important takeaway on the Support section, please review and clarify.

[nathan-at-least]

At ECC we're aligned that ZIP-317 with the right parameters and adjustments can be a helpful step, and we intend to help refine the ZIP to meet our proposed goals and trade-offs.

Importantly, however, we're unsure how much this ZIP by itself will improve usage behavior and network performance, especially because tuning the fee parameters effectively depends on a wide array of users and use cases with limited information:

If the fee parameters are too low, there may be no change in usage patterns. If they are too high, this may inhibit organic usage. Likewise, if the grace_window_size is too large, then either fees will be too high for "typical" usage, or there may not be sufficient disincentives to improve network performance. Meanwhile, if the window is too low, this impairs privacy and wallet note management to improve UX.

So, we are also anticipating follow up changes to the fee system, such as adjusting the fee parameters with the same scheme in this ZIP or introducing new schemes.

Here's our recommendations and the follow up tasks we will take, or that we request others to take, in support of ZIP 317:

Goal

Re recommend keeping the ZIP focused and tightly scoped to address the current pain points with minimal other impacts or changes. One notable exception is the grace_window_size, see Rationales next.

We also have an intention to collaborate across the Zcash community on other changes to the fee system to meet other potential goals in the future.

Rationales

• General:
  • Cost per input/output makes the network more resilient for all kinds of usage with different arities.
  • Cost change to "typical" users sending from shielded mobile should be minimally impactful.
  • Rist to high arity usage patterns needs to be considered and carefully observed. This might impact use cases for mining pools, miners, exchanges, fund raising, memo-based applications, and more.
  • Risk to some transparent wallets should be acceptable, though we need more research here. We assume many transparent wallets will be slow to adopt this change. We'll be posting some on-chain analytics around this to determine what fraction of recent transactions would be negatively impacted by this change.
• grace_window_size: this achieves three goals which are not directly related to addressing the current performance issues, but we believe these goals need to be balanced against addressing the current performance issues. Also they are well understood and simple enough to include that we make an exception to the tight scoping goal. All of these goals are facilitated by grace_window_size by allowing wallets to use "free" input/output slots opportunistically to:
  • add dummy inputs/outputs to improve privacy,
  • include more inputs/outputs than strictly necessary to facilitate note management,
  • and include "dust" inputs whose value is below marginal_fee. (Without this window, every input would be charged marginal_fee making any note/UTXO less than that value unusable.)

What we recommend

High-level

• "usage neutrality" so long as the results are secure and economical.
  • Don't express a preference for lower/higher arity, with the exception of the grace_window_size floor.
• Keep this proposal tightly focused on addressing the current performance / UX issues as simply as possible without adding other goals (ex: incentivizing shielded adoption, migration to orchard, etc…)
  • Note: some of those other goals are valuable, and we believe we should work on thos later after addressing the current acute pain points.

Specifics

• Apply the fee policy to all transactions (don't exclude fully transparent transactions)
• Select parameters that don't incentivize transaction splitting, nor making txns larger than necessary, therefore we recommend parameters with base_fee = marginal_fee * grace_window_size. See these hackmd notes to understand why this constraint maintains arity neutrality.
• Another way to then write the formula that obeys this property is max(base_fee, marginal_fee * IO) where IO is the total arity of the transaction (number of inputs + outputs). We believe this formula is easier to understand and explain in natural language, ie: "The fee is marginal_fee for each input or output, or base_fee, whichever is greater."
• Explicitly distinguish deployment areas:
  • Wallets (including zcashd cli wallet):
    • Wallet fee logic and UX updates. Do this ASAP (no need to activate at a block height).
  • Full nodes (which also influences miner behavior):
    • Full node getblocktemplate defaults. (Staged roll-out?)
    • Mempool eviction rules.
    • Full node relay rules, after we're confident this change doesn't hamper a significant number of users.
• We strongly advocate doing explicit impact reviews, transparently as a community, between wallet vs full node deployment stages to learn and react to the impacts, rather than deploying all changes at once.
• [Question for Zip Editors] Sorting out full node changes may take more time. Should we split this into two zips and make the wallet-facing ZIP active sooner to expedite deployment?

Future Work (or non-ZIP context to share in discussion)

• [ECC and/or other devs] Propose specific concrete parameters for base_fee, marginal_fee, and grace_window_size that balance what we know from on-chain analysis (next), user populations, and estimated impacts.
• [ECC] Post on-chain data analysis to understand how historical transaction trends would be impacted by this change.
• [ECC] Post on the status of our current user research and how this ZIP may impact known user populations.
• [ECC and/or other devs] Submit one or more pull requests with the proposed specific changes.
• [ZIP Editors] Help clarify which revision wallets should deploy (this is the proposed first deployment tier).
• [ZIP Editors] Decide if we should split out full node deployment steps into a separate ZIP or keep them here. Keep in mind it's possible we would learn from wallet deployments that we need to adjust full node rules or deployment.
• [ECC] Engage with wallet developers to advocate for adopting this ZIP when the wallet portion is sufficiently defined.

[daira]

[Question for Zip Editors] Sorting out full node changes may take more time. Should we split this into two zips and make the wallet-facing ZIP active sooner to expedite deployment?

I don't really see a need.

Remember that we get no benefit to the network unless and until miners and relayers start enforcing the new fee structure. Therefore, the ZIP only really makes sense if it includes a proposal to do that. ZIPs are not static (unlike RFCs); they can be adjusted according to experience and measurement. But if there is not even a tentative proposal in the ZIP that the new fee be enforced, how can we assess whether it's worth doing at all?

[daira]

This section will need to become a Rationale section briefly saying why we chose these parameters and this formula. When describing the earlier proposed parameters, we will need to take into account that they are not directly comparable with the specified marginal_fee, because they were multiplied by inputs + outputs instead of logical actions.

[daira]

Describe the effect on users of wallets that are not upgraded.

[daira]

Consider deleting some of this section, since the premise of this ZIP is that there is at least some chance that it will work to discourage transaction DoS.