mirror of https://github.com/zcash/zips.git
ZIPs 207, 214, 215 and 251: some suggested changes from NCC audit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
bbb2bac1ac
commit
a83a64fefc
|
|
@ -17,33 +17,33 @@ Created: 2019-01-04
|
|||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD 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>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">5</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">8</a></p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">4</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">10</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Canopy</dt>
|
||||
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol">2</a></dd>
|
||||
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">3</a></dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol">2</a></dd>
|
||||
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">3</a></dd>
|
||||
</dl>
|
||||
</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 specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">12</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">14</a>, which describes the high-level requirements for that fund.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">14</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">16</a>, which describes the high-level requirements for that fund.</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>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">14</a>.</p>
|
||||
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">16</a>.</p>
|
||||
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">12</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">14</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">14</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">16</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</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>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">4</a>, <a id="id13" class="footnote_reference" href="#protocol-subsidies">5</a>, and <a id="id14" class="footnote_reference" href="#protocol-foundersreward">6</a>:</p>
|
||||
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, <a id="id13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="id14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="id15" class="footnote_reference" href="#protocol-foundersreward">8</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BlossomActivationHeight}\)</span>
|
||||
|
|
@ -74,7 +74,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a rel="bookmark" href="#funding-streams"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).</p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id15" class="footnote_reference" href="#zip-0208">9</a></p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id16" class="footnote_reference" href="#zip-0208">11</a></p>
|
||||
<p>The value of a funding stream at a given block height is defined as:</p>
|
||||
<div class="math">\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
|
||||
\mathsf{floor}\left(
|
||||
|
|
@ -196,17 +196,17 @@ License: MIT</pre>
|
|||
<p>On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.</p>
|
||||
</section>
|
||||
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id16" class="footnote_reference" href="#protocol-foundersreward">6</a></p>
|
||||
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
|
||||
<p>Once the Canopy network upgrade activates:</p>
|
||||
<ul>
|
||||
<li>The existing consensus rule for payment of the Founders' Reward <a id="id17" class="footnote_reference" href="#protocol-foundersreward">6</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The existing consensus rule for payment of the Founders' Reward <a id="id18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
|
||||
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id18" class="footnote_reference" href="#zip-0213">11</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
|
||||
<span class="math">\(\mathbf{0x02}\)</span>
|
||||
, as specified in <a id="id19" class="footnote_reference" href="#zip-0212">10</a>.</li>
|
||||
, as specified in <a id="id20" class="footnote_reference" href="#zip-0212">12</a>.</li>
|
||||
</ul>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id20" class="footnote_reference" href="#zip-0214">12</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id21" class="footnote_reference" href="#zip-0000">7</a></p>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id21" class="footnote_reference" href="#zip-0214">14</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id22" class="footnote_reference" href="#zip-0000">9</a></p>
|
||||
</section>
|
||||
<section id="example-implementation"><h3><span class="section-heading">Example implementation</span><span class="section-anchor"> <a rel="bookmark" href="#example-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<pre data-language="cpp"><span class="k">struct</span> <span class="n">FundingPeriod</span> <span class="p">{</span>
|
||||
|
|
@ -371,7 +371,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</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 proposal is intended to be deployed with Canopy. <a id="id22" class="footnote_reference" href="#zip-0251">13</a></p>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id23" class="footnote_reference" href="#zip-0251">15</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
|
|
@ -392,46 +392,62 @@ License: MIT</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.9 or later [Canopy]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-subsidyconcepts" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#subsidyconcepts">Section 3.9: Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/canopy.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-constants" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#constants">Section 5.3: Constants. Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/canopy.pdf#constants">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.3: Constants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-diffadjustment" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/canopy.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.6.3: Difficulty adjustment</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-subsidies" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#subsidies">Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/canopy.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-foundersreward" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#foundersreward">Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/canopy.pdf#foundersreward">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.8: Payment of Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0000" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -439,7 +455,7 @@ License: MIT</pre>
|
|||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -447,7 +463,7 @@ License: MIT</pre>
|
|||
<table id="zip-0208" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -455,7 +471,7 @@ License: MIT</pre>
|
|||
<table id="zip-0212" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<th>12</th>
|
||||
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -463,7 +479,7 @@ License: MIT</pre>
|
|||
<table id="zip-0213" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>13</th>
|
||||
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -471,7 +487,7 @@ License: MIT</pre>
|
|||
<table id="zip-0214" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<th>14</th>
|
||||
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -479,7 +495,7 @@ License: MIT</pre>
|
|||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<th>15</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -487,7 +503,7 @@ License: MIT</pre>
|
|||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<th>16</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
18
zip-0207.rst
18
zip-0207.rst
|
|
@ -28,9 +28,9 @@ The terms below are to be interpreted as follows:
|
|||
Canopy
|
||||
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
||||
Testnet
|
||||
The Zcash test network, as defined in the Zcash Protocol Specification. [#protocol]_
|
||||
The Zcash test network, as defined in the Zcash Protocol Specification. [#protocol-networks]_
|
||||
Mainnet
|
||||
The Zcash production network, as defined in the Zcash Protocol Specification. [#protocol]_
|
||||
The Zcash production network, as defined in the Zcash Protocol Specification. [#protocol-networks]_
|
||||
|
||||
|
||||
Abstract
|
||||
|
|
@ -81,7 +81,7 @@ Definitions
|
|||
-----------
|
||||
|
||||
We use the following constants and functions defined in [#protocol-constants]_,
|
||||
[#protocol-subsidies]_, and [#protocol-foundersreward]_:
|
||||
[#protocol-diffadjustment]_, [#protocol-subsidies]_, and [#protocol-foundersreward]_:
|
||||
|
||||
- :math:`\mathsf{BlossomActivationHeight}`
|
||||
- :math:`\mathsf{PostBlossomHalvingInterval}`
|
||||
|
|
@ -398,11 +398,13 @@ References
|
|||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-subsidyconcepts] `Section 3.9: Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf#subsidyconcepts>`_
|
||||
.. [#protocol-constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf#constants>`_
|
||||
.. [#protocol-subsidies] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf#subsidies>`_
|
||||
.. [#protocol-foundersreward] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf#foundersreward>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.9 or later [Canopy] <protocol/canopy.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
|
||||
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidyconcepts>`_
|
||||
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.3: Constants <protocol/canopy.pdf#constants>`_
|
||||
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.6.3: Difficulty adjustment <protocol/canopy.pdf#diffadjustment>`_
|
||||
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidies>`_
|
||||
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.8: Payment of Founders' Reward <protocol/canopy.pdf#foundersreward>`_
|
||||
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
||||
|
|
|
|||
|
|
@ -16,20 +16,13 @@ License: MIT
|
|||
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHALL", "SHOULD", 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>The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="id2" class="footnote_reference" href="#trademark">5</a> or successor agreement).</p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">7</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">5</a> or successor agreement).</p>
|
||||
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.9 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-blocksubsidy">3</a>.</p>
|
||||
<p>The term "halving" in this document are to be interpreted as described in sections 7.7 of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-calculation">4</a>.</p>
|
||||
<p>The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="id7" class="footnote_reference" href="#zip-1014">11</a>.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Canopy</dt>
|
||||
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in <a id="id8" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id9" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
<p>The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="id2" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">8</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
|
||||
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.9 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-subsidyconcepts">4</a>.</p>
|
||||
<p>The term "halving" in this document are to be interpreted as described in sections 7.7 of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
|
||||
<p>The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="id7" class="footnote_reference" href="#zip-1014">12</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="id8" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</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 ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.</p>
|
||||
|
|
@ -38,7 +31,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.</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>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="id10" class="footnote_reference" href="#zip-1014">11</a>, which gives a high-level description of the intended structure of the fund.</p>
|
||||
<p>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">12</a>, which gives a high-level description of the intended structure of the fund.</p>
|
||||
<p>An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -49,9 +42,9 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<p>This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.</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 Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="id11" class="footnote_reference" href="#zip-0208">9</a>, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.</p>
|
||||
<p>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="id10" class="footnote_reference" href="#zip-0208">10</a>, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.</p>
|
||||
<p>Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.</p>
|
||||
<p>ZIP 207 <a id="id12" class="footnote_reference" href="#zip-0207">8</a> SHALL be activated in Canopy.</p>
|
||||
<p>ZIP 207 <a id="id11" class="footnote_reference" href="#zip-0207">9</a> SHALL be activated in Canopy.</p>
|
||||
<p>The following funding streams are defined for Mainnet:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
|
|
@ -89,7 +82,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>As specified in <a id="id13" class="footnote_reference" href="#zip-0207">8</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
|
||||
<p>As specified in <a id="id12" class="footnote_reference" href="#zip-0207">9</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
|
||||
<p>The funding streams defined for Testnet are identical except that the start height of each stream is the activation height of Canopy on Testnet, i.e. TODO.</p>
|
||||
<p>Note: on Testnet, the activation height of Canopy will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).</p>
|
||||
<section id="dev-fund-recipient-addresses"><h3><span class="section-heading">Dev Fund Recipient Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#dev-fund-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -99,10 +92,10 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<li>ZF SHALL generate the addresses for the <code>FS_ZF</code> and <code>FS_MG</code> funding streams, which on Mainnet correspond to the <strong>ZF slice</strong> and <strong>MG slice</strong> respectively.</li>
|
||||
</ul>
|
||||
<p>Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.</p>
|
||||
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id14" class="footnote_reference" href="#zip-1014">11</a>.</p>
|
||||
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id13" class="footnote_reference" href="#zip-1014">12</a>.</p>
|
||||
<p>No requirements are imposed on the use of funds sent to Testnet funding streams.</p>
|
||||
<section id="direct-grant-option"><h4><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a rel="bookmark" href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="id15" class="footnote_reference" href="#zip-1014">11</a></p>
|
||||
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="id14" class="footnote_reference" href="#zip-1014">12</a></p>
|
||||
<p>The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total value of funding streams assigned to direct grantees MUST be subtracted from the value of the funding stream for the remaining <strong>MG slice</strong> (or, if all Major Grants are direct, replace the funding stream for the <strong>MG slice</strong>).</p>
|
||||
<p>For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP SHOULD be published specifying those modifications.</p>
|
||||
</section>
|
||||
|
|
@ -124,13 +117,13 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The rationale for ZF generating the addresses for the <code>ZF_MG</code> funding stream is that ZF is the financial recipient of the <strong>MG slice</strong> as specified in ZIP 1014. <a id="id16" class="footnote_reference" href="#zip-1014">11</a></p>
|
||||
<p>The rationale for ZF generating the addresses for the <code>ZF_MG</code> funding stream is that ZF is the financial recipient of the <strong>MG slice</strong> as specified in ZIP 1014. <a id="id15" class="footnote_reference" href="#zip-1014">12</a></p>
|
||||
<p>Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.</p>
|
||||
<p>Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks at the time of writing, which is the equivalent of ~67 days at the post-Blossom block target spacing), the activation height and the start heights of the funding streams could have also been set to 1046400 on Testnet. However, 67 days is arguably too short a testing period, and the block rate on Testnet is less predictable than on Mainnet.</p>
|
||||
<p>It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.</p>
|
||||
</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 proposal is intended to be deployed with Canopy. <a id="id17" class="footnote_reference" href="#zip-0251">10</a></p>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id16" class="footnote_reference" href="#zip-0251">11</a></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">
|
||||
|
|
@ -145,30 +138,38 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.9 or later [Canopy]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-blocksubsidy" class="footnote">
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.4. Section 3.9: Block Subsidy and Founders' Reward</a></td>
|
||||
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-calculation" class="footnote">
|
||||
<table id="protocol-subsidyconcepts" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.4. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
|
||||
<td><a href="protocol/canopy.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-subsidies" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/canopy.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="trademark" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<th>6</th>
|
||||
<td><a href="https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf">Zcash Trademark Donation and License Agreement</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -176,7 +177,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<table id="osd" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<th>7</th>
|
||||
<td><a href="https://opensource.org/osd">The Open Source Definition</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -184,7 +185,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<th>8</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -192,7 +193,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<table id="zip-0207" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0207">ZIP 207: Funding Streams</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -200,7 +201,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<table id="zip-0208" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -208,7 +209,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -216,7 +217,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli
|
|||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>12</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
22
zip-0214.rst
22
zip-0214.rst
|
|
@ -25,23 +25,20 @@ described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
|
|||
Agreement ([#trademark]_ or successor agreement).
|
||||
|
||||
The term "block subsidy" in this document is to be interpreted as described in
|
||||
section 3.9 of the Zcash Protocol Specification [#protocol-blocksubsidy]_.
|
||||
section 3.9 of the Zcash Protocol Specification [#protocol-subsidyconcepts]_.
|
||||
|
||||
The term "halving" in this document are to be interpreted as described in
|
||||
sections 7.7 of the Zcash Protocol Specification [#protocol-calculation]_.
|
||||
sections 7.7 of the Zcash Protocol Specification [#protocol-subsidies]_.
|
||||
|
||||
The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"),
|
||||
"Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to
|
||||
be interpreted as described in ZIP 1014 [#zip-1014]_.
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
Canopy
|
||||
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
||||
Testnet
|
||||
The Zcash test network, as defined in [#protocol]_.
|
||||
Mainnet
|
||||
The Zcash production network, as defined in [#protocol]_.
|
||||
"Canopy" is the code-name for the fifth Zcash network upgrade, also known as
|
||||
Network Upgrade 4.
|
||||
|
||||
|
||||
Abstract
|
||||
|
|
@ -360,9 +357,10 @@ References
|
|||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-blocksubsidy] `Zcash Protocol Specification, Version 2020.1.4. Section 3.9: Block Subsidy and Founders' Reward <protocol/protocol.pdf>`_
|
||||
.. [#protocol-calculation] `Zcash Protocol Specification, Version 2020.1.4. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/protocol.pdf>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.9 or later [Canopy] <protocol/canopy.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
|
||||
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.9: Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidyconcepts>`_
|
||||
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidies>`_
|
||||
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
|
||||
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
|
|
|
|||
|
|
@ -21,13 +21,13 @@ License: BSD-2-Clause</pre>
|
|||
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature validity from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 validity criteria and changing them to be compatible with batch validation.</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>The lack of clear validity criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validity criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validity criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validity criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>The lack of clear validity criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validity criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-2020-1-1">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validity criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validity criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>In addition, the validity criteria used by Zcash preclude the use of batch validation of Ed25519 signatures. While signature validation is not the primary bottleneck for Zcash, it would be nice to be able to batch-validate signatures, as is the case for RedJubjub.</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>After activation of this ZIP, the
|
||||
<span class="math">\(\mathsf{JoinSplitSig}\)</span>
|
||||
validation rules in §5.4.5 of the protocol specification <a id="id4" class="footnote_reference" href="#protocol">3</a> are changed to the following:</p>
|
||||
validation rules in <a id="id4" class="footnote_reference" href="#protocol-concreteed25519">5</a> are changed to the following:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\underline{A}\)</span>
|
||||
|
|
@ -77,7 +77,7 @@ License: BSD-2-Clause</pre>
|
|||
<p>This change has no effect on honestly-generated signatures. Unlike the current validation rules, it makes it possible for a user to generate weak signing keys or to generate signing keys with nonzero torsion component and submit them to the blockchain. However, doing so provides them with no advantage, only compromise to their own security. Moreover, these cases are not a failure mode of any deployed implementation.</p>
|
||||
</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 is intended to be deployed with the Canopy Network Upgrade, which is scheduled to activate on Mainnet at block height 1046400.</p>
|
||||
<p>This is intended to be deployed with the Canopy Network Upgrade <a id="id6" class="footnote_reference" href="#zip-0251">6</a>, which is scheduled to activate on Mainnet <a id="id7" class="footnote_reference" href="#protocol-networks">4</a> at block height 1046400.</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">
|
||||
|
|
@ -96,11 +96,35 @@ License: BSD-2-Clause</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol" class="footnote">
|
||||
<table id="protocol-2020-1-1" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.5 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
|
||||
<td><a href="https://github.com/zcash/zips/blob/v2020.1.1/protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concreteed25519" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/canopy.pdf#concreteed25519">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.4.5: Ed25519</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
21
zip-0215.rst
21
zip-0215.rst
|
|
@ -15,6 +15,7 @@ Terminology
|
|||
The key words "MUST" and "MUST NOT" in this document is to be interpreted as described
|
||||
in RFC 2119. [#RFC2119]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
|
|
@ -27,6 +28,7 @@ inherits criteria for signature validity from an obsolete version of
|
|||
Ed25519 validity criteria and changing them to be compatible with batch
|
||||
validation.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
|
|
@ -35,7 +37,7 @@ maintenance burden. The initial implementation of Zcash consensus in `zcashd`
|
|||
inherited validity criteria from a then-current version of `libsodium` (1.0.15).
|
||||
Due to `a bug in libsodium <https://github.com/zcash/zcash/issues/2872#issuecomment-576911471>`_,
|
||||
this was different from the intended criteria documented in the Zcash protocol
|
||||
specification [#protocol]_ (before the specification was changed to match
|
||||
specification [#protocol-2020.1.1]_ (before the specification was changed to match
|
||||
`libsodium` 1.0.15 in specification version 2020.1.2). Also, `libsodium` never
|
||||
guaranteed stable validity criteria, and changed behavior in a later point
|
||||
release. This forced `zcashd` to use an older version of the library before
|
||||
|
|
@ -50,11 +52,12 @@ validation of Ed25519 signatures. While signature validation is not the
|
|||
primary bottleneck for Zcash, it would be nice to be able to batch-validate
|
||||
signatures, as is the case for RedJubjub.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
After activation of this ZIP, the :math:`\mathsf{JoinSplitSig}` validation rules
|
||||
in §5.4.5 of the protocol specification [#protocol]_ are changed to the following:
|
||||
in [#protocol-concreteed25519]_ are changed to the following:
|
||||
|
||||
- :math:`\underline{A}` and :math:`\underline{R}` MUST be encodings of points
|
||||
:math:`A` and :math:`R` respectively on the complete twisted Edwards curve Ed25519;
|
||||
|
|
@ -73,6 +76,7 @@ are canonical encodings; in other words, the integer encoding the
|
|||
Note: the alternate validation equation :math:`[S]B = R + [k]A`, allowed
|
||||
by RFC 8032, MUST NOT be used.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
|
|
@ -84,6 +88,7 @@ existing Ed25519 signatures on the chain.
|
|||
It also allows the use of batch validation, which requires multiplication
|
||||
by the cofactor in the validation equation.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
|
|
@ -94,15 +99,21 @@ the blockchain. However, doing so provides them with no advantage, only
|
|||
compromise to their own security. Moreover, these cases are not a failure mode
|
||||
of any deployed implementation.
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This is intended to be deployed with the Canopy Network Upgrade, which is
|
||||
scheduled to activate on Mainnet at block height 1046400.
|
||||
This is intended to be deployed with the Canopy Network Upgrade [#zip-0251]_,
|
||||
which is scheduled to activate on Mainnet [#protocol-networks]_ at block height
|
||||
1046400.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#RFC8032] `Edwards-Curve Digital Signature Algorithm (EdDSA) <https://www.rfc-editor.org/rfc/rfc8032.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.5 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf>`_
|
||||
.. [#protocol-2020.1.1] `Zcash Protocol Specification, Version 2020.1.1 <https://github.com/zcash/zips/blob/v2020.1.1/protocol/protocol.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
|
||||
.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.4.5: Ed25519 <protocol/canopy.pdf#concreteed25519>`_
|
||||
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
|
||||
|
|
|
|||
|
|
@ -15,16 +15,9 @@ Created: 2020-02-28
|
|||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", 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>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Canopy</dt>
|
||||
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">5</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="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</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 the deployment of the Canopy network upgrade.</p>
|
||||
|
|
@ -33,17 +26,17 @@ License: MIT</pre>
|
|||
<section id="canopy-deployment"><h3><span class="section-heading">Canopy deployment</span><span class="section-anchor"> <a rel="bookmark" href="#canopy-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Canopy consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a></li>
|
||||
<li>ZIP 207: Funding Streams <a id="id7" class="footnote_reference" href="#zip-0207">5</a></li>
|
||||
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="id8" class="footnote_reference" href="#zip-0211">6</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="id9" class="footnote_reference" href="#zip-0212">7</a></li>
|
||||
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id10" class="footnote_reference" href="#zip-0214">8</a></li>
|
||||
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="id11" class="footnote_reference" href="#zip-0215">9</a></li>
|
||||
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id12" class="footnote_reference" href="#zip-1014">11</a>.</li>
|
||||
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="id5" class="footnote_reference" href="#zip-0200">5</a></li>
|
||||
<li>ZIP 207: Funding Streams <a id="id6" class="footnote_reference" href="#zip-0207">7</a></li>
|
||||
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="id7" class="footnote_reference" href="#zip-0211">8</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="id8" class="footnote_reference" href="#zip-0212">9</a></li>
|
||||
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id9" class="footnote_reference" href="#zip-0214">10</a></li>
|
||||
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="id10" class="footnote_reference" href="#zip-0215">11</a></li>
|
||||
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id11" class="footnote_reference" href="#zip-1014">13</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id13" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id14" class="footnote_reference" href="#zip-0200">3</a> are defined for the Canopy upgrade:</p>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id12" class="footnote_reference" href="#zip-0201">6</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id13" class="footnote_reference" href="#zip-0200">5</a> are defined for the Canopy upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0xE9FF75A6</code></dd>
|
||||
|
|
@ -61,7 +54,7 @@ License: MIT</pre>
|
|||
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
|
||||
*/
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id15" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id14" class="footnote_reference" href="#zip-0201">6</a>.</p>
|
||||
<p>Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Canopy nodes on that network;</li>
|
||||
|
|
@ -72,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="id16" class="footnote_reference" href="#protocol">2</a> section 7.1; and use the same transaction digest algorithm as defined in <a id="id17" class="footnote_reference" href="#zip-0243">10</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id18" class="footnote_reference" href="#zip-0243">10</a></p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="id15" class="footnote_reference" href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <a id="id16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id17" class="footnote_reference" href="#zip-0243">12</a></p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Canopy on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version 170013.</p>
|
||||
|
|
@ -90,14 +83,30 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
|
||||
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.9 or later [Canopy]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-txnencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/canopy.pdf#txnencoding">Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.1: Encoding of Transactions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -105,7 +114,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -113,7 +122,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0207" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<th>7</th>
|
||||
<td><a href="zip-0207">ZIP 207: Funding Streams</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -121,7 +130,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0211" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<th>8</th>
|
||||
<td><a href="zip-0211">ZIP 211: Disabling Addition of New Value to the Sprout Value Pool</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -129,7 +138,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0212" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -137,7 +146,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0214" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -145,7 +154,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0215" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0215">ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -153,7 +162,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-0243" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<th>12</th>
|
||||
<td><a href="zip-0243">ZIP 243: Transaction Signature Validation for Sapling</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -161,7 +170,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>13</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
17
zip-0251.rst
17
zip-0251.rst
|
|
@ -18,14 +18,11 @@ interpreted as described in RFC 2119. [#RFC2119]_
|
|||
The term "network upgrade" in this document is to be interpreted as described in
|
||||
ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
Canopy
|
||||
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
||||
Testnet
|
||||
The Zcash test network, as defined in [#protocol]_.
|
||||
Mainnet
|
||||
The Zcash production network, as defined in [#protocol]_.
|
||||
"Canopy" is the code-name for the fifth Zcash network upgrade, also known as
|
||||
Network Upgrade 4.
|
||||
|
||||
|
||||
Abstract
|
||||
|
|
@ -113,7 +110,7 @@ will always disconnect peers using lower protocol versions.
|
|||
Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not
|
||||
define a new transaction version. Canopy transactions are therefore in the same
|
||||
v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085
|
||||
as defined in [#protocol]_ section 7.1; and use the same transaction digest
|
||||
as defined in [#protocol-txnencoding]_; and use the same transaction digest
|
||||
algorithm as defined in [#zip-0243]_. This does not imply that transactions are
|
||||
valid across the Canopy activation, since signatures MUST use the appropriate
|
||||
consensus branch ID. [#zip-0243]_
|
||||
|
|
@ -131,7 +128,9 @@ References
|
|||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.9 or later [Canopy] <protocol/canopy.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
|
||||
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.1: Encoding of Transactions <protocol/canopy.pdf#txnencoding>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue