ZIP 224: The normative reference for Orchard is the protocol spec

This commit is contained in:
Jack Grigg 2021-02-28 02:16:58 +00:00 committed by Daira Hopwood
parent 630280869e
commit 6fa961877c
2 changed files with 76 additions and 55 deletions

View File

@ -17,6 +17,9 @@ Owners: Daira Hopwood <daira@electriccoin.co>
Status: Draft
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://github.com/zcash/zips/issues/435</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<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>
</section>
@ -24,7 +27,8 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<p>TBD</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Orchard protocol is specified as an update to the Zcash Protocol Specification <a id="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 MUST be implemented as specified in the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#orchard-spec">2</a>.</p>
<p>Given that the Orchard protocol 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>
<section id="curves"><h3><span class="section-heading">Curves</span><span class="section-anchor"> <a rel="bookmark" href="#curves"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:</p>
<ul>
@ -33,14 +37,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</ul>
<p>We use the "simplified SWU" algorithm to define an infallible
<span class="math">\(\mathsf{GroupHash}\)</span>
, 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 <a id="id2" class="footnote_reference" href="#ietf-hash-to-curve">26</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
, 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 <a id="id3" class="footnote_reference" href="#ietf-hash-to-curve">27</a> (but the protocol specification takes precedence in the case of any discrepancy).</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>
<ul>
<li>Curve specifications: <a id="id3" class="footnote_reference" href="#spec-pasta">10</a></li>
<li>Curve specifications: <a id="id4" class="footnote_reference" href="#spec-pasta">11</a></li>
<li>
<span class="math">\(\mathsf{GroupHash}\)</span>
: <a id="id4" class="footnote_reference" href="#spec-pasta-grouphash">11</a></li>
<li>Supporting evidence: <a id="id5" class="footnote_reference" href="#pasta-evidence">27</a></li>
: <a id="id5" class="footnote_reference" href="#spec-pasta-grouphash">12</a></li>
<li>Supporting evidence: <a id="id6" class="footnote_reference" href="#pasta-evidence">28</a></li>
</ul>
</section>
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -48,31 +52,31 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<p>This ZIP does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future ZIPs.</p>
<ul>
<li>Halo 2 protocol description: TODO</li>
<li>UltraPLONK Arithmetization: <a id="id6" class="footnote_reference" href="#concepts-upa">16</a></li>
<li>Halo 2 explanation and design rationale: <a id="id7" class="footnote_reference" href="#design-halo2">17</a></li>
<li>UltraPLONK Arithmetization: <a id="id7" class="footnote_reference" href="#concepts-upa">17</a></li>
<li>Halo 2 explanation and design rationale: <a id="id8" class="footnote_reference" href="#design-halo2">18</a></li>
</ul>
</section>
<section id="circuit"><h3><span class="section-heading">Circuit</span><span class="section-anchor"> <a rel="bookmark" href="#circuit"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<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>
<ul>
<li>Action description: <a id="id8" class="footnote_reference" href="#spec-actions">4</a></li>
<li>Circuit statement: <a id="id9" class="footnote_reference" href="#spec-action-statement">5</a></li>
<li>Design rationale: <a id="id10" class="footnote_reference" href="#design-actions">19</a></li>
<li>Action description: <a id="id9" class="footnote_reference" href="#spec-actions">5</a></li>
<li>Circuit statement: <a id="id10" class="footnote_reference" href="#spec-action-statement">6</a></li>
<li>Design rationale: <a id="id11" class="footnote_reference" href="#design-actions">20</a></li>
</ul>
</section>
<section id="commitments"><h3><span class="section-heading">Commitments</span><span class="section-anchor"> <a rel="bookmark" href="#commitments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<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>
<ul>
<li>Sinsemilla hash function: <a id="id11" class="footnote_reference" href="#spec-sinsemilla-hash">7</a></li>
<li>Sinsemilla commitments: <a id="id12" class="footnote_reference" href="#spec-sinsemilla-comm">9</a></li>
<li>Design rationale: <a id="id13" class="footnote_reference" href="#design-commitments">20</a></li>
<li>Sinsemilla hash function: <a id="id12" class="footnote_reference" href="#spec-sinsemilla-hash">8</a></li>
<li>Sinsemilla commitments: <a id="id13" class="footnote_reference" href="#spec-sinsemilla-comm">10</a></li>
<li>Design rationale: <a id="id14" class="footnote_reference" href="#design-commitments">21</a></li>
</ul>
</section>
<section id="commitment-tree"><h3><span class="section-heading">Commitment tree</span><span class="section-anchor"> <a rel="bookmark" href="#commitment-tree"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<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: <a id="id14" class="footnote_reference" href="#design-tree">21</a></li>
<li>Design rationale and considered alternatives: <a id="id15" class="footnote_reference" href="#design-tree">22</a></li>
</ul>
</section>
<section id="keys-and-addresses"><h3><span class="section-heading">Keys and addresses</span><span class="section-anchor"> <a rel="bookmark" href="#keys-and-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -94,11 +98,11 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<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>
<ul>
<li>Key components diagram: <a id="id15" class="footnote_reference" href="#spec-addrs-keys">2</a></li>
<li>Key components specification: <a id="id16" class="footnote_reference" href="#spec-keys">6</a></li>
<li>Encodings and HRPs: <a id="id17" class="footnote_reference" href="#spec-encoding-addr">12</a> <a id="id18" class="footnote_reference" href="#spec-encoding-ivk">13</a> <a id="id19" class="footnote_reference" href="#spec-encoding-fvk">14</a> <a id="id20" class="footnote_reference" href="#spec-encoding-sk">15</a></li>
<li>HD key derivation specification: <a id="id21" class="footnote_reference" href="#zip-0032">23</a></li>
<li>Design rationale: <a id="id22" class="footnote_reference" href="#design-keys">18</a></li>
<li>Key components diagram: <a id="id16" class="footnote_reference" href="#spec-addrs-keys">3</a></li>
<li>Key components specification: <a id="id17" class="footnote_reference" href="#spec-keys">7</a></li>
<li>Encodings and HRPs: <a id="id18" class="footnote_reference" href="#spec-encoding-addr">13</a> <a id="id19" class="footnote_reference" href="#spec-encoding-ivk">14</a> <a id="id20" class="footnote_reference" href="#spec-encoding-fvk">15</a> <a id="id21" class="footnote_reference" href="#spec-encoding-sk">16</a></li>
<li>HD key derivation specification: <a id="id22" class="footnote_reference" href="#zip-0032">24</a></li>
<li>Design rationale: <a id="id23" class="footnote_reference" href="#design-keys">19</a></li>
</ul>
</section>
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -109,9 +113,9 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<span class="math">\(\psi\)</span>
and
<span class="math">\(\mathsf{rcm}\)</span>
are derived from a random seed (as with Sapling after ZIP 212 <a id="id23" class="footnote_reference" href="#zip-0212">24</a>).</p>
are derived from a random seed (as with Sapling after ZIP 212 <a id="id24" class="footnote_reference" href="#zip-0212">25</a>).</p>
<ul>
<li>Orchard notes: <a id="id24" class="footnote_reference" href="#spec-notes">3</a></li>
<li>Orchard notes: <a id="id25" class="footnote_reference" href="#spec-notes">4</a></li>
</ul>
</section>
<section id="nullifiers"><h3><span class="section-heading">Nullifiers</span><span class="section-anchor"> <a rel="bookmark" href="#nullifiers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -126,13 +130,13 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
is a fixed independent base.</p>
<ul>
<li>Poseidon: TODO</li>
<li>Design rationale and considered alternatives: <a id="id25" class="footnote_reference" href="#design-nullifiers">22</a></li>
<li>Design rationale and considered alternatives: <a id="id26" class="footnote_reference" href="#design-nullifiers">23</a></li>
</ul>
</section>
<section id="signatures"><h3><span class="section-heading">Signatures</span><span class="section-anchor"> <a rel="bookmark" href="#signatures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<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>
<ul>
<li>RedPallas: <a id="id26" class="footnote_reference" href="#spec-redpallas">8</a></li>
<li>RedPallas: <a id="id27" class="footnote_reference" href="#spec-redpallas">9</a></li>
</ul>
</section>
</section>
@ -152,7 +156,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
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. <a id="id27" class="footnote_reference" href="#zip-0315">25</a></li>
<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. <a id="id28" class="footnote_reference" href="#zip-0315">26</a></li>
</ul>
</li>
</ul>
@ -172,10 +176,18 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<p>This ZIP is proposed to activate with Network Upgrade 5.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="orchard-spec" class="footnote">
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="orchard-spec" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="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>
@ -183,7 +195,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-addrs-keys" class="footnote">
<tbody>
<tr>
<th>2</th>
<th>3</th>
<td><a href="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>
@ -191,7 +203,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-notes" class="footnote">
<tbody>
<tr>
<th>3</th>
<th>4</th>
<td><a href="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>
@ -199,7 +211,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-actions" class="footnote">
<tbody>
<tr>
<th>4</th>
<th>5</th>
<td><a href="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>
</tr>
</tbody>
@ -207,7 +219,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-action-statement" class="footnote">
<tbody>
<tr>
<th>5</th>
<th>6</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#actionstatement">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. 4.17.4: Action Statement (Orchard)</a></td>
</tr>
</tbody>
@ -215,7 +227,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-keys" class="footnote">
<tbody>
<tr>
<th>6</th>
<th>7</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 4.2.3: Orchard Key Components</a></td>
</tr>
</tbody>
@ -223,7 +235,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-sinsemilla-hash" class="footnote">
<tbody>
<tr>
<th>7</th>
<th>8</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretesinsemillahash">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function</a></td>
</tr>
</tbody>
@ -231,7 +243,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-redpallas" class="footnote">
<tbody>
<tr>
<th>8</th>
<th>9</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretereddsa">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas</a></td>
</tr>
</tbody>
@ -239,7 +251,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-sinsemilla-comm" class="footnote">
<tbody>
<tr>
<th>9</th>
<th>10</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretesinsemillacommit">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments</a></td>
</tr>
</tbody>
@ -247,7 +259,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-pasta" class="footnote">
<tbody>
<tr>
<th>10</th>
<th>11</th>
<td><a href="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>
@ -255,7 +267,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-pasta-grouphash" class="footnote">
<tbody>
<tr>
<th>11</th>
<th>12</th>
<td><a href="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>
</tr>
</tbody>
@ -263,7 +275,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-encoding-addr" class="footnote">
<tbody>
<tr>
<th>12</th>
<th>13</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.5: Orchard Payment Address</a></td>
</tr>
</tbody>
@ -271,7 +283,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-encoding-ivk" class="footnote">
<tbody>
<tr>
<th>13</th>
<th>14</th>
<td><a href="https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.8: Orchard Incoming Viewing Keys</a></td>
</tr>
</tbody>
@ -279,7 +291,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-encoding-fvk" class="footnote">
<tbody>
<tr>
<th>14</th>
<th>15</th>
<td>TODO</td>
</tr>
</tbody>
@ -287,7 +299,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="spec-encoding-sk" class="footnote">
<tbody>
<tr>
<th>15</th>
<th>16</th>
<td>TODO</td>
</tr>
</tbody>
@ -295,7 +307,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="concepts-upa" class="footnote">
<tbody>
<tr>
<th>16</th>
<th>17</th>
<td><a href="https://zcash.github.io/halo2/concepts/arithmetization.html">The halo2 Book: 1.2 UltraPLONK Arithmetization</a></td>
</tr>
</tbody>
@ -303,7 +315,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="design-halo2" class="footnote">
<tbody>
<tr>
<th>17</th>
<th>18</th>
<td><a href="https://zcash.github.io/halo2/design/proving-system.html">The halo2 Book: 3.1. Proving system</a></td>
</tr>
</tbody>
@ -311,7 +323,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="design-keys" class="footnote">
<tbody>
<tr>
<th>18</th>
<th>19</th>
<td><a href="https://zcash.github.io/orchard/design/keys.html">The Orchard Book: 3.1. Keys and addresses</a></td>
</tr>
</tbody>
@ -319,7 +331,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="design-actions" class="footnote">
<tbody>
<tr>
<th>19</th>
<th>20</th>
<td><a href="https://zcash.github.io/orchard/design/actions.html">The Orchard Book: 3.2. Actions</a></td>
</tr>
</tbody>
@ -327,7 +339,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="design-commitments" class="footnote">
<tbody>
<tr>
<th>20</th>
<th>21</th>
<td><a href="https://zcash.github.io/orchard/design/commitments.html">The Orchard Book: 3.3. Commitments</a></td>
</tr>
</tbody>
@ -335,7 +347,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="design-tree" class="footnote">
<tbody>
<tr>
<th>21</th>
<th>22</th>
<td><a href="https://zcash.github.io/orchard/design/commitment-tree.html">The Orchard Book: 3.4. Commitment tree</a></td>
</tr>
</tbody>
@ -343,7 +355,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="design-nullifiers" class="footnote">
<tbody>
<tr>
<th>22</th>
<th>23</th>
<td><a href="https://zcash.github.io/orchard/design/nullifiers.html">The Orchard Book: 3.5. Nullifiers</a></td>
</tr>
</tbody>
@ -351,7 +363,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>23</th>
<th>24</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
@ -359,7 +371,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="zip-0212" class="footnote">
<tbody>
<tr>
<th>24</th>
<th>25</th>
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
</tr>
</tbody>
@ -367,7 +379,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="zip-0315" class="footnote">
<tbody>
<tr>
<th>25</th>
<th>26</th>
<td><a href="zip-0315">ZIP 315: Best Practices for Wallet Handling of Multiple Pools</a></td>
</tr>
</tbody>
@ -375,7 +387,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="ietf-hash-to-curve" class="footnote">
<tbody>
<tr>
<th>26</th>
<th>27</th>
<td><a href="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>
</tr>
</tbody>
@ -383,7 +395,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="pasta-evidence" class="footnote">
<tbody>
<tr>
<th>27</th>
<th>28</th>
<td><a href="https://github.com/zcash/pasta">Pallas/Vesta supporting evidence</a></td>
</tr>
</tbody>

View File

@ -12,6 +12,12 @@
Discussions-To: <https://github.com/zcash/zips/issues/435>
Terminology
===========
The key word "MUST" in this document is to be interpreted as described in RFC 2119. [#RFC2119]_
Abstract
========
@ -29,10 +35,12 @@ TBD
Specification
=============
The Orchard protocol is specified as an update to the Zcash Protocol Specification
[#orchard-spec]_. 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.
The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification
[#orchard-spec]_.
Given that the Orchard protocol 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
------
@ -232,6 +240,7 @@ This ZIP is proposed to activate with Network Upgrade 5.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#orchard-spec] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal] <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf>`_
.. [#spec-addrs-keys] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.1: Payment Addresses and Keys <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#addressesandkeys>`_
.. [#spec-notes] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.2: Notes <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#notes>`_