<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>
, 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 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).</p>
<li>Encodings and HRPs: <aid="id17"class="footnote_reference"href="#spec-encoding-addr">12</a><aid="id18"class="footnote_reference"href="#spec-encoding-ivk">13</a><aid="id19"class="footnote_reference"href="#spec-encoding-fvk">14</a><aid="id20"class="footnote_reference"href="#spec-encoding-sk">15</a></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>
<p>This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an Orchard-specific
transaction field. This has the following considerations:</p>
<ul>
<li>The Orchard pool forms a separate anonymity set from the Sprout and Sapling pools. The new pool will start with zero notes (as Sapling did at its deployment), but transactions within Orchard will increase the size of the anonymity set more rapidly than Sapling, due to the arity-hiding nature of Orchard actions.</li>
field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.</li>
<li>Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
<ul>
<li>Wallets should take steps to migrate their userbases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <aid="id27"class="footnote_reference"href="#zip-0315">25</a></li>
<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="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>
