As part of the Zcash Improvement Proposal and Network Upgrade Pipeline, Electric Coin Co. (ECC) is publishing our commitment of company resources to proposals for the Network Upgrade 4 (NU4), due to activate in November 2020. We reviewed these proposed features with the Zcash Foundation and reached agreement on the inclusion of the ZIPs outlined here, subject to the outcome of security audits.
About feature selection
The primary impetus for NU4 is to implement protocol and consensus-level changes related to the advent of the Zcash Development Fund (a.k.a. the Dev Fund) which is outlined in ZIP 1014.
For other ZIPs not related to the Dev Fund, ECC answered these questions:
- Is the ZIP sufficiently specified, such that it could be successfully implemented in NU4?
- Does the ZIP introduce an unacceptable level of risk or complexity given the criticality of successful implementation of the Dev Fund related ZIPs in NU4?
- Do we believe the impact of the ZIP will be a net benefit for Zcash?
- For those ZIPs that are sufficiently specified, that do not introduce an unacceptable level of risk, and which we approve of, which will ECC commit to designing, implementing, auditing, and testing, to deploy safely and on time for NU4?
There are some nuances to these answers, especially for Questions 2 and 3, which involves a lot of discretionary judgment. For example, a ZIP may be well specified, and we may approve of the general idea, yet a specific ZIP may have some detail that impacts use cases or tradeoffs in a way we find unacceptable or introduces a level of complexity we find too risky at the current time.
NU4 ZIPs that ECC will implement
The following are proposals which we believe are well-specified, which do not introduce an unacceptable level of risk, which we judge to be a net benefit for Zcash, and to which ECC will commit our resources to deploying in NU4:
Dev Fund ZIPs
ZIP 207 – Funding streams
[link] This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights. This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214. It should be read in conjunction with ZIP 1014, which describes the high-level requirements for that fund.
ZIP 214 – Consensus rules for a Zcash development fund
[link] This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years. An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed upon by ECC, ZF and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.
ZIP 251: Deployment of the ${NU4} Network Upgrade
[link] This proposal defines the deployment of the ${NU4} network upgrade. Note that the network handshake and peer management mechanisms defined in ZIP 201 also apply to this upgrade.
Other ZIPs
ZIP 211 – Disabling addition of new value to the Sprout value pool
[link] This would be a step in the process of ensuring that Sprout funds would migrate out of the Sprout shielded pool whenever the owners decided to move those funds. It prevents new funds from entering the Sprout pool by shielding transactions. It does not prevent transfers within the Sprout pool.
ZIP 212 – Transfer Sapling ephemeral secret to recipient in note plaintext
[link] This protects against a subtle, theoretical privacy weakness related to the use of diversified addresses. This also fixes an obstacle in developing a comprehensive security argument for Zcash privacy properties. Specifically, the goal of this is to avoid an assumption on zk-SNARK knowledge soundness in order to prevent an interactive attack that could link together diversified addresses.
ZIP 215 – Fix Ed25519 validation rules to allow batch verification
[link] Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and RFC-conformant implementations need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature verification from an obsolete version of libsodium. Instead, this ZIP clears the situation by explicitly defining the Ed25519 verification criteria and changing them to be compatible with batch verification
ECC is excited to see the Dev Fund era begin post NU4 and we look forward to collaborating with other developers and teams on future network upgrades. Finally, we’re learning and refining the network upgrade process through each cycle and look forward to working with the ecosystem to define a more agile process while retaining the safeguards that have provided several successful upgrades throughout the years. We’re excited about the future of Zcash and look forward to working with the community and major grant recipients on NU5!
