mirror of https://github.com/zcash/zips.git
ZIP 224: fix a broken link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
8e2215c577
commit
dba647f121
|
|
@ -61,30 +61,30 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard uses the Halo 2 proving system <a id="id11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.</p>
|
||||
<p>Orchard uses the Halo 2 proving system <a id="id11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization <a id="id12" class="footnote_reference" href="#halo2-arithmetization">22</a>, instead of Groth16 and R1CS.</p>
|
||||
<p>This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.</p>
|
||||
</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" class="section-anchor" 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="id12" class="footnote_reference" href="#protocol-actions">8</a></li>
|
||||
<li>Circuit statement: <a id="id13" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
|
||||
<li>Design rationale: <a id="id14" class="footnote_reference" href="#orchard-actions">25</a></li>
|
||||
<li>Action description: <a id="id13" class="footnote_reference" href="#protocol-actions">8</a></li>
|
||||
<li>Circuit statement: <a id="id14" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
|
||||
<li>Design rationale: <a id="id15" class="footnote_reference" href="#orchard-actions">25</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" class="section-anchor" 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 PLONKish-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.</p>
|
||||
<ul>
|
||||
<li>Sinsemilla hash function: <a id="id15" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
|
||||
<li>Sinsemilla commitments: <a id="id16" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
|
||||
<li>Design rationale: <a id="id17" class="footnote_reference" href="#orchard-commitments">26</a></li>
|
||||
<li>Sinsemilla hash function: <a id="id16" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
|
||||
<li>Sinsemilla commitments: <a id="id17" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
|
||||
<li>Design rationale: <a id="id18" class="footnote_reference" href="#orchard-commitments">26</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" class="section-anchor" 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="id18" class="footnote_reference" href="#orchard-tree">27</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id19" class="footnote_reference" href="#orchard-tree">27</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -105,14 +105,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
, instead of being a component of the spending key.</li>
|
||||
<li>All diversifiers now result in valid payment addresses.</li>
|
||||
</ul>
|
||||
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id19" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id20" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</p>
|
||||
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</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="id21" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
|
||||
<li>Key components specification: <a id="id22" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
|
||||
<li>Encodings: <a id="id23" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="id24" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="id25" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="id26" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
|
||||
<li>HD key derivation specification: <a id="id27" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="id28" class="footnote_reference" href="#orchard-keys">24</a></li>
|
||||
<li>Key components diagram: <a id="id22" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
|
||||
<li>Key components specification: <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
|
||||
<li>Encodings: <a id="id24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="id25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="id27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
|
||||
<li>HD key derivation specification: <a id="id28" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="id29" class="footnote_reference" href="#orchard-keys">24</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -123,9 +123,9 @@ Discussions-To: <<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="id29" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
are derived from a random seed (as with Sapling after ZIP 212 <a id="id30" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
<ul>
|
||||
<li>Orchard notes: <a id="id30" class="footnote_reference" href="#protocol-notes">7</a></li>
|
||||
<li>Orchard notes: <a id="id31" class="footnote_reference" href="#protocol-notes">7</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -139,14 +139,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<span class="math">\(\mathcal{G}\)</span>
|
||||
is a fixed independent base.</p>
|
||||
<ul>
|
||||
<li>Poseidon: <a id="id31" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id32" class="footnote_reference" href="#orchard-nullifiers">28</a></li>
|
||||
<li>Poseidon: <a id="id32" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id33" class="footnote_reference" href="#orchard-nullifiers">28</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" class="section-anchor" 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="id33" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
|
||||
<li>RedPallas: <a id="id34" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -166,7 +166,7 @@ Discussions-To: <<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 user bases 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="id34" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
<li>Wallets should take steps to migrate their user bases 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="id35" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ Proving system
|
|||
--------------
|
||||
|
||||
Orchard uses the Halo 2 proving system [#halo2-proving-system]_ with the PLONKish
|
||||
arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.
|
||||
arithmetization [#halo2-arithmetization]_, instead of Groth16 and R1CS.
|
||||
|
||||
This proposal does not make use of Halo 2's support for recursive proofs, but this is
|
||||
expected to be leveraged by future protocol updates.
|
||||
|
|
|
|||
Loading…
Reference in New Issue