Zcash privacy
Zcash Zero-Knowledge Proofs: zk-SNARKs and Halo 2
Quick Answer
Proof-system explanations must identify the Zcash shielded protocol and source version. ZIP 224 specifies Orchard’s use of Halo 2 with PLONKish arithmetization instead of Groth16/R1CS, and explicitly says this proposal does not use Halo 2 recursive-proof support. The source is ZIP 224, titled Orchard Shielded Protocol, with a Final header.
Key Takeaways
- Zero-knowledge proofs allow validation without disclosing the same financial details.
- Orchard uses a different proving-system design from earlier shielded protocols.
- A shielded protocol does not eliminate information held by endpoints.
A protocol name is necessary context
The source is ZIP 224, titled Orchard Shielded Protocol, with a Final header. Its specification requires Orchard to follow the Zcash Protocol Specification and then documents design differences from Sapling.
This guide is a reading aid to that specific source, not a derivation of the mathematics or proof that every transaction, wallet or network interface has the same disclosure properties. The Final editorial label is not an independently verified chain activation record.
Groth16 and the setup assumptions described in the source
ZIP 224’s motivation describes Sprout and Sapling circuits using a Groth16 proving system with a structured reference string and discusses the risks of hidden setup structure. It explains the multiparty-generation assumption: at least one honest, uncompromised participant makes that hidden structure unrecoverable.
These are source-described assumptions, not a guarantee from this project that a historical ceremony was flawless or that all implementation bugs are impossible.
What the Orchard design changes
The proposal motivates a curve-cycle design and a proving system not requiring an SRS. Its proving-system section says Orchard uses Halo 2 with PLONKish arithmetization rather than Groth16 and R1CS.
It describes an Orchard bundle of actions covered by a single Halo 2 proof. These statements have exact source locations below; we do not turn them into claims about performance, all future upgrades or device compatibility.
Recursive capability is not deployed recursive use
ZIP 224 explicitly says the proposal does not make use of Halo 2’s support for recursive proofs, while describing it as an expected future possibility. Saying Halo 2 supports a technique and saying this protocol proposal uses it are different claims.
The same care applies to other forward-looking design language: future scalability goals are not already measured product benefits or evidence that a pending upgrade activated.
How this relates to transaction privacy
A proof-system description alone does not settle transparent versus shielded use, cross-pool disclosure, viewing-key permissions, endpoint compromise or server metadata. Those are separate protocol and operational questions.
The shielded-transactions, address-types and viewing-keys guides explain their own evidence scope. No personalized privacy recommendation, identity tracing, key upload or wallet connection is offered here.
FAQ
Does Orchard’s use of Halo 2 mean recursive proofs are used here?
Not in the retrieved ZIP 224 proposal. It explicitly says it does not make use of Halo 2 recursive-proof support.
Does a proof-system name guarantee every ZEC transaction is private?
No. Transaction type, disclosure mechanisms and operational metadata are distinct evidence questions.
Is the Final ZIP header an activation proof?
No. It is document metadata; observed enforcement on a particular network and height needs separate evidence.
Sources and Methodology
Page updated: . Source observation dates remain separate.
Source checked: 2026-10-01T17:33:53.576439+00:00
Source version and supporting details
- Lines 3–14: Orchard Shielded Protocol, Final header and creation metadata.
- Lines 38–71: historical motivation, Groth16/SRS and multiparty setup assumption.
- Lines 77–82 and 108–125: normative protocol pointer, Halo 2/PLONKish, no recursive use and action bundle.
a735caf76ed8d3fa0a50e4f6b706ca9dac39079b
179c31d846b697f3c75471533576794f27610333244dd760435447313f945632
Methodology and technical limitations
Method and limits
We paraphrase a pinned ZIP 224, with its creation metadata, header and retrieval hash kept separate. Historical motivation text refers to its own February 2021 context and is not rewritten as a current inventory of all active pools. No cryptographic proof verification, benchmark, expert audit or independently observed chain activation has been performed.
Source dates describe the referenced observation or document, not a live price. How data is checked · Corrections