I love the spirit of this post.
But let me ask: are you an owner or advocate for the many fully shielded Zcash clones? Why or why not?
Are those fully shielded Zcash clones bringing privacy to more people or is Zcash or some other system?
I believe the answer is that Zcash is a leading contender for bringing privacy to the most people because we’ve been very pragmatic about network effect.
1 year might be enough time and enough of a forcing function to spur upgrades. That would be ideal. OTOH, it carries these risks:
- we might lose product/service support that lose existing users.
- we might lost future product/service support because the barrier to adoption becomes greater.
Degrading network effect means less privacy for fewer people, as @aristarchus also points out. I believe Zcash has more users than fully private Zcash clones partially because of t-addrs (but also because of many other important factors).
For me, adoption is crucial, not just the mere existence of tech, but proof that it works in the market place.
Let’s think about the complexity across the ecosystem to upgrade to shielded:
- exchanges to implement shielded support, even though they often have custom in-house tech for hot wallet, cold storage, and custodian management. Often these involve various Hardware Security Modules (HSMs), which are difficult for ECC or Zfnd engineers to develop for due to proprietary nature. Furthermore exchanges and custodians are quite unlikely to freely collaborate on their core hot wallet code’s HSM integrations without heavy NDAs and stuff. So that means it’s either them doing it on their own, or someone like ECC or Zfnd taking on a legal liability and oversite to help out.
- exchanges to pass those implementations through their legal compliance review cycles. Changes to exchange or custodian architecture (such as might be required by Zcash shielded due to differences in transparent UTXO indexing versus Viewing Key support) are much more difficult to get through this process compared to deploying similar architectures for different coins.
- enough of the 12 wallets listed under transparent only address support need to upgrade. They use different platforms and underlying tech. I’m not sure how many Zcash users each supports. Upgrading isn’t just a matter of replacing a transaction library under the hood (which is already fairly involved) but it also requires modifications to UX. For multi-currency wallets, this means special case UX for Zcash whereas t-addr support can crib from Bitcoin. So it’s not merely a matter of replacing a transaction library, but a full-fledged product modification. (Again, I’m not saying t-addr support and UX is not a hazard, but it is a much lower cost way to integrate Zcash.)
- what about services that let you spend Zcash at retail like Flexa’s SPEDN wallet? Not only do they need “standard” send/receive/balance functionality, but they’ll very likely need new UX flow, for example support for Payment Disclosure flow in the user-facing interface that works for both spender and merchant. The same goes for “Crypto ATM” products like Lamassu, or point-of-sale products. (Tangent: I saw an Anypay video that demos shielded Point-of-Sale support already! If that truly works, that’s excellent progress.)
- Existing multisig users, such as custodians or API services like Bitgo would need to either deploy a new service that doesn’t use multisig (a core feature of Bitgo) or they need to upgrade to a new cryptographic threshold scheme Zfnd engineers and other cryptographic researchers have developed. The new protocol is a great improvement, but it’s unique and different from what Bitgo currently does, so they’ll need to add more special case code, infrastructure, and UX components for their product.
- If we have Ledger support, but not Trezor or other hardware wallets, how many users are supported versus left in the cold? What if a Trezor user stores other cryptocurrencies on their Trezor that aren’t yet supported by Ledger? Is it worth it for them to migrate and manage two hardware wallets, or will they just deposit their cold storage onto an exchange to avoid the headache? In this example, even though “apparent on-chain privacy” has increased, actual privacy decreases because more exchanges control more ZEC.
- Block explorers probably will need UX upgrades. For example, Blockchair.com already implemented a Payment Disclosure UX for Zcash Sprout. This is the only end-user payment disclosure feature I’m aware of.
- We need to be careful of degrading or losing mining support. We want to make sure pool operators are able to do mine-to-shielded and shielded payouts on time, otherwise we risk decimating the hashrate.
- Existing cross-chain protocols which we may not be aware of might have to upgrade and doing so may be very difficult. For example, I just learned of Ren Project’s mainnet which supports a ZEC <-> ETH bridge. I know very little about it, but I am willing to bet 1 ZEC that it relies on t-addrs, and another 1 ZEC that altering their decentralized protocol to support shielded might be a very difficult cryptographic protocol research project.
- Plus, there’s the likelihood of dozens of applications, protocols, and services none of us are aware of with some numbers of users.
Finally, that’s all only about the complexity of deploying the upgrades. What about the incentive? If an exchange can do 5 engineer days of work to integrate Zcash t-addr and then one week of legal compliance work, they’ll do that so long as expected revenue from ZEC trading is high enough. But now, if they are forced to do a lot of heavy lifting in a one year timeframe, if I were them I would look very closely at that substantial cost stacked against ZEC trading revenue. Other factors like strategic factors probably matter, but the bottom line calculation is very important.
I also think people are getting too focused on exchanges compared to all of these other cases I described. The same calculation is true of any multi-currency wallet. How much is Zcash support worth to them versus the effort. If it’s easy to deploy t-addrs because it’s mostly cut’n’paste from Bitcoin, the low cost can be worth the effort even without a large revenue/adoption/traction increase. But now, if they are forced to do a significant amount of work, they will again need to balance their bottom line vs strategic priorities.
Finally, losing network effect doesn’t just mean losing users, and probably a declining price (which slows on-chain development funding), but it can also mean wittling down alternatives and thus centralizing control over parts of the Zcash ecosystem. For example, if only one hardware wallet makes the upgrade on time, users options are reduced, and there’s less competition to improve user options. (Hopefully because Zcash is open and permissionless, the competition can grow back.)
And finally: all of the concerns I lay out in this post are just the downside risk of the equation. As I said, it may be that a forcing function spurs adoption. Maybe if we lost a third of the services or products in each category, but all of the “core categories” retain enough traction, then the benefits of fully shielded will lead to better growth longer term.
One way to think of it: if Zcash commits to going fully shielded in 12 months, how long will it take the growth rate to surpass the existing trajectory? If it takes 6 months, 12 months, or 48 months, does that change our thinking about when/how to go fully shielded? For me personally if I’m fairly confident it’s ≤ 6 months, I’d be totally for it. I’m not confident in that yet.
What would give me confidence is seeing users adopt shielded products and services. For me “Ledger support” isn’t nearly as important as “the number of Ledger users using shielded Zcash is growing by 5% per month for the past three months”. Shielded mobile “support” isn’t nearly as important as “the number of shielded mobile users and/or txns is growing by 5% per month”.
BTW- I’m starting to hear some really promising adoption rate numbers through the grapevine for shielded services. So if we keep the momentum going, with any luck in 3-12 months this thread will be moot because the downside risks I mention here will be fairly obviously mitigated already before needing to apply a forcing function.