During the latest Electric Coin Co. (ECC) quarterly livestream, we shared our R&D and engineering strategy to advance the future of Zcash. In this post, we delve a little deeper into this section of our overall ECC flight plan and lay out a vision of what’s possible for the future of Zcash.
This post outlines what could be; we recognize there’s a delicate balance between being ambitious and realistic, telling a story that’s inspiring while also avoiding the crypto hype machine. To stay accountable to our flight plan goals, we’ll post an update in the first quarter next year. It will assess our execution and the strategic outcomes from this quarter’s plan and present any associated strategic changes.
Below, we summarize our thinking on the technical objectives that could unlock exponential momentum and adoption in the years to come.
Our R&D and engineering strategy is focused on (a) interoperability and (b) enabling more parties to participate in Zcash development. Some of our R&D objectives involve cutting-edge technology that has yet to be tested, much less implemented into practical uses and production-ready code. Nevertheless, we are committed to exploring and developing this research to advance Zcash and privacy-preserving technology across the industry. Our engineering efforts are the bedrock of the protocol as we bring R&D to life responsibly, preventing or quickly mitigating disastrous bugs and security issues.
The flight plan
We envision Zcash becoming a usable, safe, global, permissionless, and private store of value and medium of exchange. We know it won’t be an easy road to get there. As a company, we are committed to improving agility, communicating our vision and rationale, and remaining accountable to the community. At ECC, we believe a future version of Zcash can be fully shielded, which would provide the strongest privacy benefits for users, and also simplify usability and technical concerns. Additionally, we’ve determined that, at least for the next year, it is imperative not to impede or slow down adoption of Zcash’s transparent functionality by new services or products. Thus our strategy accommodates both shielded and transparent development and adoption.
Our flight plan outlines where we’re going and what we need to get there. At ECC, we think of “where we’re going” in terms of three horions: short term, near term and long term. We think of our objectives as what we need to get there.
Three horizons
Horizon 1: 0-6 months, short term
Horizon 1 is specifically focused on community enablement and interoperability, with specific attention on shielded mobile SDKs, viewing key support and Blossom activation. We anticipate that Zcash will continue to have widespread adoption among well-regulated exchanges with liquidity in multiple fiat trading pairs. The first production mobile wallets supporting Zcash shielded functionality will be deployed and improved upon in this horizon. ECC is no longer the primary developer of the Zcash base protocol and infrastructure, with a second consensus node implementation, zebra, approaching a production-ready release. Additionally, multiple development orgs are actively collaborating on upcoming protocol features.
Horizon 2: 6-24 months, near term
Horizon 2 and 3 plans are more speculative and based on the community’s decision on ECC funding.
Our vision is that within two years the Zcash community will have instituted a qualitative change to the current governance structure for Zcash. We believe it is likely (although not guaranteed) that there will be a development fund with a portion of funds coming from blockchain issuance rules.
During Horizon 2, we are confident that Zcash will activate Network Upgrades 3 and 4. Two different consensus node codebases will operate on mainnet. Multiple persistent public testnets will exist for prototyping different protocol features. We also intend to spend our focus on Layer 1 scalability approaches, such as HALO research. In this horizon, most of our “direct users” will be vendors, organizations or projects, rather than end users.
We also anticipate that during Horizon 2, multiple parties will continue the work on wrapped ZEC bridges, WTPs and Layer 2 support. (See David Campbell’s livestream presentation.) We predict multiple services across key verticals will adopt Zcash shielded support, including consumer mobile noncustodial wallets, exchanges, payment systems and more mining pools. Viewing key support will be mature in production, enabling new Zcash-specific applications, such as secure exchange hot/cold wallet-monitoring systems, privacy-protecting portfolio-monitoring tools, enterprise block explorers with private account views, and consumer messaging integrations. We believe this “minimum viable closed economic loop” within the Zcash shielded ecosystem will lead to increased adoption, independent of ECC or Zcash Foundation efforts. We believe this will present a compelling enough business case for services to provide shielded support. We also expect that strong privacy support will be seen as a necessity for all public blockchains in this time period.
Horizon 3: 2-4 year range, long term
Our long term vision — for the next four years — is that Zcash will emerge as a mature, safe, private, permissionless store-of-value and medium-of-exchange. We believe cryptocurrencies, Zcash especially, will have powerful medium-of-exchange (MoE) usage, especially in regions with poorly managed regional monetary policy, as well as globally in various internet-native services and products. In general, we expect cryptocurrencies will continue to gain inroads in mainstream markets, accruing a global network effect as they do. Finally, we expect “alternative infrastructure” to continue to grow in scope, though not displacing central internet infrastructure in this time range. We include things like DAOs, alternative naming systems, p2p cloud computing, and payments-integrated social networking in this category.
Given these beliefs, we see Zcash as one of the leading stores-of-value and a mediums-of-exchange, particularly for regions with unstable monetary policy, decentralized financial ecosystems, and the alternative infrastructure category. We believe Zcash will be competitive in this role due to its best-in-class privacy properties, interoperability and support for L2 use cases including micropayments. In this Horizon 3, protocol development should be highly decentralized with persistent testnets mixing and matching prototyped features.
Horizon 1 ECC objectives and key results
We have broken down our higher level strategy into eight objectives.
Objectives are long-lived focuses of our effort. They are defined with short qualitative descriptions. We provide a rationale for aiming for the objective. We then express our believed benefits of pursuing this objective over the three time horizons.
For each objective, we describe our key results against that objective, including what effort we intend to take this quarter, our execution success criteria and strategic success indicators.
Execution success criteria strive to be defined in terms that ECC can complete without relying on external parties or stable external conditions. Achieving them or failing to achieve them over a quarter keeps our execution accountable.
By contrast, strategic success indicators are events or metrics that suggest our efforts are having the desired impact in the marketplace. If we execute successfully but do not see strategic success indicators it may be due to either mistaken beliefs guiding our objective or externally shifting conditions in the marketplace.
With this framework at hand, here are our current engineering objectives for the next six months:
- Flyclient MMR support
- Whitelisted Transparent Programs
- Mobile wallet SDK improvements
- Viewing key support
- Ethereum protocol improvements for Zcash
- Dev fund protocol support
- Community-driven protocol development
- Scalability 2021
Conclusion
We know these goals are ambitious. We might only achieve 80% of what we’ve laid out. We commit to being transparent and specific about our plans so that the rest of the Zcash community can be inspired to (hopefully) build alongside us. What do you think we can accomplish with less than two holiday filled months left in the quarter? You’ll have to tune in next time to find out!
Objectives:
Flyclient MMR support
Description: Flyclient’s Merkle Mountain Range protocol feature enables efficient proofs of Proof-of-Work for light clients. In addition to enabling improved light-client wallets, this improves many cross-chain protocols. This feature is specified in ZIP 221.
Rationale: This feature enables tZEC, a concrete use case. It also enables a class of cross-chain integration and lite-client use cases. If this feature is deployed in NU3, it has the potential to enable multiple interoperability protocols and products or services built upon them.
Effort: We will coordinate multiple developer orgs on design and implementation, and integrate MMR libraries into Zcashd.
Execution success cCriteria:
- Technical review of ZIP 221
- A functional prototype in a Zcashd development branch
Strategic success indicators:
- Keep and provide a deployment timeline for tZEC
- Bonus: Any other MMR-based feature is announced by third party
Whitelisted Transparent Programs
Description: Whitelisted Transparent Programs simplify extending consensus upgrades to transaction semantics outside of Bitcoin script, without strong privacy. They use a UTXO semantic model, yet have broader capabilities than Bitcoin script. Their specification is in a ZIP draft state.
Rationale: The WTP feature simplifies BOLT Layer 2 support, a concrete use case. Furthermore, it enables a large design space of future protocol upgrades to extend transaction semantics. If this feature is included in NU4, it can enable new WTP-based feature development to support desired use cases (potentially dynamic programmability features, covenants, an on-chain naming system, or others).
Effort: Finalize the ZIP specification, provide a library for zcashd implementation, and implement a proof-of-concept prototype.
Execution success criteria:
- The ZIP specification is submitted for NU4 acceptance
- A zcashd implementation exists in a development branch
- There is a functioning proof-of-concept WTP program
Strategic success indicators:
- The ZIP specification is accepted into NU4
- Bolt Labs announces a functional test prototype of BOLT support based on WTPs
Mobile wallet SDK improvements
Description: The ECC Mobile Wallet SDK and associated protocol and backend components enable shielded mobile wallets and similar applications.
Rationale: A consumer-facing shielded lite wallet is the first service necessary to encourage shielded adoption. Development of a new modular wallet engine is reusable in other products and use cases beyond mobile wallets.
Effort: Introduce iOS support so that (with Android) both major mobile platforms are supported natively. Develop a mainnet-ready internal prototype within ECC to learn about the full deployment stack including end user UX testing.
Execution success criteria:
- SDK support for core shielded functionality on iOS and Android
- SDK support for transparent transactions on both platforms
- Internal “dogfood app” is installable on an invite-only basis and can transact on mainnet
Strategic success indicators:
- A third-party mobile wallet announces a Zcash shielded support build from this SDK
Viewing key support
Description: Viewing keys are a protocol feature of the NU1 Sapling upgrade; they allow a viewing key holder to see incoming and outgoing transaction information for the associated shielded address, without the ability to transfer any funds.
Rationale: Viewing keys are a key component of the Zcash value proposition because they allow users to selectively disclose transaction information to third parties. The protocol feature has been in place for a year, and the demand is known, so following through with tool support is obvious.
Effort: We will develop a zcashd-based prototype.
Execution success criteria:
- A zcashd branch has experimental viewing key RPC support on mainnet
Strategic success indicators:
- One or more third-party applications have announced viewing key support
Ethereum protocol improvements for Zcash
Description: Where possible to upgrade Ethereum in a manner that benefits Zcash interoperability with Ethereum, ECC aims to improve that interoperability.
Rationale: Ethereum is the current focus for Defi and other decentralized Dapps, and by bridging ZEC to that market, both systems can benefit: Defi/Dapp users gain access to private storage with less platform risk, and ZEC holders gain access to the Defi/Dapp marketplace. ECC envisions extending the privacy protections of the Zcash shielded pool outward across bridging protocols to improve private usage of Defi/Dapp use cases. Assuming Istanbul activates with EIP152 Blake2 support in the next six months, protocols like tZEC will be possible. In theory, future upgrades to both Ethereum and Zcash may enable extending Zcash’s privacy across bridge protocols into the Defi or Dapp use cases. This is speculative, ongoing research, but it is an exciting possibility ECC is committed to exploring.
Effort: Provide coordination and advocacy for Ethereum EIP152 deployment in Istanbul.
Execution success criteria: There is no outstanding effort required of ECC to achieve the business objective for this quarter.
Strategic success indicators:
- Ethereum Istanbul activates with EIP152 support
Dev fund protocol support
Description: ECC will evaluate and implement any feasible dev fund or governance-based consensus rule changes from the 2019/2020 Community Dev Fund decision process. (Note: ECC will not exercise any discretionary authority over design that materially impacts governance, and instead will work with the Zcash Foundation and the community to resolve any such ambiguities in protocol development.) If the selected proposal requires technically simple consensus rule changes, the specification will be complete and a testnet implementation will be complete within the next six months. If the consensus rule changes are more sophisticated, a ZIP draft will be ready for review and auditing by Zcash Foundation and external auditors.
Rationale: ECC is committed to implementing the non-discretionary technical features necessary to support the community selected Dev Fund proposal.
Effort: Publish an initial assessment of technical feasibility and security of the selected dev fund proposal.
Execution success criteria:
- Our technical assessment is posted within the ZIPs repository addressing the selected ZIP
Strategic success indicators:
- The foundation’s technical team has either publicly concurred with ECC’s technical assessment or posted its own alternative assessment
Community-driven protocol development
Description: This goal lowers barriers to entry for developers outside of ECC to contribute protocol changes to Zcash. A new process will be instituted for Network Upgrade 4 which will make it easier for other developers to get their desired protocol changes into NU4.
Rationale: The existing Network Upgrade Pipeline has known barriers to entry for parties outside of ECC or Zcash Foundation to contribute Zcash protocol changes, so this effort can address those hurdles and encourage more contributions to protocol development. With improvements to this process dovetailing with a new development fund and governance structure for Zcash, we anticipate substantial new skilled and engaged development teams contributing to Zcash.
Effort: ECC will work with the Zcash Foundation to propose a new upgrade process, incorporate feedback from all current protocol developer orgs, then present the result to the public.
Execution success criteria:
- ECC has published the proposal and feedback to the public
Strategic success indicators:
- Zcash Foundation and at least two of the four other participating development organizations publicly endorse the new process
Scalability 2021
Description: The ECC Scalability 2021 project is a long term R&D initiative to transition Zcash to a new architecture with Layer 1 horizontal scalability. The current focus of this effort is in research and development around Halo, a new proof system that supports recursive proofs without a toxic waste systemic vulnerability. In the next six months, we’ll have more academic review of Halo. We’ll also have a better understanding of the associated SNARKtember (where multiple similar yet distinct research breakthroughs were published) results and we anticipate further potential developments as researchers discover how these related results may be combined or improved upon.
Rationale: In order for Zcash to be useful to billions of users without relying on middlemen, it must horizontally scale at the base layer. By making progress on this long term need now, well before it is practically necessary, potential users evaluating the long-term stability of blockchain platforms will be provided with a plausible path towards global adoption in the long term. This helps them make a justifiable case for adopting Zcash among competitors. In theory, this research will help Zcash transition to a new architecture, capable of meeting massive layer 1 demand, and which may remove the toxic waste risk and transparent functionality from Zcash.
Effort: We will add new optimizations with published performance benchmarks to a new revision of the Halo paper. Research the results from “SNARKtember.”
Execution success criteria:
- ECC publishes a new version of the Halo paper with optimizations and performance benchmarks
- ECC publishes a blog post with comparative analysis of SNARKtember results
Strategic success indicators:
- Zcash’s Scalability 2021 effort is referenced in one or more high-quality industry reports about scalability
