129 lines
4.4 KiB
ReStructuredText
129 lines
4.4 KiB
ReStructuredText
::
|
|
|
|
ZIP: 206
|
|
Title: Deployment of the Blossom Network Upgrade
|
|
Owners: Daira Hopwood <daira@electriccoin.co>
|
|
Credits: Simon Liu
|
|
Status: Final
|
|
Category: Consensus / Network
|
|
Created: 2019-07-29
|
|
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:
|
|
|
|
Blossom
|
|
Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.
|
|
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 Blossom network upgrade.
|
|
|
|
|
|
Specification
|
|
=============
|
|
|
|
Blossom deployment
|
|
------------------
|
|
|
|
The primary sources of information about Blossom consensus protocol changes are:
|
|
|
|
- The Zcash Protocol Specification [#protocol]_.
|
|
- Shorter Block Target Spacing [#zip-0208]_.
|
|
- Network Upgrade 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 Blossom
|
|
upgrade:
|
|
|
|
CONSENSUS_BRANCH_ID
|
|
``0x2BB40E60``
|
|
|
|
|
|
ACTIVATION_HEIGHT (Blossom)
|
|
Testnet: 584000
|
|
|
|
Mainnet: 653600
|
|
|
|
|
|
Nodes compatible with Blossom activation on testnet MUST advertise protocol version
|
|
170008 or later. Nodes compatible with Blossom activation on mainnet MUST advertise
|
|
protocol version 170009 or later. The minimum peer protocol version that
|
|
Blossom-compatible nodes will connect to is 170002.
|
|
|
|
Pre-Blossom testnet nodes are defined as nodes on testnet advertising a protocol
|
|
version less than 170008. Pre-Blossom mainnet nodes are defined as nodes on mainnet
|
|
advertising a protocol version less than 170009.
|
|
|
|
For each network (testnet and mainnet), approximately three days (defined in terms of
|
|
block height) before the corresponding Blossom activation height, nodes compatible
|
|
with Blossom activation on that network will change the behaviour of their peer
|
|
connection logic in order to prefer pre-Blossom 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
|
|
[#zip-0201]_.
|
|
|
|
Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:
|
|
|
|
- reject new connections from pre-Blossom nodes on that network;
|
|
- disconnect any existing connections to pre-Blossom nodes on that network.
|
|
|
|
|
|
Backward compatibility
|
|
======================
|
|
|
|
Prior to the network upgrade activating on each network, Blossom and pre-Blossom
|
|
nodes are compatible and can connect to each other. However, Blossom nodes will
|
|
have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will
|
|
gradually be disconnected in the run up to activation.
|
|
|
|
Once the network upgrades, even though pre-Blossom nodes can still accept the
|
|
numerically larger protocol version used by Blossom as being valid, Blossom nodes
|
|
will always disconnect peers using lower protocol versions.
|
|
|
|
Unlike Overwinter and Sapling, Blossom does not define a new transaction version.
|
|
Blossom transactions are therefore in the same v4 format as Sapling transactions,
|
|
and use the same version group ID, i.e. 0x892F2085 as defined in [#protocol]_
|
|
section 7.1. This does not imply that transactions are valid across the Blossom
|
|
activation, since signatures MUST use the appropriate consensus branch ID.
|
|
|
|
|
|
Support in zcashd
|
|
=================
|
|
|
|
Support for Blossom on testnet is implemented in ``zcashd`` version 2.0.7, which
|
|
advertises protocol version 170008. Support for Blossom on mainnet is implemented
|
|
in ``zcashd`` version 2.1.0, which advertises protocol version 170009.
|
|
|
|
|
|
References
|
|
==========
|
|
|
|
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
|
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
|
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
|
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
|
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|