zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIPs 239 and 252: updates for revised testnet activation. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-10-02 00:46:00 +01:00
parent 52abb0c609
commit d1909fb05a
4 changed files with 147 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
zip-0239.html
View File

@ -43,7 +43,8 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
<p>Note that <code>MSG_WTX</code> might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.</p>
<p><code>MSG_TX</code> and <code>MSG_WTX</code> entries may be mixed in arbitrary order in an <code>inv</code> message or a <code>getdata</code> message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial <code>count</code> field, and has to be determined by parsing the whole message.</p>
<section id="deployment"><h3><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></h3>
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5. In <a id="id13" class="footnote_reference" href="#zip-0252">5</a>, the minimum protocol version that signals support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol version that enables support for this specification is also defined to be 170014 (on both Testnet and Mainnet).</p>
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5.</p>
<p>The peer protocol version that enables support for this specification is defined to be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol version that signals support for NU5 on Testnet, which is 170015. <a id="id13" class="footnote_reference" href="#zip-0252">7</a></p>
<p>As specified in <a id="id14" class="footnote_reference" href="#zip-0200">4</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
<p>Nevertheless, it is possible for a node to receive an <code>inv</code> or <code>getdata</code> message with a <code>MSG_WTX</code> inv type, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. The node MUST handle this case in the same way that it would after NU5 activation when it has no v5 transactions to relay. Receiving a <code>MSG_WTX</code> inv type on a peer connection that has negotiated a protocol version before 170014, on the other hand, SHOULD be treated as a protocol error.</p>
<p>As the <code>MSG_WTX</code> inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.</p>

9
zip-0239.rst
View File

@ -118,10 +118,11 @@ Deployment
----------
This ZIP is assumed to be deployed in advance of the network upgrade that introduces
v5 transactions, i.e. NU5. In [#zip-0252]_, the minimum protocol version that signals
support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol
version that enables support for this specification is also defined to be 170014
(on both Testnet and Mainnet).
v5 transactions, i.e. NU5.
The peer protocol version that enables support for this specification is defined to
be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol
version that signals support for NU5 on Testnet, which is 170015. [#zip-0252]_
As specified in [#zip-0200]_, a node that supports a network upgrade will clear its
mempool when reaching the block before that upgrade's activation block. Before this

126
zip-0252.html
View File

@ -28,58 +28,71 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://githu
<section id="nu5-deployment"><h3><span class="section-heading">NU5 deployment</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about NU5 consensus and peer-to-peer protocol changes are:</p>
<ul>
<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">7</a></li>
<li>ZIP 216: Require Canonical Point Encodings <a id="id6" class="footnote_reference" href="#zip-0216">9</a></li>
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="id7" class="footnote_reference" href="#zip-0221">10</a> (amended)</li>
<li>ZIP 224: Orchard Shielded Protocol <a id="id8" class="footnote_reference" href="#zip-0224">11</a></li>
<li>ZIP 225: Version 5 Transaction Format <a id="id9" class="footnote_reference" href="#zip-0225">12</a></li>
<li>ZIP 239: Relay of Version 5 Transactions <a id="id10" class="footnote_reference" href="#zip-0239">13</a></li>
<li>ZIP 244: Transaction Identifier Non-Malleability <a id="id11" class="footnote_reference" href="#zip-0244">14</a></li>
<li>The Orchard Book <a id="id12" class="footnote_reference" href="#orchard-book">16</a></li>
<li>The halo2 Book <a id="id13" class="footnote_reference" href="#halo2-book">17</a></li>
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a> <a id="id5" class="footnote_reference" href="#protocol-txnencoding">4</a></li>
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">7</a></li>
<li>ZIP 216: Require Canonical Point Encodings <a id="id7" class="footnote_reference" href="#zip-0216">13</a></li>
<li>ZIP 224: Orchard Shielded Protocol <a id="id8" class="footnote_reference" href="#zip-0224">15</a></li>
<li>ZIP 225: Version 5 Transaction Format <a id="id9" class="footnote_reference" href="#zip-0225">16</a></li>
<li>ZIP 239: Relay of Version 5 Transactions <a id="id10" class="footnote_reference" href="#zip-0239">17</a></li>
<li>ZIP 244: Transaction Identifier Non-Malleability <a id="id11" class="footnote_reference" href="#zip-0244">18</a></li>
<li>The Orchard Book <a id="id12" class="footnote_reference" href="#orchard-book">21</a></li>
<li>The halo2 Book <a id="id13" class="footnote_reference" href="#halo2-book">22</a></li>
</ul>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id14" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
<p>Unified addresses and viewing keys are described in ZIP 316 <a id="id15" class="footnote_reference" href="#zip-0316">19</a>.</p>
<p>The following ZIPs have been updated in varying degrees to take into account Orchard:</p>
<ul>
<li>ZIP 32: Shielded Hierarchical Deterministic Wallets <a id="id16" class="footnote_reference" href="#zip-0032">5</a></li>
<li>ZIP 203: Transaction Expiry <a id="id17" class="footnote_reference" href="#zip-0203">9</a></li>
<li>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <a id="id18" class="footnote_reference" href="#zip-0209">10</a></li>
<li>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <a id="id19" class="footnote_reference" href="#zip-0212">11</a></li>
<li>ZIP 213: Shielded Coinbase <a id="id20" class="footnote_reference" href="#zip-0213">12</a></li>
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="id21" class="footnote_reference" href="#zip-0221">14</a></li>
<li>ZIP 401: Addressing Mempool Denial-of-Service <a id="id22" class="footnote_reference" href="#zip-0401">20</a></li>
</ul>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id14" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade. Unified addresses and viewing keys are described in ZIP 316 <a id="id15" class="footnote_reference" href="#zip-0316">15</a>. ZIP 32 <a id="id16" class="footnote_reference" href="#zip-0032">5</a> has been amended to include hierarchical key derivation for Orchard.</p>
<p>Support for the <code>addrv2</code> peer protocol message, defined in ZIP 155 [#zip-0155], is being added concurrently with this upgrade, signalled by the same Mainnet peer protocol version.</p>
<p>The following network upgrade constants <a id="id17" class="footnote_reference" href="#zip-0200">7</a> are defined for the NU5 upgrade:</p>
<p>The following network upgrade constants <a id="id23" class="footnote_reference" href="#zip-0200">7</a> are defined for the NU5 upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xF919A198</code></dd>
<dd><code>0x37519621</code> (this will change if a second Testnet activation occurs)</dd>
<dt>ACTIVATION_HEIGHT (NU5)</dt>
<dd>
<p>Testnet: TODO</p>
<p>Testnet: 1599200</p>
<p>Testnet (second activation): TODO</p>
<p>Mainnet: TODO</p>
</dd>
<dt>MIN_NETWORK_PROTOCOL_VERSION (NU5)</dt>
<dd>
<p>Testnet: 170014</p>
<p>Mainnet: 170015</p>
<p>Testnet: 170015</p>
<p>Testnet (second activation): 170016</p>
<p>Mainnet: 170017</p>
</dd>
</dl>
<p>For each network (Testnet and Mainnet), nodes compatible with NU5 activation on that network MUST advertise a network protocol version that is greater than or equal to that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).</p>
<p>A second activation of NU5 on Testnet might or might not occur; if it does, then a reorganisation will occur to wipe out the original Testnet chain from height 1599200. In this case the CONSENSUS_BRANCH_ID will also change for the new Testnet epoch, and for Mainnet NU5 activation.</p>
<p>For each network (Testnet and Mainnet), nodes compatible with NU5 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU5) for that activation.</p>
<p>For each network, pre-NU5 nodes are defined as nodes advertising a protocol version less than that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).</p>
<p>Once NU5 activates on Testnet or Mainnet, NU5 nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-NU5 nodes on that network;</li>
<li>disconnect any existing connections to pre-NU5 nodes on that network.</li>
</ul>
<p>The change to the peer-to-peer protocol described in ZIP 239 takes effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <a id="id18" class="footnote_reference" href="#zip-0239">13</a></p>
<p>The change to the peer-to-peer protocol described in ZIP 155 takes effect from peer protocol version 170015 onward, on both Testnet and Mainnet. <a id="id19" class="footnote_reference" href="#zip-0155">6</a></p>
<p>The change to the peer-to-peer protocol described in ZIP 239 takes effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <a id="id24" class="footnote_reference" href="#zip-0239">17</a></p>
<p>The change to the peer-to-peer protocol described in ZIP 155 is currently proposed to take effect from peer protocol version 170017 onward, on both Testnet and Mainnet <a id="id25" class="footnote_reference" href="#zip-0155">6</a>. This might be changed to version 170016 depending on scheduling constraints.</p>
<p>Note: these peer-to-peer protocol changes are enabled whenever the relevant version (or higher) is negotiated on a given connection, which can happen in advance of the Testnet or Mainnet NU5 activation.</p>
</section>
</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>Prior to the network upgrade activating on each network, NU5 and pre-NU5 nodes are compatible and can connect to each other.</p>
<p>Once the network upgrades, even though pre-NU5 nodes can still accept the numerically larger protocol version used by NU5 as being valid, NU5 nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by <a id="id20" class="footnote_reference" href="#zip-0225">12</a>. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.</p>
<p>Backward compatibility of the new <code>MSG_WTX</code> inv type introduced for <code>inv</code> and <code>getdata</code> messages is discussed in <a id="id21" class="footnote_reference" href="#zip-0239">13</a>.</p>
<p>Backward compatibility of the new <code>addrv2</code> message (not technically part of NU5) is discussed in <a id="id22" class="footnote_reference" href="#zip-0155">6</a>.</p>
<p>Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by <a id="id26" class="footnote_reference" href="#zip-0225">16</a>. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.</p>
<p>Backward compatibility of the new <code>MSG_WTX</code> inv type introduced for <code>inv</code> and <code>getdata</code> messages is discussed in <a id="id27" class="footnote_reference" href="#zip-0239">17</a>.</p>
<p>Backward compatibility of the new <code>addrv2</code> message (not technically part of NU5) is discussed in <a id="id28" class="footnote_reference" href="#zip-0155">6</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><strong>TODO: Update as needed</strong></p>
<p>Support for NU5 on Testnet will be implemented in <code>zcashd</code> version 4.5.0, which will advertise protocol version 170014. Support for NU5 on Mainnet will be implemented in <code>zcashd</code> version 5.0.0, which will advertise protocol version 170015.</p>
<p>Support for NU5 on Testnet is implemented in <cite>zcashd</cite> version 4.5.1, which advertises protocol version 170015. (A previous revision of the NU5 consensus rules was implemented in <cite>zcashd</cite> version 4.5.0, but this revision contained critical bugs in the Orchard Action circuit. Before it could activate, <cite>zcashd</cite> version 4.5.1 was released, with the later NU5 Testnet activation height and consensus branch ID defined in this document.)</p>
<p>Support for NU5 on Mainnet will be implemented in <cite>zcashd</cite> version 5.0.0, which will advertise protocol version 170017.</p>
<section id="backward-compatibility-in-zcashd"><h3><span class="section-heading">Backward compatibility in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The minimum peer protocol version that NU5-compatible <code>zcashd</code> nodes will connect to is 170002.</p>
<p>The minimum peer protocol version that NU5-compatible <cite>zcashd</cite> nodes will connect to is 170002.</p>
</section>
<section id="nu5-deployment-for-zcashd"><h3><span class="section-heading">NU5 deployment for zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment-for-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For each network, approximately 1.5 days (defined in terms of block height) before the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will change the behaviour of their peer connection logic in order to prefer pre-NU5 peers on that network for eviction from the set of peer connections:</p>
@ -88,13 +101,12 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">https://githu
* 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="id23" class="footnote_reference" href="#zip-0201">8</a>.</p>
<p>The implementation is similar to that for Overwinter which was described in <a id="id29" class="footnote_reference" href="#zip-0201">8</a>.</p>
<p>However, NU5 nodes will have a preference for connecting to other NU5 nodes, so pre-NU5 nodes will gradually be disconnected in the run up to activation.</p>
</section>
</section>
<section id="support-in-zebra"><h2><span class="section-heading">Support in Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zebra"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><strong>TODO: Update as needed</strong></p>
<p>Support for NU5 on Testnet will be implemented in Zebra version 1.0.0, which will advertise protocol version 170014. Support for NU5 on Mainnet will be implemented in Zebra version 2.0.0, which will advertise protocol version 170015.</p>
<p>Partial support for NU5 on Testnet will be implemented in Zebra version 1.0.0-alpha.18, which will advertise protocol version 170015. This version will validate a strict subset of NU5 consensus rules on Testnet.</p>
<section id="backward-compatibility-in-zebra"><h3><span class="section-heading">Backward compatibility in Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility-in-zebra"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The minimum peer protocol version that NU5-compatible Zebra nodes will connect to is 170002. However, Zebra will immediately disconnect from nodes with a protocol version less than:</p>
<ul>
@ -172,10 +184,42 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
</tr>
</tbody>
</table>
<table id="zip-0216" class="footnote">
<table id="zip-0203" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
</tr>
</tbody>
</table>
<table id="zip-0209" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="zip-0209">ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances</a></td>
</tr>
</tbody>
</table>
<table id="zip-0212" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a></td>
</tr>
</tbody>
</table>
<table id="zip-0213" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
</tr>
</tbody>
</table>
<table id="zip-0216" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="zip-0216">ZIP 216: Require Canonical Point Encodings</a></td>
</tr>
</tbody>
@ -183,7 +227,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0221" class="footnote">
<tbody>
<tr>
<th>10</th>
<th>14</th>
<td><a href="zip-0221">ZIP 221: FlyClient - Consensus-Layer Changes</a></td>
</tr>
</tbody>
@ -191,7 +235,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0224" class="footnote">
<tbody>
<tr>
<th>11</th>
<th>15</th>
<td><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></td>
</tr>
</tbody>
@ -199,7 +243,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0225" class="footnote">
<tbody>
<tr>
<th>12</th>
<th>16</th>
<td><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></td>
</tr>
</tbody>
@ -207,7 +251,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0239" class="footnote">
<tbody>
<tr>
<th>13</th>
<th>17</th>
<td><a href="zip-0239">ZIP 239: Relay of Version 5 Transactions</a></td>
</tr>
</tbody>
@ -215,7 +259,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0244" class="footnote">
<tbody>
<tr>
<th>14</th>
<th>18</th>
<td><a href="zip-0244">ZIP 244: Transaction Identifier Non-Malleability</a></td>
</tr>
</tbody>
@ -223,15 +267,23 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-0316" class="footnote">
<tbody>
<tr>
<th>15</th>
<th>19</th>
<td><a href="zip-0316">ZIP 316: Unified Addresses and Unified Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="zip-0401" class="footnote">
<tbody>
<tr>
<th>20</th>
<td><a href="zip-0401">ZIP 401: Addressing Mempool Denial-of-Service</a></td>
</tr>
</tbody>
</table>
<table id="orchard-book" class="footnote">
<tbody>
<tr>
<th>16</th>
<th>21</th>
<td><a href="https://zcash.github.io/orchard/">The Orchard Book</a></td>
</tr>
</tbody>
@ -239,7 +291,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="halo2-book" class="footnote">
<tbody>
<tr>
<th>17</th>
<th>22</th>
<td><a href="https://zcash.github.io/halo2/">The halo2 Book</a></td>
</tr>
</tbody>

77
zip-0252.rst
View File

@ -40,10 +40,9 @@ NU5 deployment
The primary sources of information about NU5 consensus and peer-to-peer protocol
changes are:
- The Zcash Protocol Specification [#protocol]_
- The Zcash Protocol Specification [#protocol]_ [#protocol-txnencoding]_
- ZIP 200: Network Upgrade Mechanism [#zip-0200]_
- ZIP 216: Require Canonical Point Encodings [#zip-0216]_
- ZIP 221: FlyClient - Consensus-Layer Changes [#zip-0221]_ (amended)
- ZIP 224: Orchard Shielded Protocol [#zip-0224]_
- ZIP 225: Version 5 Transaction Format [#zip-0225]_
- ZIP 239: Relay of Version 5 Transactions [#zip-0239]_
@ -52,9 +51,19 @@ changes are:
- The halo2 Book [#halo2-book]_
The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_
also apply to this upgrade. Unified addresses and viewing keys are described in
ZIP 316 [#zip-0316]_. ZIP 32 [#zip-0032]_ has been amended to include hierarchical
key derivation for Orchard.
also apply to this upgrade.
Unified addresses and viewing keys are described in ZIP 316 [#zip-0316]_.
The following ZIPs have been updated in varying degrees to take into account Orchard:
- ZIP 32: Shielded Hierarchical Deterministic Wallets [#zip-0032]_
- ZIP 203: Transaction Expiry [#zip-0203]_
- ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances [#zip-0209]_
- ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext [#zip-0212]_
- ZIP 213: Shielded Coinbase [#zip-0213]_
- ZIP 221: FlyClient - Consensus-Layer Changes [#zip-0221]_
- ZIP 401: Addressing Mempool Denial-of-Service [#zip-0401]_
Support for the ``addrv2`` peer protocol message, defined in ZIP 155 [#zip-0155],
is being added concurrently with this upgrade, signalled by the same Mainnet peer
@ -65,24 +74,33 @@ The following network upgrade constants [#zip-0200]_ are defined for the NU5
upgrade:
CONSENSUS_BRANCH_ID
``0xF919A198``
``0x37519621`` (this will change if a second Testnet activation occurs)
ACTIVATION_HEIGHT (NU5)
Testnet: TODO
Testnet: 1599200
Testnet (second activation): TODO
Mainnet: TODO
MIN_NETWORK_PROTOCOL_VERSION (NU5)
Testnet: 170014
Testnet: 170015
Mainnet: 170015
Testnet (second activation): 170016
Mainnet: 170017
A second activation of NU5 on Testnet might or might not occur; if it does,
then a reorganisation will occur to wipe out the original Testnet chain from
height 1599200. In this case the CONSENSUS_BRANCH_ID will also change for the
new Testnet epoch, and for Mainnet NU5 activation.
For each network (Testnet and Mainnet), nodes compatible with NU5 activation
on that network MUST advertise a network protocol version that is greater than
or equal to that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).
or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU5) for that activation.
For each network, pre-NU5 nodes are defined as nodes advertising a protocol
version less than that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).
@ -95,8 +113,10 @@ Once NU5 activates on Testnet or Mainnet, NU5 nodes SHOULD take steps to:
The change to the peer-to-peer protocol described in ZIP 239 takes effect
from peer protocol version 170014 onward, on both Testnet and Mainnet. [#zip-0239]_
The change to the peer-to-peer protocol described in ZIP 155 takes effect
from peer protocol version 170015 onward, on both Testnet and Mainnet. [#zip-0155]_
The change to the peer-to-peer protocol described in ZIP 155 is currently
proposed to take effect from peer protocol version 170017 onward, on both
Testnet and Mainnet [#zip-0155]_. This might be changed to version 170016
depending on scheduling constraints.
Note: these peer-to-peer protocol changes are enabled whenever the relevant
version (or higher) is negotiated on a given connection, which can happen in
@ -129,19 +149,21 @@ NU5) is discussed in [#zip-0155]_.
Support in zcashd
=================
**TODO: Update as needed**
Support for NU5 on Testnet will be implemented in ``zcashd`` version 4.5.0, which
will advertise protocol version 170014. Support for NU5 on Mainnet will be implemented
in ``zcashd`` version 5.0.0, which will advertise protocol version 170015.
Support for NU5 on Testnet is implemented in `zcashd` version 4.5.1, which
advertises protocol version 170015. (A previous revision of the NU5 consensus
rules was implemented in `zcashd` version 4.5.0, but this revision contained
critical bugs in the Orchard Action circuit. Before it could activate, `zcashd`
version 4.5.1 was released, with the later NU5 Testnet activation height and
consensus branch ID defined in this document.)
Support for NU5 on Mainnet will be implemented in `zcashd` version 5.0.0,
which will advertise protocol version 170017.
Backward compatibility in zcashd
--------------------------------
The minimum peer protocol version that NU5-compatible ``zcashd`` nodes will connect to
is 170002.
The minimum peer protocol version that NU5-compatible `zcashd` nodes will
connect to is 170002.
NU5 deployment for zcashd
-------------------------
@ -164,15 +186,13 @@ The implementation is similar to that for Overwinter which was described in
However, NU5 nodes will have a preference for connecting to other NU5 nodes, so
pre-NU5 nodes will gradually be disconnected in the run up to activation.
Support in Zebra
================
**TODO: Update as needed**
Support for NU5 on Testnet will be implemented in Zebra version 1.0.0, which
will advertise protocol version 170014. Support for NU5 on Mainnet will be implemented
in Zebra version 2.0.0, which will advertise protocol version 170015.
Partial support for NU5 on Testnet will be implemented in Zebra version
1.0.0-alpha.18, which will advertise protocol version 170015. This version
will validate a strict subset of NU5 consensus rules on Testnet.
Backward compatibility in Zebra
-------------------------------
@ -208,6 +228,10 @@ References
.. [#zip-0155] `ZIP 155: addrv2 message <zip-0155.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <zip-0209.rst>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0216] `ZIP 216: Require Canonical Point Encodings <zip-0216.rst>`_
.. [#zip-0221] `ZIP 221: FlyClient - Consensus-Layer Changes <zip-0221.rst>`_
.. [#zip-0224] `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`_
@ -215,5 +239,6 @@ References
.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`_
.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`_
.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`_
.. [#zip-0401] `ZIP 401: Addressing Mempool Denial-of-Service <zip-0401.rst>`_
.. [#orchard-book] `The Orchard Book <https://zcash.github.io/orchard/>`_
.. [#halo2-book] `The halo2 Book <https://zcash.github.io/halo2/>`_