We’re proud to introduce ZIP 224, which provides a path to bringing Halo 2 to Zcash. The Halo 2 zero-knowledge proving system, invented and developed at Electric Coin Co. (ECC), eliminates the trusted setup, reducing the attack surface of the Zcash protocol and improving assurance about ZEC supply integrity. As the first deployment of the Halo 2 zero-knowledge platform, this would enable future circuit upgrades without the need for setup ceremonies, making the Zcash shielded protocol more agile for future improvements, such as supporting additional assets. In addition, the ZIP paves the way for proof aggregation and blockchain succinctness, two scalability improvements that enable the Zcash protocol to stay abreast of adoption.
A proposed Zcash protocol feature
The first phase of Halo 2 deployment in Zcash introduces a new shielded-transaction protocol, which creates the first shielded-transfer capability that does not rely on a trusted setup. The functionality offered will be very similar to that available from the Sapling protocol, however, the proving system will leverage the Halo 2 stack. This includes a new cycle of elliptic curves, Pallas and Vesta, together referred to as the Pasta curves. The Pasta curves, a new cryptographic construct, are a result of ECC’s continued effort to ensure that Zcash benefits as much as possible from groundbreaking cryptographic innovations that improve both security and performance. The Pasta curves are already being adopted by Mir Protocol and Mina (formerly Coda), and Mina has already begun work on a Ledger integration for the Pasta curves which has been submitted to Zondax for future Zcash Ledger integration. They are also included in the Arkworks Rust library.
The ZIP introduces a new shielded-address format, using the Pasta curves, and a new shielded pool. Its protocol design characteristics and privacy properties are intentionally almost identical to Sapling, in order to limit technical risk and simplify the user experience and adoption. Third-party audits will be commissioned to increase confidence in the safety of the new protocol and implementation before it is considered ready for deployment.
New shielded pool
If activated, the ZIP would create a third shielded pool for Zcash and represents the continued evolution of our zk-SNARK technology stack. The first shielded pool was codenamed Sprout, and the second shielded pool was codenamed Sapling.
The new shielded pool would be guarded by the same shielded-pool turnstile design as used between Sprout and Sapling. This supports our strategy to limit cryptographic and engineering risk as we deploy new shielded technology, by gradually retiring older shielded pools. This encourages migration to a trustless proof system, reinforces confidence in the soundness of the monetary base, and reduces the implementation complexity and attack surface of Zcash overall.
In the Canopy network upgrade, we deployed ZIP 211 which disabled the ability to add new value to the Sprout value pool balance. Similarly, in a future network upgrade after ZIP 224 activates, our intent is to deploy ZIP 219, which will similarly disable the ability to add new value to the Sapling value pool balance. The current Sprout-to-Sapling migration tool would be upgraded to support both Sprout-to-Halo and Sapling-to-Halo migrations immediately from activation.
Reduction of metadata leakage
Taking account of experience from Sprout and Sapling, this ZIP includes changes to reduce leakage of metadata in the unencrypted parts of transactions. This is done by merging Outputs and Spends into “Actions,” which are indistinguishable from each other, and by using a single anchor for all Actions in a transaction.
Future-proofing Zcash
The currently active shielded pool for Sapling uses Groth16, the smallest and most efficiently verifiable zero-knowledge proof construction. These proofs are less than 200 bytes in size and take around 7-10ms to verify individually in zcashd today. This is great for the scale at which our network currently operates, as the verification time lives within the noise margins of network latency.
However, at some scale even this is insufficient, especially given some of the unknowns around the usage patterns of future Zcash extensions, such as User Defined Assets (UDAs). When we discuss what verification time and proof size is acceptable in Zcash, an order of magnitude is not make-or-break; however, we need proofs that support techniques that can advance scalability and programmability, such as proof-carrying data. These techniques allow proofs to be aggregated together and proof verification time to be amortized away, so that the major contributors to the cost of transaction verification and storage are exponentially reduced. It is infeasible for our existing proofs to support all of these kinds of techniques except in very limited situations. What we have achieved with Halo 2 not only supports these techniques, which are indispensable tools for scalability, but even without these tools our proof size and individual proof verification time are still well within the bounds required to support Zcash transaction volumes in the near term.
By eliminating the need for a “trusted” per-circuit setup, this ZIP both mitigates concerns with respect to the security of that process and ensures that MPC setup ceremonies will not be required for other circuit changes in the future, such as those required to introduce UDAs. This will make those changes easier to implement, and it will lower the cost, risk and time to ship future upgrades.
Halo also relies on weaker and less complicated cryptographic assumptions than the current Groth16 proofs, which depend on pairing-based cryptography. Although there is no immediate reason to be concerned about the security of the BLS12-381 pairing that Zcash uses, the reduction in security assumptions is welcome.
Scalability will require large redesigns of Zcash’s current protocol that are more involved than simply implementing Halo 2 on Zcash. Halo 2 will be a crucial component of these protocol designs. In the relatively near term, we will be able to leverage features in Halo 2 to reduce on-chain bandwidth and verification time via transaction aggregation. Eventually these features could also allow us to implement a fully succinct block chain, allowing near-instant syncing, and light client support with similar security guarantees to a full node.
Performance
We’ve been working hard, from the beginning of the development of Halo 2, to ensure that we could solve scalability challenges and remove the trusted setup without compromising in any meaningful way on performance. We believe that computationally Halo 2 on Zcash will be competitive and perhaps even superior to Sapling (although transactions will be a bit larger). Additionally, the accumulation and aggregation capabilities of Halo 2 will allow us to substantially reduce transaction sizes in a future scalable version of Zcash.
Shielded transactions built using Halo 2 look a bit different than those with proofs created using Groth16. Instead of creating several individual proofs for each Spend and Output description, all of the proofs are created in parallel with each other so that they can share the costs of their size and verification time. Transactions with a single proof will be roughly a couple of kilobytes, but the marginal size of additional proof material is much smaller, and the marginal verification time is insignificant. Given that existing shielded transactions can contain kilobytes of memo data, this does not represent a significant increase in transaction size.
The time for verifying an individual transaction on a single thread is around 30ms, which is slightly worse for a single proof than Groth16. However, unlike Groth16 proofs that require many serial operations, our proofs can be verified almost entirely in parallel, and this can scale with the number of threads available. With just three or four threads available, the performance approaches that of Groth16, and with more threads the performance of Halo 2 on Zcash may be superior.
Implementation
In this section we break down key implementation notes for different categories of users. In general, for all categories of users, this feature brings the risk of new bugs or unforeseen design flaws which is true of any network upgrade feature. Additionally, because Sapling will still be an active pool, no specific action items are required to continue using Sapling addresses or integrating with the Sapling shielded pool when the network upgrade containing ZIP 224 activates, other than to upgrade to a supporting release of Zcashd or our mobile wallet SDKs. Users who rely on Zcashd directly or our wallet SDKs, and who don’t have complex needs for the end-user experience, should have a relatively straightforward implementation.
| Category | Notes |
|---|---|
| Mining Pool Operators | In order to use shielded coinbase with a new ZIP 224 address, operators would only need to generate the address and configure -mineraddress accordingly. No change will be required for the mining pool operators to send to a mining pool recipient who chooses to use a new ZIP 224 address. |
| Wallet Vendors | Vendors that use our SDK, like NightHawk and Unstoppable, would get ZIP 224 support automatically by upgrading to a supporting version of the SDK. Additional work would be needed in user interface code to accommodate ZIP 224 addresses. |
| Exchanges and Hardware Wallets | Exchanges like Gemini that support Sapling outputs would need to add support for ZIP 224 outputs. Zondax would need to add support for Ledger integration; however Mina has already commissioned a Ledger integration for the Pasta curves which should aid that effort. |
| Developers | ZIP 224’s implementation benefits from ECC’s cryptographic engineering expertise through multiple deployment-grade generations of ZKP technology. In combination with ECC’s work on our Shielded Mobile Wallet SDK, we believe this newer technology will be easier to integrate and deploy than Zcash’s current Sapling support. |
| Existing ZEC Users | Existing ZEC holders can migrate their funds into the new shielded pool using the migration tool mentioned above or through the standard transfer mechanism they use today. |
| Block Explorers | Block explorers must change how they handle supply calculations and parse / display details about ZIP 224 transfers. |
