mirror of https://github.com/zcash/zips.git
135 lines
9.9 KiB
HTML
135 lines
9.9 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<title>ZIP 251: Deployment of the Network Upgrade</title>
|
||
|
|
<meta charset="utf-8" />
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||
|
|
<body>
|
||
|
|
<section>
|
||
|
|
<pre>ZIP: 251
|
||
|
|
Title: Deployment of the ${NU4} Network Upgrade
|
||
|
|
Owners: Daira Hopwood <daira@electriccoin.co>
|
||
|
|
Status: Draft
|
||
|
|
Category: Consensus
|
||
|
|
Created: 2020-02-28
|
||
|
|
License: MIT</pre>
|
||
|
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a 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>${NU4}</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>
|
||
|
|
</section>
|
||
|
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a 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 ${NU4} network upgrade.</p>
|
||
|
|
</section>
|
||
|
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
|
<section id="nu4-deployment"><h3><span class="section-heading">${NU4} deployment</span><span class="section-anchor"> <a href="#nu4-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||
|
|
<p>The primary sources of information about ${NU4} 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 214: Consensus rules for a Zcash Development Fund <a id="id8" class="footnote_reference" href="#zip-0214">6</a></li>
|
||
|
|
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id9" class="footnote_reference" href="#zip-1014">7</a></li>
|
||
|
|
<li>TODO: other ZIPs</li>
|
||
|
|
</ul>
|
||
|
|
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id10" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||
|
|
<p>The following network upgrade constants <a id="id11" class="footnote_reference" href="#zip-0200">3</a> are defined for the ${NU4} upgrade:</p>
|
||
|
|
<dl>
|
||
|
|
<dt>BRANCH_ID</dt>
|
||
|
|
<dd><code>0xTODO</code></dd>
|
||
|
|
<dt>ACTIVATION_HEIGHT (${NU4})</dt>
|
||
|
|
<dd>
|
||
|
|
<p>Testnet: TODO</p>
|
||
|
|
<p>Mainnet: 1046400</p>
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
<p>Nodes compatible with ${NU4} activation on testnet MUST advertise protocol version TODO or later. Nodes compatible with ${NU4} activation on mainnet MUST advertise protocol version TODO or later. The minimum peer protocol version that ${NU4}-compatible nodes will connect to is 170002.</p>
|
||
|
|
<p>Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet advertising a protocol version less than TODO.</p>
|
||
|
|
<p>For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} peers on that network for eviction from the set of peer connections:</p>
|
||
|
|
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||
|
|
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
|
||
|
|
<p>The implementation is similar to that for Overwinter which was described in <a id="id12" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||
|
|
<p>Once ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to:</p>
|
||
|
|
<ul>
|
||
|
|
<li>reject new connections from pre-${NU4} nodes on that network;</li>
|
||
|
|
<li>disconnect any existing connections to pre-${NU4} nodes on that network.</li>
|
||
|
|
</ul>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a 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, ${NU4} and pre-${NU4} nodes are compatible and can connect to each other. However, ${NU4} nodes will have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will gradually be disconnected in the run up to activation.</p>
|
||
|
|
<p>Once the network upgrades, even though pre-${NU4} nodes can still accept the numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes will always disconnect peers using lower protocol versions.</p>
|
||
|
|
<p>TODO: delete if applicable. Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new transaction version. ${NU4} transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id13" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID.</p>
|
||
|
|
</section>
|
||
|
|
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
|
<p>Support for ${NU4} on testnet will be implemented in <code>zcashd</code> version TODO, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in <code>zcashd</code> version 3.0.0, which will advertise protocol version TODO.</p>
|
||
|
|
</section>
|
||
|
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||
|
|
<table id="rfc2119" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>1</th>
|
||
|
|
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<table id="protocol" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>2</th>
|
||
|
|
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<table id="zip-0200" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>3</th>
|
||
|
|
<td><a href="zip-0200">ZIP 200: Network Upgrade Activation Mechanism</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<table id="zip-0201" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>4</th>
|
||
|
|
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<table id="zip-0207" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>5</th>
|
||
|
|
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<table id="zip-0214" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>6</th>
|
||
|
|
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<table id="zip-1014" class="footnote">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<th>7</th>
|
||
|
|
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
</body>
|
||
|
|
</html>
|