From ede12155664a5269cb053c86617b55bce6575c0a Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 28 Oct 2018 07:43:31 +0000 Subject: [PATCH] Add ZIP 205. Signed-off-by: Daira Hopwood --- zip-0205.rst | 143 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 zip-0205.rst diff --git a/zip-0205.rst b/zip-0205.rst new file mode 100644 index 00000000..ee159541 --- /dev/null +++ b/zip-0205.rst @@ -0,0 +1,143 @@ +:: + + ZIP: 205 + Title: Deployment of the Sapling Network Upgrade + Author: Daira Hopwood + Credits: Simon Liu + Category: Consensus + Created: 2018-10-08 + 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 terms "branch" and "network upgrade" in this document are to be interpreted as +described in ZIP 200. [#zip-0200]_ + +The terms below are to be interpreted as follows: + +Sapling + Code-name for the second Zcash network upgrade, also known as Network Upgrade 1. + + +Abstract +======== + +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. + + +Specification +============= + +Sapling deployment +------------------ + +The primary sources of information about Sapling consensus protocol changes are: + +- The Zcash Protocol Specification [#protocol]_. +- Transaction Signature Verification for Sapling [#zip-0243]_. +- Network Upgrade Activation Mechanism [#zip-0200]_. + +The network handshake and peer management mechanisms defined in [#zip-0201]_ also +apply to this upgrade. + + +The following network upgrade constants [#zip-0200]_ are defined for the Sapling +upgrade: + +BRANCH_ID + ``0x76b809bb`` + +ACTIVATION_HEIGHT (Sapling) + 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 +[#zip-0201]. + +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 [#protocol]_ 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 [#protocol]_ 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. + + +References +========== + +.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-32 [Overwinter+Sapling] `_ +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ +.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ +.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling `_