forked from zcash/zips
-
Notifications
You must be signed in to change notification settings - Fork 0
/
zip-0252.html
250 lines (250 loc) · 18.1 KB
/
zip-0252.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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
<!DOCTYPE html>
<html>
<head>
<title>ZIP 252: Deployment of the NU5 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: 252
Title: Deployment of the NU5 Network Upgrade
Owners: teor <teor@zfnd.org>
Daira Hopwood <daira@electriccoin.co>
Status: Proposed
Category: Consensus / Network
Created: 2021-02-23
License: MIT
Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>>
Pull-Request: <<a href="https://github.com/zcash/zips/pull/446">https://github.com/zcash/zips/pull/446</a>></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" and "SHOULD" 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">7</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>
</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 NU5 network upgrade.</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="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>
</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>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xF919A198</code></dd>
<dt>ACTIVATION_HEIGHT (NU5)</dt>
<dd>
<p>Testnet: TODO</p>
<p>Mainnet: TODO</p>
</dd>
<dt>MIN_NETWORK_PROTOCOL_VERSION (NU5)</dt>
<dd>
<p>Testnet: 170014</p>
<p>Mainnet: 170015</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>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>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>
</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>
<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>
</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>
<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="id23" 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>
<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>
<li>170012 on Testnet, or</li>
<li>170013 on Mainnet.</li>
</ul>
</section>
<section id="nu5-deployment-for-zebra"><h3><span class="section-heading">NU5 deployment for Zebra</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment-for-zebra"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For each network, at the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will close any new connections with pre-NU5 peers.</p>
<p>Since Zebra maintains a reasonably strict internal request-response protocol, pre-NU5 nodes will gradually be disconnected after activation. (Nodes are temporarily disconnected if they send gossip or chain sync hints outside the strict request-response sequence that Zebra expects.)</p>
</section>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.24 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/nu5.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="zip-0155" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0155">ZIP 155: addrv2 message</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0201" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0216" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-0216">ZIP 216: Require Canonical Point Encodings</a></td>
</tr>
</tbody>
</table>
<table id="zip-0221" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="zip-0221">ZIP 221: FlyClient - Consensus-Layer Changes</a></td>
</tr>
</tbody>
</table>
<table id="zip-0224" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></td>
</tr>
</tbody>
</table>
<table id="zip-0225" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></td>
</tr>
</tbody>
</table>
<table id="zip-0239" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="zip-0239">ZIP 239: Relay of Version 5 Transactions</a></td>
</tr>
</tbody>
</table>
<table id="zip-0244" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="zip-0244">ZIP 244: Transaction Identifier Non-Malleability</a></td>
</tr>
</tbody>
</table>
<table id="zip-0316" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="zip-0316">ZIP 316: Unified Addresses and Unified Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="orchard-book" class="footnote">
<tbody>
<tr>
<th>16</th>
<td><a href="https://zcash.github.io/orchard/">The Orchard Book</a></td>
</tr>
</tbody>
</table>
<table id="halo2-book" class="footnote">
<tbody>
<tr>
<th>17</th>
<td><a href="https://zcash.github.io/halo2/">The halo2 Book</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>