We are on track to launch the Zcash currency on October 28th. Recently, we shared our vision of Zcash as a consensual currency: users are always free to run software from whichever developers they choose. Now, before Zcash launches, is a perfect time for us to share some of our visions for how we propose to evolve Zcash.
Upgrade Strategy
The most important overarching theme of our future protocol plans is that we intend to deprecate old protocol versions. This will allow us to introduce features that old clients do not recognize, as well as removing old behavior when it’s no longer advantageous to retain.
This is sometimes referred to as a hard forking upgrade although we prefer to avoid the term fork because it’s both highly-conflated and often repeated in highly contentious debates. The term fork itself can mean at least any of the following:
- diverging software revisions,
- persistently diverging blockchain histories,
- diverging communities.
These are orthogonal to each other. For example, a single coherent community may maintain multiple divergent software codebases, or diverging blockchain histories might be supported by a single codebase (e.g. parity after the divergence of ETH and ETC).
We believe that the protocol upgrades we propose will be acceptable to almost all participants. More importantly, the upgrades will not be unacceptable to a significant population. Whenever this is true, blockchain divergence will be short-lived and the community will continue undivided.
At some point, a proposed upgrade may not be so clearly desired by all participants. Even in this scenario, a proposed upgrade may still provide benefits that outweight the drawbacks (e.g. confusion caused by diverging blockchains). If that’s the case, we may still advocate for the upgrade and release software for it. Or, we may decide the risk of a blockchain divergence outweighs the benefit.
One final note about our upgrade strategy: we believe it’s possible to have a single coherent Zcash community even if the blockchain diverges, so if we forsee a blockchain divergence, one of our focuses will be in collaborating between the subcommunities participating in each side.
Potentially Surprising Upgrades
Given that we plan to propose upgrades that will deprecate older protocol implementations, it’s important to let people know what kinds of upgrades we plan well in advance, in order to set expectations appropriately. The following examples are not comprehensive, nor are they the coolest or most exciting upgrades on our radar. Rather they are a selection of upgrades we expect will surprise some fraction of potential users, and are thus the most important to communicate before Zcash launches.
Mining
We already intend to alter our mining system, at the very least by altering the Equihash parameters. In the future we may even advocate more drastic changes, such as moving to a different proof-of-work system or even proof-of-stake, if we believe those alternatives are feasible, secure, and have better economic effects.
Founders’ Reward
If the Founders’ Reward were to suffer a severe flaw or if our keys were stolen or compromised, we would advocate an upgrade to repair the damage.
Counterfeit Detection
Any currency with strong privacy carries a risk of undetected counterfeiting [1]. For any security system, a crucial complement to prevention is detection. We’ve started sketching out several potential protocol upgrades for counterfeit detection. These will allow all users to potentially detect, and in some cases to limit, counterfeiting due to security breakthroughs.
Some of the counterfeit detection schemes we’ve considered rely on expiring old, abandoned funds (i.e. users might need to take action to ensure that their dormant funds are not flagged as expired).
Removing Technical Debt
Zcash is derived from the Bitcoin Core code and design. We chose this implementation path in order to benefit from a battle-tested, conservative design and codebase. Because we will be proposing upgrades which deprecate features, we will have the opportunity to remove technical debt when it seems safe and beneficial to do so [2].
…and More
As mentioned earlier, this list is not comprehensive. We may advocate for other upgrades which may surprise some users, which aren’t listed here. The ideas above are merely what we consider fairly likely and the most “surprising” potential upgrades. And remember, these aren’t the coolest potential upgrades. 😉
Future Evolution
We’ve presented here a taste of the kinds of upgrades we may advocate for in the future. Keep in mind, we also plan to change our technical strategy appropriately as Zcash grows.
For example, if the userbase remains relatively small with a few niche use cases, we may promote more rapid evolution of features. However, if Zcash were to grow to many stakeholders encompassing many different use cases, this would imply the design at that time was already successful at supporting economic weight, and we would likely adopt a more conservative strategy.
One final thought: we’ve discussed here and in the consensual currency post how we intend to propose changes that anyone is free to adopt, but we haven’t yet clarified how proposals will be made, what the decision process will look like, and how we’ll solicit input from stakeholders. That’s a topic for another post.
—Nathan Wilcox, 2016-10-18
Footnotes:
| [1] | Different privacy systems have different attack surfaces which, if compromised, lead to counterfeiting. For Zcash the attack surfaces include the initial parameter setup, the security assumptions supporting soundness of zk-SNARK proofs, and the zk-SNARK circuit construction that maintains the currency balance rules for shielded transactions. When analyzing fungible currency systems, it is important to determine the attack surface for counterfeiting vulnerability. |
| [2] | The Bitcoin community maintains a wishlist for just this purpose. We have the opportunity to test these clean-ups in our live network so that Bitcoin community can learn from our successes and mistakes. |