Preparing for the future
ECC’s protocol engineering efforts in the next quarter and beyond will focus on the work that is needed now to provide a sound base for future protocol development, in concert with the Zcash community and developers at Zcash Foundation, Qedit, Shielded Labs, Zingo Labs, and others.
The primary emphasis of ECC’s engineering work in this quarter will be on Zcashd deprecation and the deployment of Zcash Shielded Assets.
Zcash Shielded Assets
ZSAs are a critical foundation for Zcash’s future and it is vital that they are deployed safely and successfully without undue delay. In later quarters that will include development of wallet support for multiple assets, but for now the focus is on the review of Qedit’s implementation of the consensus protocol and note encryption changes for ZSAs, and their integration into Zebra.
Zcashd deprecation
zcashd’s legacy C++ codebase derived from Bitcoin Core has served us well, but has become a drag on protocol development and maintenance. Since ZSAs will not be supported by zcashd, their deployment requires moving to the Zebra node software developed by Zcash Foundation.
Since Sapling, the majority of code supporting Zcash’s cryptography has been written in Rust, taking advantage of Rust’s memory safety, its strong type system, a community that cares deeply about software quality and security, and access to a broad ecosystem of libraries providing a solid foundation for cryptographic software. Zebra expands the advantages of working in Rust to the networking and consensus protocol, benefiting greatly in simplicity, robustness, and maintainability from its single-language codebase.
What has been missing for the transition to Zebra is a full-node wallet suitable for exchanges and other non-light-client use cases, and supporting the full Zcash protocol, including transparent multisig and P2SH addresses. ECC is writing the Zallet wallet to fill this gap. Previous work by ECC has put Zcash’s libraries in a good position to support this functionality, but the work is not complete, and will need to be integrated with Zallet and the Zaino project developed by Zingo Labs. Completing this integration will make up a large portion of the work done by ECC engineers in Q2.
Memo bundles
Most of the work to support Zcash’s next major network upgrade is being done outside ECC, in particular by Qedit, Zcash Foundation, and Shielded Labs. An exception is the implementation of memo bundles, which will need to be ready for the same upgrade. This protocol change allows larger memos and also supports efficiently sending memo data to multiple recipients, unlocking new functionality such as authenticated reply addresses, and other applications of on-chain proofs outside the main consensus protocol.
Scalable Liberated Payments
From the launch of Zcash, our vision has always been for it to become a globally adopted electronic payments system that maintains the privacy of physical cash, while matching or beating centralized systems in ease of use. ZSAs are critical to some aspects of that vision. But even once ZSAs are deployed, it will be impossible to achieve the adoption we aim for unless the protocol can scale with usage to, at first, hundreds or thousands of times the current transaction capacity, and eventually, a scale that allows it to be truly ubiquitous. The goal of combining scalability, usability, and Zcash’s strong privacy guarantees without compromising on any of them, presents some tricky challenges that have not been solved by other deployed systems.
We believe that Sean Bowe’s work on the Tachyon protocol provides a path for this to happen. There is a lot of design work to do to make it into a deployable reality. ECC researchers will collaborate with Sean on the design of Tachyon.
As part of this project, we will work on the design of out-of-band or “liberated” payments — sent directly in some cases and via a mixnet such as NYM in others — which has many advantages for scalability (relieving the cost of chain scanning), latency, and usability.
Governance
Zcash urgently needs decentralized governance and allocation of funding. This is a controversial topic on which opinions differ. ECC team members have contributed three proposals — Zcash Governance Bloc, Community and Coinholder Funding Model, and Pure Coinholder Funding Model — for consideration by the Zcash community.
Whatever the community decides (subject as always to Zcash’s culture of never compromising on security and robustness), we will help to specify, implement, analyse, and deploy it. This could include implementing consensus mechanisms such as Deferred Dev Fund Lockbox Disbursement in zcashd if it turns out to be necessary — i.e. if the community decides to deploy a funding change that disburses from the lockbox in an upgrade before ZSAs or other major consensus features.
Quantum resilience
Quantum computers are a realistic potential threat to some of the cryptography used in Zcash within a 3 to 10-year timeframe. Given lead times for protocol upgrades, that means there is significant value in taking small steps now that could greatly reduce the disruption of moving to a post-quantum protocol later. ECC will use the experience of its protocol engineers in post-quantum cryptography, and the relationships we’ve developed with other experts in the field, to analyse and deploy a non-consensus change to the Orchard and Zcash Shielded Assets protocols. We believe this change is important to reducing future disruption and potential loss-of-funds risk if and when cryptographically relevant quantum computers appear.
Supporting a Proof-of-Stake transition
The developers at Shielded Labs are making efficient progress on a plan to transition Zcash to Proof-of-Stake via the Crosslink protocol developed by Daira-Emma Hopwood, Nathan Wilcox and Jack Grigg. Within Q2, researchers at ECC will complete our contribution to Crosslink’s security analysis in order to provide this work with a firm foundation.
Conclusions for Q2
The above programme is ambitious, but builds on efforts that have been ongoing for some time. Can we fit it into a quarter with ECC’s constrained resources? Yes. The key to making full and effective use of our protocol engineers’ time and expertise is to make strategic investments of those resources in co-operation with researchers and developers from other companies and communities.
With the help of Zcash Foundation, Qedit, Shielded Labs, Zingo Labs, and the wider high-assurance, ZK, and post-quantum cryptography communities, we are confident that the path to truly scalable, ubiquitous, high-assurance private money is open.
The farther future
None of the ideas below are commitments to what we will do in Q2, but we thought it would be interesting to see what else we are thinking about for Zcash’s future.
(Some of these might sound like a lot of work. But formal verification of cryptographic protocols is the kind of thing ECC’s protocol engineers find relaxing! We were like kids in a candy store trying out Lean 4.)
Long-term storage
ECC researchers will work on the design of a potential long-term storage protocol that is future-proof in its cryptographic and engineering choices. This reduces the likelihood of needing to move funds to later shielded pools in response to pool deprecation (such as the proposal to disable the ability to spend Sprout funds in ZIP 2003), which is preferable for cold storage for example. Note that it is always possible that an unanticipated security vulnerability might require moving funds.
This is complementary to the quantum resilience work mentioned above, because the long-term storage protocol will be able to use only conservatively designed symmetric cryptography that minimizes the risk of attack from quantum computers. It may be that elements of the payment and storage protocols can be shared to reduce complexity or even that no separate protocol is needed, but that will only become clear with further research and development.
Formal verification
ECC and Zcash are widely acknowledged to have played an essential role in accelerating the development and deployment of zero-knowledge and succinct proving systems. We need to maintain our leadership in this field by helping to put the science of proving systems on a sounder footing.
We have always placed critical emphasis on the importance of proactively looking for flaws to increase our confidence in the correctness and security of our protocols and implementations. The history of vulnerabilities in proving systems –such as the flaw in BCTV14 found by then-ECC researcher Ariel Gabizon (successfully remediated in Zcash with the Sapling network upgrade), or the Frozen Heart vulnerabilities due to mistakes in applying the Fiat–Shamir technique to several systems– as well as a variety of higher-level vulnerabilities in ZK circuits, demonstrate how necessary this is.
The Zcash protocol specification has long included informal “pencil-and-paper” proofs of the correctness of specific optimizations and the security of some cryptographic components, which were especially critical to the design of Sapling and Orchard. Third-party audits (such as the ones done on Zcash by NCC Group, Coinspect, Least Authority, Mary Maller, Kudelski Security, Qedit, and Trail of Bits) can provide another kind of assurance, but they are limited by time constraints and often by a relative lack of familiarity with the code by auditors.
One of the most promising techniques that can prevent, rather than just detect, potential flaws is formal verification. This is able to provide a degree of assurance essentially impossible to obtain by any other method. Formal verification is finally coming of age, with more usable tools that are attracting a larger community to verify a wider range of protocols and systems. The ZKProof effort, which ECC engineers have contributed to over many years, has started an ambitious project to produce a verified verifier for a proving system using Plonkish arithmetization.
Our engineers Daira-Emma Hopwood and Jack Grigg (together with several other veteran Zcashers including Sean Bowe, and former ZIP Editor and post-quantum cryptography expert Deirdre Connolly) recently attended the workshop on High-Assurance Cryptography Software and the Real World Crypto conference in Sofia, Bulgaria, co-located with ZKProof 7. At HACS and ZKProof there were signs that the high-assurance cryptography community is starting to coalesce around the Lean 4 verification language for verifying cryptographic software and protocols. ECC’s protocol engineers will investigate the use of Lean 4 and related tools to verify Halo 2 and the Zcash circuits.
This includes the possibility of writing ZK circuits in an embedded Domain-Specific Language of Lean —such as the existing prototype ZK circuit language clean being developed by zkSecurity— providing the full power of theorem proving and dependent types to reasoning about circuit programs. Our hope is that in combination with the verified verifier project and other efforts, this will eventually support rigorous end-to-end verification of meaningful security properties of ZK protocols in a way that is maintainable and accessible to protocol engineers. That would be huge step toward making longer-term possibilities —such as private scalable programmability— feasible without incurring unacceptable risks.
