NU5 deployment

The primary sources of information about NU5 consensus and peer-to-peer protocol changes are:

• The Zcash Protocol Specification 2 4
• ZIP 200: Network Upgrade Mechanism 7
• ZIP 216: Require Canonical Point Encodings 13
• ZIP 224: Orchard Shielded Protocol 15
• ZIP 225: Version 5 Transaction Format 16
• ZIP 239: Relay of Version 5 Transactions 17
• ZIP 244: Transaction Identifier Non-Malleability 18
• The Orchard Book 21
• The halo2 Book 22

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

Unified addresses and viewing keys are described in ZIP 316 19.

The following ZIPs have been updated in varying degrees to take into account Orchard:

• ZIP 32: Shielded Hierarchical Deterministic Wallets 5
• ZIP 203: Transaction Expiry 9
• ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances 10
• ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext 11
• ZIP 213: Shielded Coinbase 12
• ZIP 221: FlyClient - Consensus-Layer Changes 14
• ZIP 401: Addressing Mempool Denial-of-Service 20

Support for the addrv2 peer protocol message, defined in ZIP 155 6, is being added concurrently with this upgrade, signalled by the same Mainnet peer protocol version.

The following network upgrade constants 7 are defined for the NU5 upgrade:

CONSENSUS_BRANCH_ID

0x37519621 (this will change if a second Testnet activation occurs)

ACTIVATION_HEIGHT (NU5)

Testnet: 1599200

Testnet (second activation): TODO

Mainnet: TODO

MIN_NETWORK_PROTOCOL_VERSION (NU5)

Testnet: 170015

Testnet (second activation): 170016

Mainnet: 170017

A second activation of NU5 on Testnet might or might not occur; if it does, then a reorganisation will occur to wipe out the original Testnet chain from height 1599200. In this case the CONSENSUS_BRANCH_ID will also change for the new Testnet epoch, and for Mainnet NU5 activation.

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 the MIN_NETWORK_PROTOCOL_VERSION (NU5) for that activation.

For each network, pre-NU5 nodes are defined as nodes advertising a protocol version less than that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).

Once NU5 activates on Testnet or Mainnet, NU5 nodes SHOULD take steps to:

• reject new connections from pre-NU5 nodes on that network;
• disconnect any existing connections to pre-NU5 nodes on that network.

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. 17

The change to the peer-to-peer protocol described in ZIP 155 is currently proposed to take effect from peer protocol version 170017 onward, on both Testnet and Mainnet 6. This might be changed to version 170016 depending on scheduling constraints.

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.

Backward compatibility in zcashd

The minimum peer protocol version that NU5-compatible zcashd nodes will connect to is 170002.

NU5 deployment for zcashd

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:

/**
 * 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 8.

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.

Backward compatibility in Zebra

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:

• 170012 on Testnet, or
• 170013 on Mainnet.

NU5 deployment for Zebra

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.

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.)