This is the ZIP Editors’ and consensus node implementors’ assessment of the candidate ZIPs proposed for inclusion in NU7, with rationale.
In summary:
- Most of the candidate ZIPs have been determined to be safe, feasible, and useful to include.
- The complexity of the upgrade is significant, primarily due to the ZSA ZIPs, but our assessment is that the community would prefer a slightly delayed NU7 activation over excluding the ZIPs that we have recommended to include.
- There is not a simple relationship between the set of ZIPs included and the likelihood of a delay in activation. Rather, pieces that can be worked on in parallel will all be competing for engineers’ time and attention, to different extents. The most likely factor to cause delay is if there is unanticipated complexity associated with one of the proposals (most likely ZSAs or the associated zcashd deprecation work), or unanticipated interactions between proposals.
- ZIP 231 has a parameter for the maximum total size of memo data. We believe the current recommendation in the ZIP, resulting in a maximum of 16 KiB of memo data in a transaction, is appropriate.
- ZIP 234 inclusion would be conditional on Shielded Labs.
- ZIP 235 would benefit from polling to determine community sentiment.
- We suggest considering to modify ZIP 227 to specify that issuance fees be burned in accordance with ZIP 233, instead of being paid to miners.
- Both ZIP 234 and ZIP 235 impose costs on miners relative to these ZIPs not being included (and dependent on time within the prior halving schedule in the case of ZIP 234). If the rest of the community wishes to include either or both of these changes, the community should attempt to understand the likely responses of mining pools, as an input to its decision.
- ZIP 2004 should be deferred to NU8.
We recommend final selection of ZIPs by mid-December after community polling for:
- Whether ZIP 235 will be included.
- Whether ZSA issuance fees will be burned.
- Any other feedback on the proposed inclusions that those running polls choose to ask for.
However, we believe that consensus implementation of most ZIPs can begin now.
| ZIP | Primary Implementor | Safe, feasible, and useful to include | Safety & Feasibility Rationale | Usefulness Rationale |
|---|---|---|---|---|
| 230: v6 tx | ECC/ZF | Yes | Node implementors have experience of making similar tx format changes before. The mechanisms for doing so safely were defined in ZIPs 200 and 202. | Necessary for ZSAs. Also enables ZIPs 231, 233, 235, and 2002. |
| 226: ZSA Transfer and Burn | QEDit | Yes | Large but manageable complexity cost (including wallets, not just consensus). The move to Halo 2 was in part motivated by enabling this kind of circuit upgrade without needing a new trusted setup. Node implementors have committed to put in the work to make ZSAs safely deployable. | Major addition of functionality allowing new use cases. Strong community support demonstrated by polls and by enthusiasm on the forum and social media. |
| 227: ZSA issuance | QEDit | Yes | Fees for ZSA issuance should be reconsidered in the light of ZIP 233 and ZIP 234; it may be preferable for ZSA issuance fees to be largely burned instead of being paid to the miner that includes the issuance transaction. | |
| 231: Memo Bundles | ECC/ZF | Yes | Non-trivial but has minimal interaction with the transaction format outside of its self-contained memo bundle. Updating wallets to handle receiving longer memos does not need to be on the critical path. We advise accepting the current recommendation of a 16 KiB limit on memo data in a transaction. | Strong motivation in order to enable applications needing proofs in memos, such as authenticated reply addresses and voting. |
| 233: NSM burnAmount Field | Shielded Labs | Yes | Trivial addition to tx format. Non-trivial change to consensus rules, but that only affects Zebra. | Allows experimentation with burning-based fee mechanisms without further consensus changes. |
| 234: NSM Issuance Smoothing | Shielded Labs | Conditional yes; Shielded Labs would need to commit to doing the work to ensure the entire ecosystem is upgraded to be aware of the change. | Potential negative economic effects leading to downward price pressure are mitigated by delaying the issuance change until the new curve crosses the old one. However, there is a possible interaction in the amount of issuance available for staking and mining if TFL is implemented. Will require changes to large parts of the ecosystem (miners, block explorers, metrics providers). Previous changes to block subsidies in Blossom and Canopy were carefully constructed to not alter the issuance curve as a function of time. Even with that precaution, there were some consequent issues with block explorers and metrics providers not calculating issuance correctly as a function of block height. | Provides a mechanism to allow unissued funds to be reissued, and potentially reduces the economic unpredictability that would otherwise arise from halving events. |
| 235: NSM Fee Burning | Shielded Labs | Inclined toward no; based on a combination of Safety and Usefulness issues, there is insufficient reason in our opinion to make this change in an otherwise heavy upgrade. (ZSAs make this upgrade heavy regardless of which other ZIPs are selected.) | Burning fees is just as effective as giving them to miners to disincentivize denial-of-service attacks, and so that does not present a safety issue. The remaining portion (40%) of transaction fees accruing to miners is probably still sufficient to incentivize tx inclusion in mined blocks, but there remains a risk that some miners could create empty blocks in response. We also have little time and are lacking information to analyze long-term economic effects. The lack of information could be helped by deploying ZIP 233 and (if accepted) 234 first. | The amount involved is very low (as calculated in the ZIP), and so the rationale points given in the ZIP imply limited benefit in the short-term. Zcash will not have problems associated with low mining reward relative to fees for many years, and we would still reap any long-term benefits if this were deferred until NU8. Also most of the same effect can be obtained via other non-consensus mechanisms (mempool and wallet behaviour) so long as ZIP 233 is included. ZIPs 233 and 234 are not dependent on including this ZIP. |
| 2002: Explicit Fees | ECC/ZF | Yes | Trivial addition to tx format. Just one extra consensus rule to constrain against something already computed. | Allows non-consensus software to compute fees more simply and without chain context. |
| 2003: Disallow V4 Transactions | ECC/ZF | Yes | Trivial consensus change. The v5 format will have been usable for >3 years by NU7 activation, and there will be sufficient time for v4-dependent software to move to it. Sprout is now barely used, and no wallets currently support it except the zcashd internal wallet; none will support it after zcashd deprecation. | Reduces protocol complexity and attack surface, which is important for maintainability and security analysis of the protocol specification and node software. The usage of Sprout no longer justifies its costs. |
| 2004: Remove consensus dependency on note encryption | ECC/ZF | No; defer to NU8 | Defer to NU8 to decrease short-term complexity. This change could have interacted with ZIP 231; we no longer need to think about that interaction. | Useful longer-term simplification but can be deferred. The ZIP Owner (Daira-Emma) is not pushing for it in NU7. |