Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
144 lines (97 sloc) 5.23 KB
ZIP: 205
Title: Deployment of the Sapling Network Upgrade
Author: Daira Hopwood <>
Credits: Simon Liu <>
Category: Consensus
Created: 2018-10-08
License: MIT


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

The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [3]

The terms below are to be interpreted as follows:

Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.


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.


Sapling deployment

The primary sources of information about Sapling consensus protocol changes are:

  • The Zcash Protocol Specification [1].
  • Transaction Signature Verification for Sapling [5].
  • Network Upgrade Activation Mechanism [3].

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

The following network upgrade constants [3] are defined for the Sapling upgrade:


Testnet: 280000

Mainnet: 419200

On testnet, Sapling had activated prior to this height, but that 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.

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.

Pre-Sapling nodes are defined as nodes advertising a protocol version less than 170007.

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.

/** 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 Sapling activates on testnet or mainnet, Sapling nodes should take steps to:

  • reject new connections from pre-Sapling nodes;
  • disconnect any existing connections to pre-Sapling nodes.

Change to difficulty adjustment on testnet

Section 7.6.3 of [1] describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the nTime and nBits fields of preceding blocks.

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 at least 15 minutes after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see [1] section 5.3). However, its nBits field is still computed according to the original difficulty adjustment algorithm.

This does not affect how the minimum-difficulty block is treated for subsequent difficulty adjustments. In particular, only the nBits field computed by the original algorithm is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.

This change does not affect mainnet.

Backward compatibility

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.

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.

Support in zcashd

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.


[1](1, 2, 3) Zcash Protocol Specification, Version 2018.0-beta-32 [Overwinter+Sapling]
[2]Key words for use in RFCs to Indicate Requirement Levels
[3](1, 2, 3) ZIP 200: Network Upgrade Activation Mechanism
[4](1, 2) ZIP 201: Network Peer Management for Overwinter
[5]ZIP 243: Transaction Signature Verification for Sapling