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 the "simplified SWU" algorithm to define an infallible \(\mathsf{GroupHash}\) , instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft 27 (but the protocol specification takes precedence in the case of any discrepancy).

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: 11
• \(\mathsf{GroupHash}\) : 12
• Supporting evidence: 28

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: 17
• Halo 2 explanation and design rationale: 18

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: 5
• Circuit statement: 6
• Design rationale: 20

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: 8
• Sinsemilla commitments: 10
• Design rationale: 21

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: 22

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 hardened-only derivation mechanism (similar to Sprout).

• Key components diagram: 3
• Key components specification: 7
• Encodings and HRPs: 13 14 15 16
• HD key derivation specification: 24
• Design rationale: 19

Notes

Orchard notes have the structure \((addr, v, \rho, \psi, \mathsf{rcm}).\) \(\rho\) is set to the nullifier of the spent note in the same action, which ensures it is unique. \(\psi\) and \(\mathsf{rcm}\) are derived from a random seed (as with Sapling after ZIP 212 25).

• Orchard notes: 4

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: 23

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).

• RedPallas: 9