This ZIP number is reserved. Preliminary technical content relating to Orchard and Halo 2 are currently in:
- Specification 
+ The Orchard protocol is specified as an update to the Zcash Protocol Specification . Given that it largely follows the design of the Sapling protocol, we provide here a list of differences, with references to their normative specifications and associated design rationale.
+ Curves
+ The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:
+
+ - Pallas is used as the "application curve", on which the Orchard protocol itself is implemented (c/f Jubjub).
+ - Vesta is used as the "circuit curve"; its scalar field (being the base field of Pallas) is the "word" type over which the circuit is implemented (c/f BLS12-381).
+
+ We use (version 10 of) the IETF hash-to-curve Internet Draft to implement
+ \(\mathsf{GroupHash}\)
+ , instead of the BLAKE2s-based mechanism used for Sapling. We specifically use the "simplified SWU" algorithm, which provides an infallible
+ \(\mathsf{GroupHash}\)
+ .
+ The presence of the curve cycle is an explicit design choice. This ZIP only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future ZIPs.
+
+ - Curve specifications:
+ - Group hash:
+ - Supporting evidence:
+
+
+ Proving system
+ Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), instead of Groth16 and R1CS.
+ This ZIP does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future ZIPs.
+
+ - Halo 2 protocol description: TODO
+ - UltraPLONK Arithmetization:
+ - Halo 2 explanation and design rationale:
+
+
+ Circuit
+ Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action" contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created.
+ An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.
+
+ - Action description:
+ - Circuit statement:
+ - Design rationale:
+
+
+ Commitments
+ The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the UPA-efficient Sinsemilla in place of Bowe--Hopwood Pedersen hashes.
+
+ - Sinsemilla hash function:
+ - Sinsemilla commitments:
+ - Design rationale:
+
+
+ Commitment tree
+ Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe-Hopwood Pedersen hash.
+
+ - Design rationale and considered alternatives:
+
+
+ Keys and addresses
+ Orchard keys and payment addresses are structurally similar to Sapling, with the following changes:
+
+ - The proof authorizing key is removed, and
+ \(\mathsf{nk}\)
+ is now a field element.
+ -
+ \(\mathsf{ivk}\)
+ is computed as a Sinsemilla commitment instead of a BLAKE2s output.
+ -
+ \(\mathsf{ovk}\)
+ is derived from
+ \(\mathsf{fvk}\)
+ , instead of being a component of the spending key.
+ - All diversifiers now result in valid payment addresses.
+
+ Keys and addresses are encoded using Bech32. Orchard addresses used with the Zcash mainnet have the prefix "zo" (compared to "zc" for Sprout and "zs" for Sapling).
+ Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a simple hardened-only derivation mechanism.
+
+ - Key components diagram:
+ - Key components specification:
+ - Encodings and HRPs:
+ - HD key derivation specification: TODO
+
+ - Needs to be hierarchical, but output only needs to be uniform 32 bytes.
+ - Probably just BLAKE2b-256(derivation_path), in line with our existing primitives.
+
+
+ - Design rationale:
+
+
+ Notes
+ Orchard notes have the structure
+ \((addr, v, \rho, \psi, \mathsf{rcm})\)
+ .
+ \(\psi\)
+ and
+ \(\mathsf{rcm}\)
+ are derived from a random seed (as with Sapling after ZIP 212 ).
+
+
+ Nullifiers
+ Nullifiers for Orchard notes are computed as:
+
+ \(\mathsf{nf} = [F_{\mathsf{nk}}(\rho) + \psi \pmod{p}] \mathcal{G} + \mathsf{cm}\)
+
+ where
+ \(F\)
+ is instantiated with Poseidon, and
+ \(\mathcal{G}\)
+ is a fixed independent base.
+
+ - Poseidon: TODO
+ - Design rationale and considered alternatives:
+
+
+ Signatures
+ Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).
+
+
+
+