::

  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


Terminology
===========

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

The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_

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 [#protocol]_.
Mainnet
  The Zcash production network, as defined in [#protocol]_.


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 [#protocol]_
- ZIP 200: Network Upgrade Mechanism [#zip-0200]_
- ZIP 207: Funding Streams [#zip-0207]_
- ZIP 214: Consensus rules for a Zcash Development Fund [#zip-0214]_
- ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants [#zip-1014]_
- TODO: other ZIPs

The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_
also apply to this upgrade.


The following network upgrade constants [#zip-0200]_ 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
[#zip-0201]_.

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


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
==========

.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0207] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <zip-0243.rst>`_
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_