Overview
As part of the Zcash Improvement Proposal and Network Upgrade Pipeline, the Electric Coin Company (ECC) is publishing our assessments of proposals, our official stance on proposals, and our commitment of company resources to proposals for the Network Upgrade 3 (NU3), due to activate in April of 2020.
About Feature Selection
For each ZIP, within ECC, we answered these questions:
- Is the ZIP sufficiently specified, such that it could be successfully implemented in NU3?
- Do we believe the impact of the ZIP will be a net benefit for Zcash? (i.e. Do we approve or oppose the implementation of the ZIP?
- For those ZIPs that are sufficiently specified and which we approve of, which will ECC commit to designing, implementing, auditing, and testing, to deploy safely and on time for NU3?
There are some nuances to these answers, especially for Question 2, 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.
Additionally, we are discovering a variety of shortcomings in the process either internally within ECC, in collaboration with the Zcash Foundation, and while collaborating with ZIP Authors. We describe some of those at the end of this post. Additionally, we plan to hold a retrospective meeting prior to the NU4 ZIP proposal cycle to improve the process iteratively in each cycle.
Feature Selection
The following table summarizes our assessment and is specific to NU3:
| ZIP | Sufficiently Specified | ECC Approves of the Tradeoffs | ECC is committed to implementation |
|---|---|---|---|
| ZIP 213 - Shielded Coinbase | ✓ | ✓ | ✓ |
| ZIP 221 - Adding MMR Proofs to Block Headers, and their use in the FlyClient Protocol | ✓ | ✓ | ✕ |
| ZIP 210 - Sapling Anchor Deduplication within Transactions | ✓ | ✓ | ✕ |
| ZIP 212 - Transfer Sapling Ephemeral Secret to Recipient in Note Plaintext | ✓ | ✓ | ✕ |
| ZIP XXX - Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol | ✕¹ | ✓ | ✕ |
| ZIP ??? - Enable Staked Polling from the Sapling Pool | ✕ | ✓² | ✕ |
| ZIP 211 - Disabling Sprout Outputs | ✓ | ✕ | ✕ |
| ZIP XXX - Threshold shielded multisig | ✓ | ✕³ | ✕ |
Notes:
¹ The main protocol is well-specified, and only two known prerequisites remain unspecified.
² The specific design of onchain voting has significant governance impacts, so our support highly depends on the concrete trade-offs.
³ ECC approves of the general motivation and goal and only reserves full approval pending more feedback with custodial vendors to ensure known use-case support.
NU3 ZIPs that ECC Will Implement
The following are proposals which we believe are well-specified, which we judge to be a net benefit for Zcash, and to which ECC will commit our resources to deploying in NU3:
ZIP 213 - Shielded Coinbase
Rationale: This change enables miners to immediately shield newly-issued ZEC. Miners who do so require one fewer transactions (since unshielded coinbases must first be shielded) for most use cases, providing a positive incentive for adoption of shielded usage, both due to a direct desire for privacy features as well as an incentive of fewer transactions and thus transaction fees.
NU3 ZIPs Ready to Implement
The following are proposals which we believe are well-specified, and which we judge to be a net benefit for Zcash. However, ECC cannot commit to implementing them with our current resources. If any development team is available to see through the development of these, please contact us soon. The first concrete deadline is a complete specification of high enough specificity for a security audit by the end of June.
ZIP 221 - Adding MMR Proofs to Block Headers, and their use in the FlyClient Protocol
Rationale: This change enables multiple use cases, all of which impact adoption:
- Cross-chain and side-chain protocols.
- Light Wallets (such as mobile wallets).
- Full Nodes that use SPV during initial download to remove a significant adoption hurdle.
ZIP 210 - Sapling Anchor Deduplication within Transactions
Rationale: This removes a potential privacy leak and simplifies the transaction format.
ZIP 212 - Transfer Sapling Ephemeral Secret to Recipient in Note Plaintext
Rationale: 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.
NU3 ZIPs Requiring Specification Improvements
The following are proposals which we believe could be a net benefit to Zcash, yet they are not sufficiently specified to include into the NU3 deployment pipeline. We hope to work with the authors as we approach the NU4 proposal deadline to ensure these are sufficiently specified for NU4. Note that we identified multiple shortcomings in the ZIP process and our communication and collaboration around it, so our assessment of these ZIPs does not reflect on the authors so much as our own planning and communication.
ZIP XXX - Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol
Rationale: This change enables the BOLT protocol which provides very-low-latency and cheap transactions within payment channels all while maintaining Zcash’s standards for privacy and safety. This enables new use cases the base Zcash protocol can’t satisfy thus enabling further adoption.
This change is championed by J. Ayo Akinyele and Colleen Swanson of Bolt Labs, reinforcing increasing openness and collaboration of Zcash protocol development.
What Improvements are Needed to the Proposal?
- Integrating OP_CHECKSEQUENCEVERIFY from Bitcoin provides a prerequisite building block for the BOLT proposal. This should be relatively straightforward process of adapting that previous work from Bitcoin into Zcash. if anyone wants to take on a good “entry level” Zcash protocol improvement project.
- We need a transaction malleability fix specified that’s sufficient for the BOLT case.
ZIP ??? - Enable Staked Polling from the Sapling Pool
Rationale: If implemented well, this would enable a powerful stake-weighted voting mechanism which preserves privacy. This could be a building block for future protocol-development decision making, and could also be used for decision making in other areas of interest.
What Improvements are Needed for this Proposal? This proposal includes the goal and motivation yet lacks a specific design or approach. In order to evaluate whether ECC would approve or oppose a ZIP it must be specific enough to evaluate the tangible trade-offs.
ZIP 211 - Disabling Sprout Outputs
Rationale: This change would ensure that Sprout funds would migrate out of the Sprout shielded pool whenever the owners decided to move those funds, and it would prevent the creation of any new Sprout funds (either by shielding or transferring within the Sprout pool).
What Improvements are Needed for this Proposal? The current version actually implements something subtly different: it prevents new funds from entering the Sprout pool by shielding transactions. It does not prevent transfers within the Sprout pool. This proposal can be improved by implementing the title and rationale as written here.
ZIP XXX - Threshold shielded multisig
Rationale: Provide support for several known uses cases that require threshold signatures in a privacy-preserving manner. Known use cases include custodian vendor support.
What Improvements are Needed for this Proposal? ECC wants to explore further if the proposal can meet known use case feedback we’ve received from interactions with vendors.
NU3 ZIPs which ECC Opposes
ECC does not oppose any of the submitted proposals, in so far as they are specified. All of the motivations are clear to us and should the specified technical details present the right trade-offs we would likely approve of them.
Process Shortcomings and Lessons
NU3 is the first Zcash network upgrade following the Network Upgrade Pipeline with established ZIP editorship shared by ECC and Foundation employees. As we go we are learning at each step where to make improvements, and we’d like to share some of our known lessons.
Additionally, ECC plans to engage with the Foundation, ZIP authors from multiple cycles, protocol developers, and anyone interested from the Zcash community in a ZIP and NUP retrospective meeting prior to the NU4 ZIP submission deadline. Keep in mind that this post is ECC’s specific perspective prior to those broader discussions.
Lessons
We’ve noticed ambiguity or miscommunication about what ZIP authors should deliver by each deadline. For example, ECC assessed that several ZIPs were insufficiently specified for inclusion in NU3, yet it wasn’t necessarily apparent to authors what constitutes sufficient specification for Feature Selection. We can improve the process for the next cycle by defining deliverable milestones for each deadline, and potentially by introducing more intermediate milestones.
In this NU3 process so far there have been two substantial milestones for ZIPs: their initial delivery as drafts, and Feature Selection which this post summarizes. In future cycles we’d like to have separate milestones for deciding if a ZIP is sufficiently specified, versus deciding exactly which subset will be implemented by whom. This second stage will especially be important to explicitly separate as multiple implementations deploy to mainnet.
ECC and the Zcash Foundation put substantial effort into analyzing proposals from multiple angles, such as technical review by engineers, product impact assessment, comment by technical advisors, and so forth. This feedback could be channeled to ZIP authors in a more organized fashion to give ZIP authors a better opportunity to digest it. In effect, we need clearer milestone definition and target dates for this feedback to ZIP authors prior to the decision point for sufficient specification.
ZIPs currently did not specify any implementation logistics, most notably who would contribute development effort. This will grow in importance as the Zcash Foundation’s independent node implementation matures, in which case successfully seeing a ZIP from proposal to deployment will require coordinating specification and development across teams. By including some of these considerations earlier in the ZIP process itself, it improves the chance that multiple stakeholders can see a proposal successfully deployed.
We uncovered multiple scoping and inclusion issues. For example, if a ZIP requires a prerequisite of substantial scope, is it acceptable to introduce that prerequisite ZIP after the draft ZIP submission deadline? What about after the Feature Selection deadline? Another example: how much can a ZIP change after each deadline? What if there is a simplification or improvement in a design, but that would potentially impact use cases or tradeoffs while still achieving a broadly similar goal?
Conclusion
We are excited to begin work on design and implementation for NU3. ECC is committed to shipping Shielded Coinbase support and we’re excited to see how this impacts the mining ecosystem and shielded adoption. Additionally, we are open to collaborating with other developers on several ZIPs which are ready to implement for NU3, should those developers show up to contribute. Finally, we’re learning and refining this upgrade process through each cycle. We’re excited to ramp up full pipelining, leading to two network upgrades per year for Zcash!