Zcash - A Privacy Cryptocurrency

Zcash is a privacy-respecting cryptocurrency that provides shielded transactions. It uses zero-knowledge proofs to give users the option of protecting their financial privacy. Zcash can validate shielded transactions in zero-knowledge, while keeping the details encrypted between sender and receiver, with optional revealing of data as needed. Zcash uses these proofs to verify that values match, that spent money has been produced in the past, that the prover was authorized, and that this money hasn’t been spent before, all in zero-knowledge.

The Zcash Foundation

The Zcash Foundation supports development of the Zcash protocol and privacy-preserving technologies. We work with cryptographers and developers from all around the world. A major part of our work is Zebra, a parallel Zcash validating cryptocurrency node with proof batching.

The Foundation also hosts an annual conference, Zcon, which is coming up on the 8-9 June 2021 and is free (gratis) for all.

Zero-Knowledge Proofs in Zcash

The Zcash protocol has used a number of different zk-SNARK proof systems since its initial deployment in 2016, including BCTV14 for the first shielded pool, Sprout (which is now in the process of being deprecated). The current version, dubbed Sapling, uses parallel batched pairing-based Groth16 proofs.

We are currently integrating the new Halo2 proof system for the upcoming Orchard shielded transactions. Halo2 introduces a recursive-capable zk-SNARK with an UltraPLONK arithmetization. Our first integration of Halo2 will be parallel, un-batched verification, with batched proof verification coming after NU5 activation.

Zero-Knowledge Proof Batch Verification in Zebra

Zebra implements global batch verification of proofs and signatures across Zcash transactions.

Zebra’s verification pipeline is fed by concurrent block verification tasks. It verifies proofs and signatures in parallel, including Groth16 proofs, Ed25519 signatures, and RedJubjub signatures. This maximizes the utilization of any available processor cores.

Zebra uses Rust futures via Tower services to implement composable batch verification. Zebra concurrently downloads and verifies transactions, which can each contain multiple proofs and signatures. Each different kind of proof / signature is sent to its global batch verifier, an instance of a Tower service for that type of batch verification , which has a configurable batch size limit and timeout. When the limit or timeout is reached, the entire batch is verified. If batch verification succeeds, each proof in the batch returns a successful result. If the batch fails, each proof is re-verified individually, in parallel, to correctly throw an error and log which item failed to verify.

Using Tower services allows us to take advantage of batch verification, but return an accurate verification status for each individual item. When queuing up an item to be verified in a batch, the caller of the service gets a future for that item. This future resolves when the entire batch is verified successfully. If the batch fails, the future resolves to the fallback individual verification result. That way, we can keep track of particular signatures or proofs in the context of the verification service call, while getting the amortization benefits of batching.

Rust futures use cooperative multitasking. Each future is translated into a state machine by the compiler. This minimises the memory and CPU cost of pending futures, and allows for rapid scheduling of ready futures on the current thread. Rust’s memory safety provides assurance that the data for each proof remains intact, even if the batch verifies transactions submitted by malicious users.

As part of Zebra’s parallel verification pipeline, we split verification into 3 stages, based on the amount of context required. Structural verification (parsing) is based on data that has recently been read. Semantic verification is based on data from the current block. And contextual verification uses data from the entire historical blockchain. This design allows us to defer data dependencies until later in the pipeline. Zebra can semantically verify the proofs and signatures from many blocks in parallel, increasing the efficiency of our batch verifiers.

Zebra’s parallel batch verification provides a significant speedup over serial verification, approximately 3x for a full Zcash chain sync.

Distributed Signing with FROST

The Foundation has recently finished an audit of an implementation of the Flexible Round-Optimized Schnorr Threshold (FROST) protocol. FROST is a multi-party threshold signature protocol, which aims to be performant, secure, and compatible with transactions signed by only a single party. The initial commitment round can be batched, so each new threshold signature only requires a single interactive request and response. We currently support key generation by a trusted dealer, with support coming for distributed key generation.

FROST has been implemented for multiple signature schemes. Our audited implementation generates RedJubjub signatures for the Zcash sapling shielded pool. A previous implementation was based on the Ristretto prime order group. We feel confident that FROST will work well with re-randomized signing keys as supported in Zcash, as well.

Based on feedback from the auditors, we are currently working on a serialization format for FROST RedJubjub messages. This binary format will help make FROST RedJubjub interoperable across different languages and implementations. It will also provide a basis for FROST messages using other signature schemes.

Other Privacy Work

Network-level privacy is also an important part of fully private Zcash transactions. We recently performed a technical assessment of different network privacy protocols. We analyzed their resistance to various attacks, including on-path correlation and block access pattern detection. These attacks are relevant for Zcash light clients, which don’t download the full blockchain. Both Tor and a generic mixnet provide good protection, but Tor currently has a significantly larger anonymity set.

We are also looking forward to scaling the Zcash network. We want to continue to improve the performance of the Zcash network and consensus protocols, to keep up with improvements in proof verification times. We also want to improve the user experience of node and wallet software, so that adoption and deployment become easier. A larger network will expand the anonymity set for all users.

Future Zero-Knowledge Proof Work

The Zebra team is looking forward to implementing Halo2 batching, and deploying recursive proofs. These optimizations will keep verification time down, and decrease proof size, allowing wide deployment of privacy protocols with tighter space and resource constraints.

Zcon 2 Lite Conference

From 8-9 June 2021, the Zcash Foundation is hosting Zcon2 Lite, an online conference on Zcash and Zero-Knowledge Proofs. Zcon 2 Lite sessions are scheduled from:

  • Tuesday 8 June, 14:00 – 23:00 UTC
  • Wednesday 9 June, 14:00 – 21:10 UTC

The following sessions will be of particular interest to Zero-Knowledge Proof practitioners:

Credentials Education Tech Zero-knowledge proofs