<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <aid="id1"class="footnote_reference"href="#rfc2119">1</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <aid="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.12 of the Zcash Protocol Specification <aid="id3"class="footnote_reference"href="#protocol-networks">3</a>.</p>
<p>This proposal defines the deployment of the Sapling network upgrade. In addition, it describes a hard fork that occurred on Testnet to allow "minimum-difficulty" blocks.</p>
<p>The network handshake and peer management mechanisms defined in <aid="id7"class="footnote_reference"href="#zip-0201">8</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <aid="id8"class="footnote_reference"href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
<p>On Testnet, Sapling had activated prior to this height, but that consensus branch was rolled back. A subsequent hard fork occurred on Testnet, changing the difficulty algorithm to accept "minimum-difficulty" blocks under certain conditions starting at block height 299188.</p>
<p>On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol version 170007 or later. The minimum peer protocol version that Sapling-compatible nodes will connect to, remains 170002.</p>
<p>Pre-Sapling nodes are defined as nodes advertising a protocol version less than 170007.</p>
<p>Approximately three days (defined in terms of block height) before the Sapling activation height, Sapling-compatible nodes will change the behaviour of their peer connection logic in order to prefer pre-Sapling peers 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). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<sectionid="change-to-difficulty-adjustment-on-testnet"><h3><spanclass="section-heading">Change to difficulty adjustment on Testnet</span><spanclass="section-anchor"><arel="bookmark"href="#change-to-difficulty-adjustment-on-testnet"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>Section 7.6.3 of the Zcash Protocol Specification <aid="id10"class="footnote_reference"href="#protocol-diffadjustment">5</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <aid="id11"class="footnote_reference"href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <aid="id12"class="footnote_reference"href="#protocol-nbits">6</a>.</p>
<p>Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
<p>Prior to the network upgrade activating, Sapling and pre-Sapling nodes are compatible and can connect to each other. However, Sapling nodes will have a preference for connecting to other Sapling nodes, so pre-Sapling nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Sapling nodes can still accept the numerically larger protocol version used by Sapling as being valid, Sapling nodes will always disconnect peers using lower protocol versions.</p>
<sectionid="support-in-zcashd"><h2><spanclass="section-heading">Support in zcashd</span><spanclass="section-anchor"><arel="bookmark"href="#support-in-zcashd"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h2>
<p>Support for Sapling consensus rules was implemented in zcashd version 2.0.0. The majority of support for RPC calls and persistence of Sapling z-addresses was implemented in version 2.0.1. Both of these versions advertise protocol version 170007.</p>