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
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:
This proposal defines the deployment of the ${NU4} network upgrade.
The primary sources of information about ${NU4} consensus protocol changes are:
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:
0xTODO
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 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:
/** 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;
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:
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 for ${NU4} on testnet will be implemented in zcashd
version TODO, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in zcashd
version 3.0.0, which will advertise protocol version TODO.
1 | Key words for use in RFCs to Indicate Requirement Levels |
---|
2 | Zcash Protocol Specification, Version 2020.1.1 or later |
---|
3 | ZIP 200: Network Upgrade Activation Mechanism |
---|
4 | 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 | ZIP 243: Transaction Signature Verification for Sapling |
---|
8 | ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants |
---|