<p>This document proposes the Orchard shielded protocol, which defines a new shielded pool with spending keys and payment addresses that are amenable to future scalability improvements.</p>
<p>The Orchard protocol is specified as an update to the Zcash Protocol Specification <aid="id1"class="footnote_reference"href="#orchard-spec">1</a>. 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.</p>
<p>The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:</p>
<ul>
<li>Pallas is used as the "application curve", on which the Orchard protocol itself is implemented (c/f Jubjub).</li>
<li>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).</li>
</ul>
<p>We use (version 10 of) the IETF hash-to-curve Internet Draft <aid="id2"class="footnote_reference"href="#ietf-hash-to-curve">25</a> to implement
<spanclass="math">\(\mathsf{GroupHash}\)</span>
, instead of the BLAKE2s-based mechanism used for Sapling. We specifically use the "simplified SWU" algorithm, which provides an infallible
<spanclass="math">\(\mathsf{GroupHash}\)</span>
.</p>
<p>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.</p>
<p>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.</p>
<p>An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.</p>
<p>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.</p>
<p>Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe-Hopwood Pedersen hash.</p>
<ul>
<li>Design rationale and considered alternatives: <aid="id14"class="footnote_reference"href="#design-tree">21</a></li>
</ul>
</section>
<sectionid="keys-and-addresses"><h3><spanclass="section-heading">Keys and addresses</span><spanclass="section-anchor"><arel="bookmark"href="#keys-and-addresses"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>Orchard keys and payment addresses are structurally similar to Sapling, with the following changes:</p>
<ul>
<li>The proof authorizing key is removed, and
<spanclass="math">\(\mathsf{nk}\)</span>
is now a field element.</li>
<li>
<spanclass="math">\(\mathsf{ivk}\)</span>
is computed as a Sinsemilla commitment instead of a BLAKE2s output.</li>
<li>
<spanclass="math">\(\mathsf{ovk}\)</span>
is derived from
<spanclass="math">\(\mathsf{fvk}\)</span>
, instead of being a component of the spending key.</li>
<li>All diversifiers now result in valid payment addresses.</li>
</ul>
<p>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).</p>
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 <aid="id15"class="footnote_reference"href="#zip-0032">23</a> to Orchard; instead, we define a simple hardened-only derivation mechanism.</p>
<li>Encodings and HRPs: <aid="id18"class="footnote_reference"href="#spec-encoding-addr">12</a><aid="id19"class="footnote_reference"href="#spec-encoding-ivk">13</a><aid="id20"class="footnote_reference"href="#spec-encoding-fvk">14</a><aid="id21"class="footnote_reference"href="#spec-encoding-sk">15</a></li>
<li>HD key derivation specification: TODO
<ul>
<li>Needs to be hierarchical, but output only needs to be uniform 32 bytes.</li>
<li>Probably just <cite>BLAKE2b-256(derivation_path)</cite>, in line with our existing primitives.</li>
<p>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).</p>
<sectionid="security-and-privacy-considerations"><h2><spanclass="section-heading">Security and Privacy Considerations</span><spanclass="section-anchor"><arel="bookmark"href="#security-and-privacy-considerations"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h2>
<td><ahref="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]</a></td>
</tr>
</tbody>
</table>
<tableid="spec-addrs-keys"class="footnote">
<tbody>
<tr>
<th>2</th>
<td><ahref="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#addressesandkeys">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.1: Payment Addresses and Keys</a></td>
</tr>
</tbody>
</table>
<tableid="spec-notes"class="footnote">
<tbody>
<tr>
<th>3</th>
<td><ahref="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#notes">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.2: Notes</a></td>
</tr>
</tbody>
</table>
<tableid="spec-actions"class="footnote">
<tbody>
<tr>
<th>4</th>
<td><ahref="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#actions">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions</a></td>
<td><ahref="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#pallasandvesta">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta</a></td>
</tr>
</tbody>
</table>
<tableid="spec-pasta-grouphash"class="footnote">
<tbody>
<tr>
<th>11</th>
<td><ahref="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretegrouphashpallasandvesta">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta</a></td>
<td><ahref="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
</tr>
</tbody>
</table>
<tableid="ietf-hash-to-curve"class="footnote">
<tbody>
<tr>
<th>25</th>
<td><ahref="https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html">draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves</a></td>
