\n<\/p>\n
ECC\u2019s 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.<\/span><\/p>\n The primary emphasis of ECC\u2019s engineering work in this quarter will be on Zcashd deprecation and the deployment of Zcash Shielded Assets.<\/span><\/p>\n ZSAs are a critical foundation for Zcash\u2019s 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\u2019s implementation of the consensus protocol and note encryption changes for ZSAs, and their integration into Zebra.<\/span><\/p>\n zcashd\u2019s 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.<\/span><\/p>\n Since Sapling, the majority of code supporting Zcash\u2019s cryptography has been written in Rust, taking advantage of Rust\u2019s 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.<\/span><\/p>\n 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\u2019s 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.<\/span><\/p>\n Most of the work to support Zcash\u2019s next major network upgrade is being done outside ECC, in particular by Qedit, Zcash Foundation, and Shielded Labs. An exception is the implementation of <\/span>memo bundles<\/span><\/a>, 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.<\/span><\/p>\n 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\u2019s strong privacy guarantees without compromising on any of them, presents some tricky challenges that have not been solved by other deployed systems.<\/span><\/p>\n We believe that Sean Bowe\u2019s work on the <\/span>Tachyon protocol<\/span><\/a> 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.<\/span><\/p>\n As part of this project, we will work on the design of out-of-band or \u201cliberated\u201d payments \u2014 sent directly in some cases and via a mixnet such as NYM in others \u2014 which has many advantages for scalability (relieving the cost of chain scanning), latency, and usability.<\/span><\/p>\n 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 \u2014 <\/span>Zcash Governance Bloc<\/span><\/a>, <\/span>Community and Coinholder Funding Model<\/span><\/a>, and <\/span>Pure Coinholder Funding Model<\/span><\/a> \u2014 for consideration by the Zcash community.<\/span><\/p>\n Whatever the community decides (subject as always to Zcash\u2019s 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 <\/span>Deferred Dev Fund Lockbox Disbursement<\/span><\/a> in zcashd <\/span>if<\/span><\/em> it turns out to be necessary \u2014 i.e. if the community decides to deploy a funding change that disburses from the <\/span>lockbox<\/span><\/a> in an upgrade before ZSAs or other major consensus features.<\/span><\/p>\n 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\u2019ve developed with other experts in the field, to analyse and deploy <\/span>a non-consensus change to the Orchard and Zcash Shielded Assets protocols<\/span><\/a>. We believe this change is important to reducing future disruption and potential loss-of-funds risk if and when cryptographically relevant quantum computers appear.<\/span><\/p>\n 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\u2019s security analysis in order to provide this work with a firm foundation.<\/span><\/p>\n 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\u2019s constrained resources? Yes. The key to making full and effective use of our protocol engineers\u2019 time and expertise is to make strategic investments of those resources in co-operation with researchers and developers from other companies and communities.<\/span><\/p>\n 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.<\/span><\/p>\n 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\u2019s future.<\/span><\/p>\n (Some of these might sound like a lot of work. But formal verification of cryptographic protocols is the kind of thing ECC\u2019s protocol engineers find relaxing! We were like kids in a candy store trying out <\/span>Lean 4<\/span><\/a>.)<\/span><\/p>\n 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 <\/span>ZIP 2003<\/span><\/a>), which is preferable for cold storage for example. Note that it is always possible that an unanticipated security vulnerability might require moving funds.<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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 \u2013such as the <\/span>flaw in BCTV14<\/span><\/a> found by then-ECC researcher Ariel Gabizon (<\/span>successfully remediated in Zcash<\/span><\/a> with the Sapling network upgrade), or the <\/span>Frozen Heart vulnerabilities<\/span><\/a> due to mistakes in applying the Fiat\u2013Shamir technique to several systems\u2013 as well as a variety of higher-level <\/span>vulnerabilities in ZK circuits<\/span><\/a>, demonstrate how necessary this is.<\/span><\/p>\n The Zcash protocol specification has long included <\/span>informal \u201cpencil-and-paper\u201d proofs<\/span><\/a> 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.<\/span><\/p>\n 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 <\/span>ZKProof effort<\/span><\/a>, which ECC engineers have contributed to over many years, has started an ambitious project to produce a <\/span>verified verifier<\/span><\/a> for a proving system using <\/span>Plonkish arithmetization<\/span><\/a>.<\/span><\/p>\n 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 <\/span>High-Assurance Cryptography Software<\/span><\/a> and the <\/span>Real World Crypto<\/span><\/a> conference in Sofia, Bulgaria, co-located with <\/span>ZKProof 7<\/span><\/a>. At HACS and ZKProof there were signs that the high-assurance cryptography community is starting to coalesce around the <\/span>Lean 4 verification language<\/span><\/a> for verifying cryptographic software and protocols. ECC\u2019s protocol engineers will investigate the use of Lean 4 and related tools to verify Halo 2 and the Zcash circuits.<\/span><\/p>\n This includes the possibility of writing ZK circuits in an <\/span>embedded Domain-Specific Language of Lean<\/span><\/a> \u2014such as the existing prototype ZK circuit language <\/span>clean<\/span><\/a> being developed by zkSecurity\u2014 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 \u2014such as private scalable programmability\u2014 feasible without incurring unacceptable risks.<\/span><\/p>\n<\/p><\/div>\n\n","protected":false},"excerpt":{"rendered":" Preparing for the future ECC\u2019s 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\u2019s […]<\/p>\n","protected":false},"author":1,"featured_media":28599,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12030],"tags":[14565,14524,19449],"dealstore":[],"offerexpiration":[],"class_list":["post-182425","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-altcoin","tag-engineering","tag-protocol","tag-roadmap"],"yoast_head":"\nZcash Shielded Assets<\/span><\/h3>\n
Zcashd deprecation<\/span><\/h3>\n
Memo bundles<\/span><\/h3>\n
Scalable Liberated Payments<\/span><\/h3>\n
Governance<\/span><\/h3>\n
Quantum resilience<\/span><\/h3>\n
Supporting a Proof-of-Stake transition<\/span><\/h3>\n
Conclusions for Q2<\/span><\/h2>\n
The farther future<\/span><\/h2>\n
Long-term storage<\/span><\/h3>\n
Formal verification<\/span><\/h3>\n