forked from ZcashFoundation/zips
-
Notifications
You must be signed in to change notification settings - Fork 1
/
zip-0251.html
146 lines (146 loc) · 10.5 KB
/
zip-0251.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
<!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 <[email protected]>
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">8</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>CONSENSUS_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 1.5 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).
* 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="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 inapplicable. Unlike Overwinter and Sapling, and like Blossom and Heartwood, ${NU4} does not define a new transaction version. ${NU4} 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="id13" class="footnote_reference" href="#protocol">2</a> section 7.1; and use the same transaction digest algorithm as defined in <a id="id14" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID. <a id="id15" class="footnote_reference" href="#zip-0243">7</a></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 3.1.0, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in <code>zcashd</code> version 4.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 2020.1.1 or later</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-0243" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0243">ZIP 243: Transaction Signature Verification for Sapling</a></td>
</tr>
</tbody>
</table>
<table id="zip-1014" class="footnote">
<tbody>
<tr>
<th>8</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>