mirror of https://github.com/zcash/zips.git
Merge pull request #448 from str4d/zip-224
Updates to ZIP 32 and ZIP 224 for Orchard
This commit is contained in:
Daira Hopwood
GitHub
commit
ecec91883b
|
|
@ -98,7 +98,7 @@ Index of ZIPs
|
|||
<tr> <td><span class="reserved">219</span></td> <td class="left"><a class="reserved" href="zip-0219.rst">Disabling Addition of New Value to the Sapling Chain Value Pool</a></td> <td>Reserved</td>
|
||||
<tr> <td>221</td> <td class="left"><a href="zip-0221.rst">FlyClient - Consensus-Layer Changes</a></td> <td>Final</td>
|
||||
<tr> <td>222</td> <td class="left"><a href="zip-0222.rst">Transparent Zcash Extensions</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">224</span></td> <td class="left"><a class="reserved" href="zip-0224.rst">Orchard Shielded Protocol</a></td> <td>Reserved</td>
|
||||
<tr> <td>224</td> <td class="left"><a href="zip-0224.rst">Orchard Shielded Protocol</a></td> <td>Proposed</td>
|
||||
<tr> <td>225</td> <td class="left"><a href="zip-0225.rst">Version 5 Transaction Format</a></td> <td>Proposed</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>244</td> <td class="left"><a href="zip-0244.rst">Transaction Identifier Non-Malleability</a></td> <td>Proposed</td>
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@
|
|||
<tr> <td><span class="reserved">219</span></td> <td class="left"><a class="reserved" href="zip-0219">Disabling Addition of New Value to the Sapling Chain Value Pool</a></td> <td>Reserved</td>
|
||||
<tr> <td>221</td> <td class="left"><a href="zip-0221">FlyClient - Consensus-Layer Changes</a></td> <td>Final</td>
|
||||
<tr> <td>222</td> <td class="left"><a href="zip-0222">Transparent Zcash Extensions</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">224</span></td> <td class="left"><a class="reserved" href="zip-0224">Orchard Shielded Protocol</a></td> <td>Reserved</td>
|
||||
<tr> <td>224</td> <td class="left"><a href="zip-0224">Orchard Shielded Protocol</a></td> <td>Proposed</td>
|
||||
<tr> <td>225</td> <td class="left"><a href="zip-0225">Version 5 Transaction Format</a></td> <td>Proposed</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>244</td> <td class="left"><a href="zip-0244">Transaction Identifier Non-Malleability</a></td> <td>Proposed</td>
|
||||
|
|
|
|||
309
zip-0032.html
309
zip-0032.html
|
|
@ -23,25 +23,33 @@ License: MIT</pre>
|
|||
</p>
|
||||
<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 words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">12</a>.</p>
|
||||
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">13</a>.</p>
|
||||
<p>A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">9</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 proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id3" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
|
||||
<p>The specification has three parts. The first part defines a system for deriving a tree of Sapling key components from a single seed. The second part defines an equivalent, but independent, system for Sprout key components (which have a different internal construction). The third part shows how to use these trees in the context of existing BIP 44 <a id="id4" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
|
||||
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
|
||||
<p>The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):</p>
|
||||
<ul>
|
||||
<li>Sapling</li>
|
||||
<li>Sprout (for compatibility, effectively unused)</li>
|
||||
<li>Orchard</li>
|
||||
</ul>
|
||||
<p>The last part shows how to use these trees in the context of existing BIP 44 <a id="id5" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
|
||||
<p>This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>BIP 32 <a id="id5" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="id6" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
|
||||
<p>BIP 32 <a id="id6" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="id7" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
|
||||
<ul>
|
||||
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
|
||||
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id7" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
|
||||
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
|
||||
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
|
||||
<li>View authority or spend authority can be delegated independently for sub-trees without compromising the master seed.</li>
|
||||
</ul>
|
||||
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
|
||||
</section>
|
||||
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">8</a>. They are reproduced here for convenience:</p>
|
||||
<p>Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification <a id="id9" class="footnote_reference" href="#protocol">8</a>. They are reproduced here for convenience:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
|
||||
|
|
@ -93,7 +101,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
|
||||
is the representation of the Jubjub elliptic curve point
|
||||
<span class="math">\(P\)</span>
|
||||
as a bit sequence, defined in <a id="id9" class="footnote_reference" href="#protocol-jubjub">12</a>.</li>
|
||||
as a bit sequence, defined in <a id="id10" class="footnote_reference" href="#protocol-jubjub">13</a>.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
|
||||
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
|
||||
|
|
@ -126,9 +134,9 @@ License: MIT</pre>
|
|||
<span class="math">\(d\)</span>
|
||||
to a base point on the Jubjub elliptic curve, or to
|
||||
<span class="math">\(\bot\)</span>
|
||||
if the diversifier is invalid. It is instantiated in <a id="id10" class="footnote_reference" href="#protocol-concretediversifyhash">10</a>.</li>
|
||||
if the diversifier is invalid. It is instantiated in <a id="id11" class="footnote_reference" href="#protocol-concretediversifyhash">11</a>.</li>
|
||||
</ul>
|
||||
<p>The following algorithm standardized in <a id="id11" class="footnote_reference" href="#nist-sp-800-38g">16</a> is used:</p>
|
||||
<p>The following algorithm standardized in <a id="id12" class="footnote_reference" href="#nist-sp-800-38g">20</a> is used:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\)</span>
|
||||
|
|
@ -162,12 +170,12 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{LEOS2IP}_\ell(S)\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling specification), which is the opposite of BIP 32.</p>
|
||||
<p>We adapt the path notation of BIP 32 <a id="id12" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
|
||||
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.</p>
|
||||
<p>We adapt the path notation of BIP 32 <a id="id13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
|
||||
<span class="math">\('\)</span>
|
||||
) to indicate hardened derivation (
|
||||
<span class="math">\(i' = i + 2^{31}\)</span>
|
||||
) as in BIP 44 <a id="id13" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
) as in BIP 44 <a id="id14" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{CDKsk}(\mathsf{CDKsk}(\mathsf{CDKsk}(m_\mathsf{Sprout}, a'), b), c)\)</span>
|
||||
|
|
@ -256,7 +264,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{nsk}_m\)</span>
|
||||
, and
|
||||
<span class="math">\(\mathsf{ovk}_m\)</span>
|
||||
via the standard Sapling derivation <a id="id14" class="footnote_reference" href="#protocol-saplingkeycomponents">9</a>:
|
||||
via the standard Sapling derivation <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">10</a>:
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
|
||||
|
|
@ -312,7 +320,7 @@ License: MIT</pre>
|
|||
<span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
|
||||
is the full viewing key derived from
|
||||
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span>
|
||||
as described in <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">9</a>.</li>
|
||||
as described in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">10</a>.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Split
|
||||
|
|
@ -354,9 +362,9 @@ License: MIT</pre>
|
|||
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Let
|
||||
<span class="math">\(\mathcal{G}\)</span>
|
||||
be as defined in <a id="id16" class="footnote_reference" href="#protocol-concretespendauthsig">11</a> and let
|
||||
be as defined in <a id="id17" class="footnote_reference" href="#protocol-concretespendauthsig">12</a> and let
|
||||
<span class="math">\(\mathcal{H}\)</span>
|
||||
be as defined in <a id="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">9</a>.</p>
|
||||
be as defined in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">10</a>.</p>
|
||||
<p>
|
||||
<span class="math">\(\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
|
||||
<span class="math">\(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\)</span>
|
||||
|
|
@ -411,7 +419,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="diversifier-derivation"><h3><span class="section-heading">Diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="sapling-diversifier-derivation"><h3><span class="section-heading">Sapling diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key
|
||||
<span class="math">\(\mathsf{dk}\)</span>
|
||||
. To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:</p>
|
||||
|
|
@ -458,7 +466,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
|
||||
be the 32-byte encoding of
|
||||
<span class="math">\(\mathsf{a_{sk}}\)</span>
|
||||
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id18" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">15</a>.</p>
|
||||
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id19" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">15</a>.</p>
|
||||
<p>Let
|
||||
<span class="math">\(\mathsf{DecodeASK}(ASK)\)</span>
|
||||
be the result of clearing the 4 most significant bits of the first byte of
|
||||
|
|
@ -532,10 +540,121 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-orchard-key-derivation"><h2><span class="section-heading">Specification: Orchard key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-orchard-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we define Orchard key derivation very similarly to Sprout above: only hardened derivation is supported.</p>
|
||||
<section id="orchard-extended-keys"><h3><span class="section-heading">Orchard extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We represent an Orchard extended spending key as
|
||||
<span class="math">\((\mathsf{sk, c}),\)</span>
|
||||
where
|
||||
<span class="math">\(\mathsf{sk}\)</span>
|
||||
is the normal Orchard spending key (opaque 32 bytes), and
|
||||
<span class="math">\(\mathsf{c}\)</span>
|
||||
is the chain code.</p>
|
||||
</section>
|
||||
<section id="orchard-master-key-generation"><h3><span class="section-heading">Orchard master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-master-key-generation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Let
|
||||
<span class="math">\(S\)</span>
|
||||
be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.</p>
|
||||
<ul>
|
||||
<li>Calculate
|
||||
<span class="math">\(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Orchard”}, S)\)</span>
|
||||
.</li>
|
||||
<li>Split
|
||||
<span class="math">\(I\)</span>
|
||||
into two 32-byte sequences,
|
||||
<span class="math">\(I_L\)</span>
|
||||
and
|
||||
<span class="math">\(I_R\)</span>
|
||||
.</li>
|
||||
<li>Use
|
||||
<span class="math">\(I_L\)</span>
|
||||
as the master spending key
|
||||
<span class="math">\(\mathsf{sk}_m\)</span>
|
||||
.</li>
|
||||
<li>Use
|
||||
<span class="math">\(I_R\)</span>
|
||||
as the master chain code
|
||||
<span class="math">\(\mathsf{c}_m\)</span>
|
||||
.</li>
|
||||
<li>Return
|
||||
<span class="math">\((\mathsf{sk}_m, \mathsf{c}_m)\)</span>
|
||||
as the master extended spending key
|
||||
<span class="math">\(m_\mathsf{Orchard}\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="orchard-child-key-derivation"><h3><span class="section-heading">Orchard child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>
|
||||
<span class="math">\(\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\)</span>
|
||||
<span class="math">\(\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)\)</span>
|
||||
</p>
|
||||
<ul>
|
||||
<li>Check whether
|
||||
<span class="math">\(i \geq 2^{31}\)</span>
|
||||
(whether the child is a hardened key).
|
||||
<ul>
|
||||
<li>If so (hardened child): let
|
||||
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
|
||||
.</li>
|
||||
<li>If not (normal child): return failure.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Split
|
||||
<span class="math">\(I\)</span>
|
||||
into two 32-byte sequences,
|
||||
<span class="math">\(I_L\)</span>
|
||||
and
|
||||
<span class="math">\(I_R\)</span>
|
||||
.</li>
|
||||
<li>Use
|
||||
<span class="math">\(I_L\)</span>
|
||||
as the child spending key
|
||||
<span class="math">\(\mathsf{sk}_{i}\)</span>
|
||||
.</li>
|
||||
<li>Use
|
||||
<span class="math">\(I_R\)</span>
|
||||
as the child chain code
|
||||
<span class="math">\(\mathsf{c}_i\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="orchard-diversifier-derivation"><h3><span class="section-heading">Orchard diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.</p>
|
||||
<p>Given an Orchard extended spending key
|
||||
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
|
||||
:</p>
|
||||
<ul>
|
||||
<li>Let
|
||||
<span class="math">\(\mathit{FVK}_i\)</span>
|
||||
be the raw encoding of the Orchard full viewing key for
|
||||
<span class="math">\(\mathsf{sk}_i\)</span>
|
||||
(as specified in <a id="id20" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>).</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathit{FVK}_i, [\texttt{0x82}]))\)</span>
|
||||
.</li>
|
||||
<li>Let
|
||||
<span class="math">\(j\)</span>
|
||||
be the index of the desired diversifier, in the range
|
||||
<span class="math">\(0\,.\!. 2^{88} - 1\)</span>
|
||||
.</li>
|
||||
<li>
|
||||
<span class="math">\(d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of
|
||||
<span class="math">\(j\)</span>
|
||||
yield valid diversifiers.</p>
|
||||
<p>The default diversifier for
|
||||
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
|
||||
is defined to be
|
||||
<span class="math">\(d_{i,0}.\)</span>
|
||||
</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id19" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id21" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Both Sprout and Sapling key paths have the following three path levels at the top, all of which use hardened derivation:</p>
|
||||
<p>Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(purpose\)</span>
|
||||
|
|
@ -546,7 +665,7 @@ License: MIT</pre>
|
|||
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
|
||||
<li>
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
: a constant identifying the cybercoin that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id20" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin testnets share
|
||||
: a constant identifying the cybercoin that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id22" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin testnets share
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
index
|
||||
<span class="math">\(1\)</span>
|
||||
|
|
@ -555,9 +674,9 @@ License: MIT</pre>
|
|||
<span class="math">\(account\)</span>
|
||||
: numbered from index
|
||||
<span class="math">\(0\)</span>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="id21" class="footnote_reference" href="#bip-0044">5</a>.</li>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="id23" class="footnote_reference" href="#bip-0044">5</a>.</li>
|
||||
</ul>
|
||||
<p>Unlike BIP 44, neither Sprout nor Sapling have a
|
||||
<p>Unlike BIP 44, none of the shielded key paths have a
|
||||
<span class="math">\(change\)</span>
|
||||
path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.</p>
|
||||
</section>
|
||||
|
|
@ -577,7 +696,7 @@ License: MIT</pre>
|
|||
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
|
||||
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
|
||||
<span class="math">\(address\_index\)</span>
|
||||
path level as in <a id="id22" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
path level as in <a id="id24" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
|
||||
|
|
@ -592,15 +711,30 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="orchard-key-path"><h3><span class="section-heading">Orchard key path</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
|
||||
<p>The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range
|
||||
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
|
||||
:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses for a given account, if they wish to enable users to give a unique address to each recipient.</p>
|
||||
<p>Note that a given account can have a maximum of
|
||||
<span class="math">\(2^{88}\)</span>
|
||||
payment addresses (unlike Sapling, all Orchard diversifiers are valid).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-fingerprints-and-tags"><h2><span class="section-heading">Specification: Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#specification-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(FVK\)</span>
|
||||
(as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">14</a>) is given by:</p>
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id25" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">16</a>) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, FVK)\)</span>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>It MAY be used to uniquely identify a particular Sapling full viewing key.</p>
|
||||
|
|
@ -608,16 +742,28 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
|
||||
<span class="math">\(ADDR\)</span>
|
||||
(as specified in <a id="id24" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">13</a>, including the lead bytes) is given by:</p>
|
||||
<span class="math">\(\mathit{ADDR}\)</span>
|
||||
(as specified in <a id="id26" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">14</a>, including the lead bytes) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)\)</span>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>It MAY be used to uniquely identify a particular Sprout payment address.</p>
|
||||
<p>A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address fingerprint. It is intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify a particular address.</p>
|
||||
</section>
|
||||
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id27" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>It MAY be used to uniquely identify a particular Orchard full viewing key.</p>
|
||||
<p>An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.</p>
|
||||
</section>
|
||||
<section id="seed-fingerprints"><h3><span class="section-heading">Seed Fingerprints</span><span class="section-anchor"> <a rel="bookmark" href="#seed-fingerprints"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "seed fingerprint" for the master seed
|
||||
<span class="math">\(S\)</span>
|
||||
|
|
@ -634,7 +780,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id25" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id28" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
|
||||
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Sapling extended spending key
|
||||
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
|
||||
|
|
@ -731,6 +877,35 @@ License: MIT</pre>
|
|||
.</p>
|
||||
<p>When encoded as Bech32, the Human-Readable Part is <code>zxsprout</code> for the production network, or <code>zxtestsprout</code> for the test network. Sprout extended spending keys are encoded using Bech32 even though other Sprout keys and addresses are encoded using Base58Check.</p>
|
||||
</section>
|
||||
<section id="orchard-extended-spending-keys"><h3><span class="section-heading">Orchard extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>An Orchard extended spending key
|
||||
<span class="math">\((\mathsf{sk, c})\)</span>
|
||||
, at depth
|
||||
<span class="math">\(depth\)</span>
|
||||
, with parent full viewing key tag
|
||||
<span class="math">\(parent\_fvk\_tag\)</span>
|
||||
and child number
|
||||
<span class="math">\(i\)</span>
|
||||
, is represented as a byte sequence:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>For the master extended spending key,
|
||||
<span class="math">\(depth\)</span>
|
||||
is
|
||||
<span class="math">\(0\)</span>
|
||||
,
|
||||
<span class="math">\(parent\_fvk\_tag\)</span>
|
||||
is 4 zero bytes, and
|
||||
<span class="math">\(i\)</span>
|
||||
is
|
||||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
|
||||
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id29" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">19</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBC</p>
|
||||
|
|
@ -804,55 +979,55 @@ License: MIT</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
|
||||
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2020.1.17 or later [Orchard proposal]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2020.1.17. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingkeycomponents" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2020.1.15. Section 4.2.2: Sapling Key Components</a></td>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/nu5.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2020.1.17. Section 4.2.2: Sapling Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretediversifyhash" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function</a></td>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/nu5.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2020.1.17. Section 5.4.1.6: DiversifyHash Hash Function</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretespendauthsig" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature</a></td>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/nu5.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2020.1.17. Section 5.4.6.1: Spend Authorization Signature</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-jubjub" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub</a></td>
|
||||
<th>13</th>
|
||||
<td><a href="protocol/nu5.pdf#jubjub">Zcash Protocol Specification, Version 2020.1.17. Section 5.4.8.3: Jubjub</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-sproutpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.3: Sprout Shielded Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.7: Sapling Full Viewing Keys</a></td>
|
||||
<td><a href="protocol/nu5.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.17. Section 5.6.2.1: Sprout Shielded Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -860,14 +1035,46 @@ License: MIT</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.15. Section 5.6.8: Sprout Spending Keys</a></td>
|
||||
<td><a href="protocol/nu5.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.17. Section 5.6.2.3: Sprout Spending Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<td><a href="protocol/nu5.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.17. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingspendingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<td><a href="protocol/nu5.pdf#saplingspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.17. Section 5.6.3.4: Sapling Spending Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.17. Section 5.6.4.3: Orchard Full Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardspendingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.17. Section 5.6.4.4: Orchard Spending Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="nist-sp-800-38g" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<th>20</th>
|
||||
<td><a href="https://dx.doi.org/10.6028/NIST.SP.800-38G">NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
183
zip-0032.rst
183
zip-0032.rst
|
|
@ -22,6 +22,12 @@ The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpret
|
|||
|
||||
"Jubjub" refers to the elliptic curve defined in [#protocol-jubjub]_.
|
||||
|
||||
A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive
|
||||
descendant keys and addresses of that key.
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash
|
||||
Protocol Specification [#protocol-networks]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
|
@ -29,10 +35,15 @@ Abstract
|
|||
This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32
|
||||
[#bip-0032]_, to support Zcash's shielded addresses.
|
||||
|
||||
The specification has three parts. The first part defines a system for deriving a tree of Sapling key
|
||||
components from a single seed. The second part defines an equivalent, but independent, system for Sprout key
|
||||
components (which have a different internal construction). The third part shows how to use these trees in the
|
||||
context of existing BIP 44 [#bip-0044]_ wallets.
|
||||
The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a
|
||||
tree of key components from a single seed, for the following shielded pools (which have different internal
|
||||
key structures):
|
||||
|
||||
- Sapling
|
||||
- Sprout (for compatibility, effectively unused)
|
||||
- Orchard
|
||||
|
||||
The last part shows how to use these trees in the context of existing BIP 44 [#bip-0044]_ wallets.
|
||||
|
||||
This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent
|
||||
Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses
|
||||
|
|
@ -63,7 +74,7 @@ shielded addresses, it is desirable to have a standard mechanism for deriving th
|
|||
Conventions
|
||||
===========
|
||||
|
||||
Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification
|
||||
Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification
|
||||
[#protocol]_. They are reproduced here for convenience:
|
||||
|
||||
- :math:`\mathsf{truncate}_k(S)` means the sequence formed from the first :math:`k` elements of :math:`S`.
|
||||
|
|
@ -113,8 +124,8 @@ We also define the following conversion function:
|
|||
little-endian order the integer :math:`k` in range :math:`\{ 0\,.\!. 2^\ell - 1 \}`. It is the reverse
|
||||
operation of :math:`\mathsf{LEOS2IP}_\ell(S)`.
|
||||
|
||||
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling
|
||||
specification), which is the opposite of BIP 32.
|
||||
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard
|
||||
specifications), which is the opposite of BIP 32.
|
||||
|
||||
We adapt the path notation of BIP 32 [#bip-0032]_ to describe shielded HD paths, using prime marks (:math:`'`) to
|
||||
indicate hardened derivation (:math:`i' = i + 2^{31}`) as in BIP 44 [#bip-0044]_:
|
||||
|
|
@ -238,8 +249,8 @@ in [#protocol-saplingkeycomponents]_.
|
|||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
|
||||
- :math:`\mathsf{c}_i = I_R`.
|
||||
|
||||
Diversifier derivation
|
||||
----------------------
|
||||
Sapling diversifier derivation
|
||||
------------------------------
|
||||
|
||||
The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key :math:`\mathsf{dk}`.
|
||||
To prevent the diversifier leaking how many diversified addresses have already been generated for an account,
|
||||
|
|
@ -309,6 +320,71 @@ Sprout child key derivation
|
|||
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
|
||||
|
||||
|
||||
Specification: Orchard key derivation
|
||||
=====================================
|
||||
|
||||
The derivation mechanism for Sapling addresses specified above incurs significant complexity to support
|
||||
non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for
|
||||
non-hardened derivation appear. With that in mind, we define Orchard key derivation very similarly to
|
||||
Sprout above: only hardened derivation is supported.
|
||||
|
||||
Orchard extended keys
|
||||
---------------------
|
||||
|
||||
We represent an Orchard extended spending key as :math:`(\mathsf{sk, c}),` where :math:`\mathsf{sk}`
|
||||
is the normal Orchard spending key (opaque 32 bytes), and :math:`\mathsf{c}` is the chain code.
|
||||
|
||||
Orchard master key generation
|
||||
-----------------------------
|
||||
|
||||
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
|
||||
|
||||
- Calculate :math:`I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Orchard”}, S)`.
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`.
|
||||
- Use :math:`I_R` as the master chain code :math:`\mathsf{c}_m`.
|
||||
- Return :math:`(\mathsf{sk}_m, \mathsf{c}_m)` as the master extended spending key
|
||||
:math:`m_\mathsf{Orchard}`.
|
||||
|
||||
Orchard child key derivation
|
||||
----------------------------
|
||||
|
||||
:math:`\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)`
|
||||
|
||||
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
|
||||
|
||||
- If so (hardened child): let
|
||||
:math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))`.
|
||||
- If not (normal child): return failure.
|
||||
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Use :math:`I_L` as the child spending key :math:`\mathsf{sk}_{i}`.
|
||||
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
|
||||
|
||||
Orchard diversifier derivation
|
||||
------------------------------
|
||||
|
||||
As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without
|
||||
leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so
|
||||
by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending
|
||||
key. This means that the full viewing key provides the capability to determine the position of a diversifier
|
||||
within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the
|
||||
key structure.
|
||||
|
||||
Given an Orchard extended spending key :math:`(\mathsf{sk}_i, \mathsf{c}_i)`:
|
||||
|
||||
- Let :math:`\mathit{FVK}_i` be the raw encoding of the Orchard full viewing key for :math:`\mathsf{sk}_i`
|
||||
(as specified in [#protocol-orchardfullviewingkeyencoding]_).
|
||||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathit{FVK}_i, [\texttt{0x82}]))`.
|
||||
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
|
||||
- :math:`d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
|
||||
|
||||
Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of :math:`j` yield
|
||||
valid diversifiers.
|
||||
|
||||
The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.`
|
||||
|
||||
|
||||
Specification: Wallet usage
|
||||
===========================
|
||||
|
||||
|
|
@ -319,8 +395,8 @@ altered the design where it makes sense to leverage features of shielded address
|
|||
Key path levels
|
||||
---------------
|
||||
|
||||
Both Sprout and Sapling key paths have the following three path levels at the top, all of which use hardened
|
||||
derivation:
|
||||
Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use
|
||||
hardened derivation:
|
||||
|
||||
- :math:`purpose`: a constant set to :math:`32'` (or :math:`\texttt{0x80000020}`) following the BIP 43
|
||||
recommendation. It indicates that the subtree of this node is used according to this specification.
|
||||
|
|
@ -333,8 +409,8 @@ derivation:
|
|||
- :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in
|
||||
BIP 44 [#bip-0044]_.
|
||||
|
||||
Unlike BIP 44, neither Sprout nor Sapling have a :math:`change` path level. The use of change addresses in
|
||||
Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by
|
||||
Unlike BIP 44, none of the shielded key paths have a :math:`change` path level. The use of change addresses
|
||||
in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by
|
||||
segregating external and internal address usage. Shielded addresses are never publicly visible in
|
||||
transactions, which means that sending change back to the originating address is indistinguishable from
|
||||
using a change address.
|
||||
|
|
@ -373,6 +449,27 @@ Wallets implementing Sprout ZIP 32 derivation MUST support the following path:
|
|||
|
||||
* :math:`m_\mathsf{Sprout} / purpose' / coin\_type' / account' / address\_index`.
|
||||
|
||||
Orchard key path
|
||||
----------------
|
||||
|
||||
Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such
|
||||
addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable
|
||||
addresses as needed does not increase the cost of scanning the block chain for relevant transactions.
|
||||
|
||||
The above key path levels include an account identifier, which in all user interfaces is represented as a
|
||||
"bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard
|
||||
ZIP 32 derivation MUST support the following path for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
|
||||
|
||||
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`.
|
||||
|
||||
Furthermore, wallets MUST support generating the default payment address (corresponding to the default
|
||||
diversifier for Orchard) for any account they support. They MAY also support generating a stream of
|
||||
diversified payment addresses for a given account, if they wish to enable users to give a unique address to
|
||||
each recipient.
|
||||
|
||||
Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard
|
||||
diversifiers are valid).
|
||||
|
||||
|
||||
Specification: Fingerprints and Tags
|
||||
====================================
|
||||
|
|
@ -380,10 +477,10 @@ Specification: Fingerprints and Tags
|
|||
Sapling Full Viewing Key Fingerprints and Tags
|
||||
----------------------------------------------
|
||||
|
||||
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding :math:`FVK` (as specified
|
||||
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as specified
|
||||
in [#protocol-saplingfullviewingkeyencoding]_) is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, FVK)`.
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})`.
|
||||
|
||||
It MAY be used to uniquely identify a particular Sapling full viewing key.
|
||||
|
||||
|
|
@ -394,10 +491,10 @@ uniquely identify a particular key.
|
|||
Sprout Address Fingerprints and Tags
|
||||
------------------------------------
|
||||
|
||||
A "Sprout address fingerprint" of a Sprout payment address with raw encoding :math:`ADDR` (as specified in
|
||||
A "Sprout address fingerprint" of a Sprout payment address with raw encoding :math:`\mathit{ADDR}` (as specified in
|
||||
[#protocol-sproutpaymentaddrencoding]_, including the lead bytes) is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)`.
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})`.
|
||||
|
||||
It MAY be used to uniquely identify a particular Sprout payment address.
|
||||
|
||||
|
|
@ -405,6 +502,20 @@ A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address
|
|||
intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify
|
||||
a particular address.
|
||||
|
||||
Orchard Full Viewing Key Fingerprints and Tags
|
||||
----------------------------------------------
|
||||
|
||||
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as
|
||||
specified in [#protocol-orchardfullviewingkeyencoding]_) is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})`.
|
||||
|
||||
It MAY be used to uniquely identify a particular Orchard full viewing key.
|
||||
|
||||
An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key
|
||||
fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to
|
||||
uniquely identify a particular key.
|
||||
|
||||
Seed Fingerprints
|
||||
-----------------
|
||||
|
||||
|
|
@ -475,6 +586,24 @@ network, or ``zxtestsprout`` for the test network. Sprout extended spending keys
|
|||
are encoded using Bech32 even though other Sprout keys and addresses are encoded
|
||||
using Base58Check.
|
||||
|
||||
Orchard extended spending keys
|
||||
------------------------------
|
||||
|
||||
An Orchard extended spending key :math:`(\mathsf{sk, c})`, at depth :math:`depth`, with parent full viewing
|
||||
key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is represented as a byte sequence:
|
||||
|
||||
* :math:`\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}`.
|
||||
|
||||
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag` is
|
||||
4 zero bytes, and :math:`i` is :math:`0`.
|
||||
|
||||
When encoded as Bech32, the Human-Readable Part is ``secret-orchard-extsk-main``
|
||||
for Mainnet, or ``secret-orchard-extsk-test`` for Testnet.
|
||||
|
||||
We define this encoding for completeness, however given that it includes the capability to derive child
|
||||
spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to
|
||||
users [#protocol-orchardspendingkeyencoding]_.
|
||||
|
||||
|
||||
Test Vectors
|
||||
============
|
||||
|
|
@ -501,12 +630,16 @@ References
|
|||
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
|
||||
.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
|
||||
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.1.15. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
|
||||
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function <protocol/protocol.pdf#concretediversifyhash>`_
|
||||
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
|
||||
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub <protocol/protocol.pdf#jubjub>`_
|
||||
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.3: Sprout Shielded Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
|
||||
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.7: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
|
||||
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.8: Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.17 or later [Orchard proposal] <protocol/nu5.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.17. Section 3.11: Mainnet and Testnet <protocol/nu5.pdf#networks>`_
|
||||
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.1.17. Section 4.2.2: Sapling Key Components <protocol/nu5.pdf#saplingkeycomponents>`_
|
||||
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.17. Section 5.4.1.6: DiversifyHash Hash Function <protocol/nu5.pdf#concretediversifyhash>`_
|
||||
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.17. Section 5.4.6.1: Spend Authorization Signature <protocol/nu5.pdf#concretespendauthsig>`_
|
||||
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.17. Section 5.4.8.3: Jubjub <protocol/nu5.pdf#jubjub>`_
|
||||
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.17. Section 5.6.2.1: Sprout Shielded Payment Addresses <protocol/nu5.pdf#sproutpaymentaddrencoding>`_
|
||||
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17. Section 5.6.2.3: Sprout Spending Keys <protocol/nu5.pdf#sproutspendingkeyencoding>`_
|
||||
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/nu5.pdf#saplingfullviewingkeyencoding>`_
|
||||
.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17. Section 5.6.3.4: Sapling Spending Keys <protocol/nu5.pdf#saplingspendingkeyencoding>`_
|
||||
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17. Section 5.6.4.3: Orchard Full Viewing Keys <protocol/nu5.pdf#orchardfullviewingkeyencoding>`_
|
||||
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17. Section 5.6.4.4: Orchard Spending Keys <protocol/nu5.pdf#orchardspendingkeyencoding>`_
|
||||
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_
|
||||
|
|
|
|||
444
zip-0224.html
444
zip-0224.html
|
|
@ -3,6 +3,7 @@
|
|||
<head>
|
||||
<title>ZIP 224: Orchard Shielded Protocol</title>
|
||||
<meta charset="utf-8" />
|
||||
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
|
|
@ -13,15 +14,444 @@ Owners: Daira Hopwood <daira@electriccoin.co>
|
|||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Ying Tong Lai <yingtong@electriccoin.co>
|
||||
Status: Reserved
|
||||
Status: Proposed
|
||||
Category: Consensus
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://github.com/zcash/zips/issues/435</a>></pre>
|
||||
<p>This ZIP number is reserved. Preliminary technical content relating to Orchard and Halo 2 are currently in:</p>
|
||||
<ul>
|
||||
<li>the <a href="https://zcash.github.io/orchard/design.html">Orchard Book</a>;</li>
|
||||
<li>the <a href="https://zcash.github.io/halo2/">Halo Book</a>;</li>
|
||||
<li>zcash/zcash GitHub tickets labeled <a href="https://github.com/zcash/zcash/issues?q=label%3AA-Orchard">A-Orchard</a> and <a href="https://github.com/zcash/zcash/issues?q=label%3AA-Halo">A-Halo</a>.</li>
|
||||
</ul>
|
||||
<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>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-networks">6</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>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash currently has two active shielded protocols and associated shielded pools:</p>
|
||||
<ul>
|
||||
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="id3" class="footnote_reference" href="#zerocash-differences">2</a>), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.</li>
|
||||
<li>The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" shielded pool.</li>
|
||||
</ul>
|
||||
<p>Both of these shielded protocols suffer from two issues:</p>
|
||||
<ul>
|
||||
<li>Neither Sprout nor Sapling are compatible with known efficient scalability techniques. Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself along with new state) that are suitable for deployment in a block chain like Zcash require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves and thus is an inherently inefficient protocol to implement inside a circuit, while the Sapling protocol uses curves for which there is no known way to construct an efficient curve cycle (or path to one).</li>
|
||||
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="id4" class="footnote_reference" href="#zcash-paramgen">3</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="id5" class="footnote_reference" href="#bctv14-vuln">4</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
|
||||
</ul>
|
||||
<p>We are thus motivated to deploy a new shielded protocol designed around a curve cycle, using a proving system that is both amenable to recursion and does not require an SRS.</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 MUST be implemented as specified in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-orchard">5</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>
|
||||
<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 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="id7" class="footnote_reference" href="#ietf-hash-to-curve">32</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 proposal only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates.</p>
|
||||
<ul>
|
||||
<li>Curve specifications: <a id="id8" class="footnote_reference" href="#protocol-pallasandvesta">16</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{GroupHash}\)</span>
|
||||
: <a id="id9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">17</a></li>
|
||||
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">33</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>
|
||||
<p>Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), 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>
|
||||
<ul>
|
||||
<li>Halo 2 protocol description: TODO</li>
|
||||
<li>UltraPLONK Arithmetization: <a id="id11" class="footnote_reference" href="#concepts-upa">22</a></li>
|
||||
<li>Halo 2 explanation and design rationale: <a id="id12" class="footnote_reference" href="#design-halo2">23</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="id13" class="footnote_reference" href="#protocol-actions">9</a></li>
|
||||
<li>Circuit statement: <a id="id14" class="footnote_reference" href="#protocol-actionstatement">10</a></li>
|
||||
<li>Design rationale: <a id="id15" class="footnote_reference" href="#design-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" 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="id16" class="footnote_reference" href="#protocol-concretesinsemillahash">12</a></li>
|
||||
<li>Sinsemilla commitments: <a id="id17" class="footnote_reference" href="#protocol-concretesinsemillacommit">15</a></li>
|
||||
<li>Design rationale: <a id="id18" class="footnote_reference" href="#design-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" 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="id19" class="footnote_reference" href="#design-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" 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
|
||||
<span class="math">\(\mathsf{nk}\)</span>
|
||||
is now a field element.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
is computed as a Sinsemilla commitment instead of a BLAKE2s output.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
is derived from
|
||||
<span class="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>
|
||||
<ul>
|
||||
<li>Key components diagram: <a id="id20" class="footnote_reference" href="#protocol-addressesandkeys">7</a></li>
|
||||
<li>Key components specification: <a id="id21" class="footnote_reference" href="#protocol-orchardkeycomponents">11</a></li>
|
||||
<li>Encodings and HRPs: <a id="id22" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">18</a> <a id="id23" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">19</a> <a id="id24" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a> <a id="id25" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a></li>
|
||||
<li>HD key derivation specification: <a id="id26" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="id27" class="footnote_reference" href="#design-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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard notes have the structure
|
||||
<span class="math">\((addr, v, \rho, \psi, \mathsf{rcm}).\)</span>
|
||||
<span class="math">\(\rho\)</span>
|
||||
is set to the nullifier of the spent note in the same action, which ensures it is unique.
|
||||
<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="id28" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
<ul>
|
||||
<li>Orchard notes: <a id="id29" class="footnote_reference" href="#protocol-notes">8</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>
|
||||
<p>Nullifiers for Orchard notes are computed as:</p>
|
||||
<p>
|
||||
<span class="math">\(\mathsf{nf} = [F_{\mathsf{nk}}(\rho) + \psi \pmod{p}] \mathcal{G} + \mathsf{cm}\)</span>
|
||||
</p>
|
||||
<p>where
|
||||
<span class="math">\(F\)</span>
|
||||
is instantiated with Poseidon, and
|
||||
<span class="math">\(\mathcal{G}\)</span>
|
||||
is a fixed independent base.</p>
|
||||
<ul>
|
||||
<li>Poseidon: <a id="id30" class="footnote_reference" href="#protocol-poseidonhash">13</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id31" class="footnote_reference" href="#design-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" 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="id32" class="footnote_reference" href="#protocol-concretereddsa">14</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="additional-rationale"><h2><span class="section-heading">Additional Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#additional-rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary motivator for proposing a new shielded protocol and pool is the need to migrate spend authority to a recursion-friendly curve. Spend authority in the Sapling shielded pool is rooted in the Jubjub curve, but there is no known way to construct an efficient curve cycle (or path to one) from either Jubjub or BLS12-381.</p>
|
||||
<p>Despite having recursion-friendliness as a design goal, we do not propose a recursive protocol in this ZIP. Deploying an entire scaling solution in a single upgrade would be a risky endeavour with a lot of moving parts. By focusing just on the components that enable a recursive protocol (namely the curve cycle and the proving system), we can start the migration of value to a scalable protocol before actually deploying the scalable protocol itself.</p>
|
||||
<p>The remainder of the changes we make relative to Sapling are motivated by simplifying the Sapling protocol (and fixing deficiencies), and using protocol primitives that are more efficient in the UltraPLONK arithmetization.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="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 the
|
||||
<span class="math">\(\mathsf{valueBalanceOrchard}\)</span>
|
||||
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>
|
||||
<li>The "transparent turnstile" created by the
|
||||
<span class="math">\(\mathsf{valueBalanceOrchard}\)</span>
|
||||
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="id33" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash-hackworks/zcash-test-vectors/pull/14">https://github.com/zcash-hackworks/zcash-test-vectors/pull/14</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash/halo2">https://github.com/zcash/halo2</a></li>
|
||||
<li><a href="https://github.com/zcash/orchard">https://github.com/zcash/orchard</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<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="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="zerocash-differences" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#differences">Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zcash-paramgen" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="https://z.cash/technology/paramgen/">Parameter Generation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bctv14-vuln" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/">Zcash Counterfeiting Vulnerability Successfully Remediated</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchard" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-addressesandkeys" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/nu5.pdf#addressesandkeys">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.1: Payment Addresses and Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-notes" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/nu5.pdf#notes">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.2: Notes</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-actions" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/nu5.pdf#actions">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-actionstatement" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/nu5.pdf#actionstatement">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.17.4: Action Statement (Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardkeycomponents" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.2.3: Orchard Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretesinsemillahash" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/nu5.pdf#concretesinsemillahash">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-poseidonhash" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="protocol/nu5.pdf#poseidonhash">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.10: PoseidonHash Function</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretereddsa" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<td><a href="protocol/nu5.pdf#concretereddsa">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretesinsemillacommit" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<td><a href="protocol/nu5.pdf#concretesinsemillacommit">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-pallasandvesta" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<td><a href="protocol/nu5.pdf#pallasandvesta">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretegrouphashpallasandvesta" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<td><a href="protocol/nu5.pdf#concretegrouphashpallasandvesta">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.1: Orchard Payment Address</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardinviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>20</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.3: Orchard Full Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardspendingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>21</th>
|
||||
<td><a href="protocol/nu5.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.4: Orchard Spending Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="concepts-upa" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>22</th>
|
||||
<td><a href="https://zcash.github.io/halo2/concepts/arithmetization.html">The halo2 Book: 1.2 UltraPLONK Arithmetization</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="design-halo2" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>23</th>
|
||||
<td><a href="https://zcash.github.io/halo2/design/proving-system.html">The halo2 Book: 3.1. Proving system</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="design-keys" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>24</th>
|
||||
<td><a href="https://zcash.github.io/orchard/design/keys.html">The Orchard Book: 3.1. Keys and addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="design-actions" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>25</th>
|
||||
<td><a href="https://zcash.github.io/orchard/design/actions.html">The Orchard Book: 3.2. Actions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="design-commitments" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>26</th>
|
||||
<td><a href="https://zcash.github.io/orchard/design/commitments.html">The Orchard Book: 3.3. Commitments</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="design-tree" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>27</th>
|
||||
<td><a href="https://zcash.github.io/orchard/design/commitment-tree.html">The Orchard Book: 3.4. Commitment tree</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="design-nullifiers" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>28</th>
|
||||
<td><a href="https://zcash.github.io/orchard/design/nullifiers.html">The Orchard Book: 3.5. Nullifiers</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>29</th>
|
||||
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0212" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>30</th>
|
||||
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0315" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>31</th>
|
||||
<td><a href="zip-0315">ZIP 315: Best Practices for Wallet Handling of Multiple Pools</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="ietf-hash-to-curve" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>32</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>
|
||||
</table>
|
||||
<table id="pasta-evidence" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>33</th>
|
||||
<td><a href="https://github.com/zcash/pasta">Pallas/Vesta supporting evidence</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
||||
305
zip-0224.rst
305
zip-0224.rst
|
|
@ -7,14 +7,305 @@
|
|||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Ying Tong Lai <yingtong@electriccoin.co>
|
||||
Status: Reserved
|
||||
Status: Proposed
|
||||
Category: Consensus
|
||||
Discussions-To: <https://github.com/zcash/zips/issues/435>
|
||||
|
||||
This ZIP number is reserved. Preliminary technical content relating to Orchard and Halo 2
|
||||
are currently in:
|
||||
|
||||
* the `Orchard Book <https://zcash.github.io/orchard/design.html>`_;
|
||||
* the `Halo Book <https://zcash.github.io/halo2/>`_;
|
||||
* zcash/zcash GitHub tickets labeled `A-Orchard <https://github.com/zcash/zcash/issues?q=label%3AA-Orchard>`_
|
||||
and `A-Halo <https://github.com/zcash/zcash/issues?q=label%3AA-Halo>`_.
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key word "MUST" in this document is to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash
|
||||
Protocol Specification [#protocol-networks]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Zcash currently has two active shielded protocols and associated shielded pools:
|
||||
|
||||
- The Sprout shielded protocol (based on the Zerocash paper with improvements and security
|
||||
fixes [#zerocash-differences]_), which as of February 2021 is a "closing" shielded pool
|
||||
into which no new ZEC can be sent.
|
||||
- The Sapling shielded protocol, which consisted of numerous improvements to functionality
|
||||
and improved performance by orders of magnitude, and as of Feburary 2021 is the "active"
|
||||
shielded pool.
|
||||
|
||||
Both of these shielded protocols suffer from two issues:
|
||||
|
||||
- Neither Sprout nor Sapling are compatible with known efficient scalability techniques.
|
||||
Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself
|
||||
along with new state) that are suitable for deployment in a block chain like Zcash
|
||||
require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves
|
||||
and thus is an inherently inefficient protocol to implement inside a circuit, while the
|
||||
Sapling protocol uses curves for which there is no known way to construct an efficient
|
||||
curve cycle (or path to one).
|
||||
|
||||
- The Sprout and Sapling circuits are implemented using a proving system (Groth16) that
|
||||
requires a "trusted setup": the circuit parameters are a Structured Reference String
|
||||
(SRS) with hidden structure, that if known could be used to create fake proofs and
|
||||
thus counterfeit funds. The parameters are in practice generated using a multiparty
|
||||
computation (MPC), where as long as at least one participant was honest and not
|
||||
compromised, the hidden structure is unrecoverable. The MPCs themselves have improved
|
||||
over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in
|
||||
the Sapling MPC two years later [#zcash-paramgen]_), but it remains the case that
|
||||
generating these parameters is a point of risk within the protocol. For example, the
|
||||
original proving system used for the Sprout circuit (BCTV14) had a bug that made the
|
||||
Sprout shielded protocol vulnerable to counterfeiting, [#bctv14-vuln]_ which needed to
|
||||
be resolved by changing the proving system and running a new MPC.
|
||||
|
||||
We are thus motivated to deploy a new shielded protocol designed around a curve cycle,
|
||||
using a proving system that is both amenable to recursion and does not require an SRS.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification
|
||||
[#protocol-orchard]_.
|
||||
|
||||
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
|
||||
------
|
||||
|
||||
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 :math:`\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 [#ietf-hash-to-curve]_ (but the
|
||||
protocol specification takes precedence in the case of any discrepancy).
|
||||
|
||||
The presence of the curve cycle is an explicit design choice. This proposal only uses half
|
||||
of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be
|
||||
leveraged by future protocol updates.
|
||||
|
||||
- Curve specifications: [#protocol-pallasandvesta]_
|
||||
- :math:`\mathsf{GroupHash}`: [#protocol-concretegrouphashpallasandvesta]_
|
||||
- Supporting evidence: [#pasta-evidence]_
|
||||
|
||||
Proving system
|
||||
--------------
|
||||
|
||||
Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), 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.
|
||||
|
||||
- Halo 2 protocol description: TODO
|
||||
- UltraPLONK Arithmetization: [#concepts-upa]_
|
||||
- Halo 2 explanation and design rationale: [#design-halo2]_
|
||||
|
||||
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: [#protocol-actions]_
|
||||
- Circuit statement: [#protocol-actionstatement]_
|
||||
- Design rationale: [#design-actions]_
|
||||
|
||||
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: [#protocol-concretesinsemillahash]_
|
||||
- Sinsemilla commitments: [#protocol-concretesinsemillacommit]_
|
||||
- Design rationale: [#design-commitments]_
|
||||
|
||||
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: [#design-tree]_
|
||||
|
||||
Keys and addresses
|
||||
------------------
|
||||
|
||||
Orchard keys and payment addresses are structurally similar to Sapling, with the following
|
||||
changes:
|
||||
|
||||
- The proof authorizing key is removed, and :math:`\mathsf{nk}` is now a field element.
|
||||
- :math:`\mathsf{ivk}` is computed as a Sinsemilla commitment instead of a BLAKE2s output.
|
||||
- :math:`\mathsf{ovk}` is derived from :math:`\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: [#protocol-addressesandkeys]_
|
||||
- Key components specification: [#protocol-orchardkeycomponents]_
|
||||
- Encodings and HRPs: [#protocol-orchardpaymentaddrencoding]_ [#protocol-orchardinviewingkeyencoding]_ [#protocol-orchardfullviewingkeyencoding]_
|
||||
[#protocol-orchardspendingkeyencoding]_
|
||||
- HD key derivation specification: [#zip-0032]_
|
||||
- Design rationale: [#design-keys]_
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
Orchard notes have the structure :math:`(addr, v, \rho, \psi, \mathsf{rcm}).` :math:`\rho`
|
||||
is set to the nullifier of the spent note in the same action, which ensures it is unique.
|
||||
:math:`\psi` and :math:`\mathsf{rcm}` are derived from a random seed (as with Sapling
|
||||
after ZIP 212 [#zip-0212]_).
|
||||
|
||||
- Orchard notes: [#protocol-notes]_
|
||||
|
||||
Nullifiers
|
||||
----------
|
||||
|
||||
Nullifiers for Orchard notes are computed as:
|
||||
|
||||
:math:`\mathsf{nf} = [F_{\mathsf{nk}}(\rho) + \psi \pmod{p}] \mathcal{G} + \mathsf{cm}`
|
||||
|
||||
where :math:`F` is instantiated with Poseidon, and :math:`\mathcal{G}` is a fixed
|
||||
independent base.
|
||||
|
||||
- Poseidon: [#protocol-poseidonhash]_
|
||||
- Design rationale and considered alternatives: [#design-nullifiers]_
|
||||
|
||||
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: [#protocol-concretereddsa]_
|
||||
|
||||
|
||||
Additional Rationale
|
||||
====================
|
||||
|
||||
The primary motivator for proposing a new shielded protocol and pool is the need to
|
||||
migrate spend authority to a recursion-friendly curve. Spend authority in the Sapling
|
||||
shielded pool is rooted in the Jubjub curve, but there is no known way to construct an
|
||||
efficient curve cycle (or path to one) from either Jubjub or BLS12-381.
|
||||
|
||||
Despite having recursion-friendliness as a design goal, we do not propose a recursive
|
||||
protocol in this ZIP. Deploying an entire scaling solution in a single upgrade would be a
|
||||
risky endeavour with a lot of moving parts. By focusing just on the components that enable
|
||||
a recursive protocol (namely the curve cycle and the proving system), we can start the
|
||||
migration of value to a scalable protocol before actually deploying the scalable protocol
|
||||
itself.
|
||||
|
||||
The remainder of the changes we make relative to Sapling are motivated by simplifying the
|
||||
Sapling protocol (and fixing deficiencies), and using protocol primitives that are more
|
||||
efficient in the UltraPLONK arithmetization.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
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 the
|
||||
:math:`\mathsf{valueBalanceOrchard}` transaction field. This has the following
|
||||
considerations:
|
||||
|
||||
- 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.
|
||||
- The "transparent turnstile" created by the :math:`\mathsf{valueBalanceOrchard}` 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.
|
||||
- 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.
|
||||
|
||||
- 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. [#zip-0315]_
|
||||
|
||||
|
||||
Test Vectors
|
||||
============
|
||||
|
||||
- https://github.com/zcash-hackworks/zcash-test-vectors/pull/14
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
- https://github.com/zcash/halo2
|
||||
- https://github.com/zcash/orchard
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
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>`_
|
||||
.. [#zerocash-differences] `Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper <https://zips.z.cash/protocol/protocol.pdf#differences>`_
|
||||
.. [#zcash-paramgen] `Parameter Generation <https://z.cash/technology/paramgen/>`_
|
||||
.. [#bctv14-vuln] `Zcash Counterfeiting Vulnerability Successfully Remediated <https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/>`_
|
||||
.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal] <protocol/nu5.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 3.11: Mainnet and Testnet <protocol/nu5.pdf#networks>`_
|
||||
.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.1: Payment Addresses and Keys <protocol/nu5.pdf#addressesandkeys>`_
|
||||
.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.2: Notes <protocol/nu5.pdf#notes>`_
|
||||
.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions <protocol/nu5.pdf#actions>`_
|
||||
.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.17.4: Action Statement (Orchard) <protocol/nu5.pdf#actionstatement>`_
|
||||
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.2.3: Orchard Key Components <protocol/nu5.pdf#orchardkeycomponents>`_
|
||||
.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function <protocol/nu5.pdf#concretesinsemillahash>`_
|
||||
.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.10: PoseidonHash Function <protocol/nu5.pdf#poseidonhash>`_
|
||||
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas <protocol/nu5.pdf#concretereddsa>`_
|
||||
.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments <protocol/nu5.pdf#concretesinsemillacommit>`_
|
||||
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta <protocol/nu5.pdf#pallasandvesta>`_
|
||||
.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta <protocol/nu5.pdf#concretegrouphashpallasandvesta>`_
|
||||
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.1: Orchard Payment Address <protocol/nu5.pdf#orchardpaymentaddrencoding>`_
|
||||
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys <protocol/nu5.pdf#orchardinviewingkeyencoding>`_
|
||||
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.3: Orchard Full Viewing Keys <protocol/nu5.pdf#orchardfullviewingkeyencoding>`_
|
||||
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.4: Orchard Spending Keys <protocol/nu5.pdf#orchardspendingkeyencoding>`_
|
||||
.. [#concepts-upa] `The halo2 Book: 1.2 UltraPLONK Arithmetization <https://zcash.github.io/halo2/concepts/arithmetization.html>`_
|
||||
.. [#design-halo2] `The halo2 Book: 3.1. Proving system <https://zcash.github.io/halo2/design/proving-system.html>`_
|
||||
.. [#design-keys] `The Orchard Book: 3.1. Keys and addresses <https://zcash.github.io/orchard/design/keys.html>`_
|
||||
.. [#design-actions] `The Orchard Book: 3.2. Actions <https://zcash.github.io/orchard/design/actions.html>`_
|
||||
.. [#design-commitments] `The Orchard Book: 3.3. Commitments <https://zcash.github.io/orchard/design/commitments.html>`_
|
||||
.. [#design-tree] `The Orchard Book: 3.4. Commitment tree <https://zcash.github.io/orchard/design/commitment-tree.html>`_
|
||||
.. [#design-nullifiers] `The Orchard Book: 3.5. Nullifiers <https://zcash.github.io/orchard/design/nullifiers.html>`_
|
||||
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
|
||||
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
|
||||
.. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools <zip-0315.rst>`_
|
||||
.. [#ietf-hash-to-curve] `draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves <https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html>`_
|
||||
.. [#pasta-evidence] `Pallas/Vesta supporting evidence <https://github.com/zcash/pasta>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue