Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
133 lines (92 sloc) 4.81 KB
ZIP: 250
Title: Deployment of the Heartwood 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. [1]

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [3]

The terms below are to be interpreted as follows:

Heartwood
Code-name for the fourth Zcash network upgrade, also known as Network Upgrade 3.
Testnet
The Zcash test network, as defined in [2].
Mainnet
The Zcash production network, as defined in [2].

Abstract

This proposal defines the deployment of the Heartwood network upgrade.

Specification

Heartwood deployment

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

  • The Zcash Protocol Specification [2]
  • ZIP 200: Network Upgrade Mechanism [3]
  • ZIP 213: Shielded Coinbase [5]
  • ZIP 221: FlyClient - Consensus-Layer Changes [6].

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

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

CONSENSUS_BRANCH_ID
0xf5b9230b
ACTIVATION_HEIGHT (Heartwood)

Testnet: TODO

Mainnet: TODO

Nodes compatible with Heartwood activation on testnet MUST advertise protocol version 170010 or later. Nodes compatible with Heartwood activation on mainnet MUST advertise protocol version 170011 or later. The minimum peer protocol version that Heartwood-compatible nodes will connect to is 170002.

Pre-Heartwood testnet nodes are defined as nodes on testnet advertising a protocol version less than 170010. Pre-Heartwood mainnet nodes are defined as nodes on mainnet advertising a protocol version less than 170011.

For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding Heartwood activation height, nodes compatible with Heartwood activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Heartwood 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). */
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 Heartwood activates on testnet or mainnet, Heartwood nodes SHOULD take steps to:

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

Backward compatibility

Prior to the network upgrade activating on each network, Heartwood and pre-Heartwood nodes are compatible and can connect to each other. However, Heartwood nodes will have a preference for connecting to other Heartwood nodes, so pre-Heartwood nodes will gradually be disconnected in the run up to activation.

Once the network upgrades, even though pre-Heartwood nodes can still accept the numerically larger protocol version used by Heartwood as being valid, Heartwood nodes will always disconnect peers using lower protocol versions.

Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new transaction version. Heartwood transactions are therefore in the same v4 format as Sapling transactions, use the same version group ID, i.e. 0x892F2085 as defined in [2] section 7.1, and the same transaction digest algorithm as defined in [7]. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID. [7]

Support in zcashd

Support for Heartwood on testnet will be implemented in zcashd version 2.1.3, which will advertise protocol version 170010. Support for Heartwood on mainnet will be implemented in zcashd version 2.2.0, which will advertise protocol version 170011.

References

[1]Key words for use in RFCs to Indicate Requirement Levels
[2](1, 2, 3, 4) Zcash Protocol Specification, Version 2020.1.1 or later
[3](1, 2, 3) ZIP 200: Network Upgrade Activation Mechanism
[4](1, 2) ZIP 201: Network Peer Management for Overwinter
[5]ZIP 213: Shielded Coinbase
[6]ZIP 221: FlyClient - Consensus-Layer Changes
[7](1, 2) ZIP 243: Transaction Signature Verification for Sapling
You can’t perform that action at this time.