Skip to content

Latest commit

 

History

History
139 lines (98 loc) · 5.06 KB

zip-0251.rst

File metadata and controls

139 lines (98 loc) · 5.06 KB
Raw
ZIP: 251
Title: Deployment of the ${NU4} Network Upgrade
Owners: Daira Hopwood <[email protected]>
Status: Draft
Category: Consensus
Created: 2020-02-28
License: MIT

Terminology

The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. [1]

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [3]

The terms below are to be interpreted as follows:

${NU4}
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
Testnet
The Zcash test network, as defined in [2].
Mainnet
The Zcash production network, as defined in [2].

Abstract

This proposal defines the deployment of the ${NU4} network upgrade.

Specification

${NU4} deployment

The primary sources of information about ${NU4} consensus protocol changes are:

  • The Zcash Protocol Specification [2]
  • ZIP 200: Network Upgrade Mechanism [3]
  • ZIP 207: Funding Streams [5]
  • ZIP 214: Consensus rules for a Zcash Development Fund [6]
  • ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants [8]
  • TODO: other ZIPs

The network handshake and peer management mechanisms defined in ZIP 201 [4] also apply to this upgrade.

The following network upgrade constants [3] are defined for the ${NU4} upgrade:

CONSENSUS_BRANCH_ID
0xTODO
ACTIVATION_HEIGHT (${NU4})

Testnet: TODO

Mainnet: 1046400

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.

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.

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:

/**
 * 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;

The implementation is similar to that for Overwinter which was described in [4].

Once ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to:

  • reject new connections from pre-${NU4} nodes on that network;
  • disconnect any existing connections to pre-${NU4} nodes on that network.

Backward compatibility

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.

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.

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 [2] section 7.1; and use the same transaction digest algorithm as defined in [7]. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID. [7]

Support in zcashd

Support for ${NU4} on testnet will be implemented in zcashd version 3.1.0, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in zcashd version 4.0.0, which will advertise protocol version TODO.

References

[1]Key words for use in RFCs to Indicate Requirement Levels
[2](1, 2, 3, 4) Zcash Protocol Specification, Version 2020.1.1 or later
[3](1, 2, 3) ZIP 200: Network Upgrade Activation Mechanism
[4](1, 2) ZIP 201: Network Peer Management for Overwinter
[5]ZIP 208: Shorter Block Target Spacing
[6]ZIP 214: Consensus rules for a Zcash Development Fund
[7](1, 2) ZIP 243: Transaction Signature Verification for Sapling
[8]ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants