ZIP: 201 Title: Network Peer Management for Overwinter Owners: Daira Hopwood <[email protected]> Original-Authors: Simon Liu Status: Final Category: Network Created: 2018-01-15 License: MIT
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. [1]
The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in IP 200. [3]
The terms below are to be interpreted as follows:
- Overwinter
- Code-name for the first Zcash network upgrade, also known as Network Upgrade Zero.
This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Activation Mechanism [3].
Related to:
- Transaction Signature Verification for Overwinter [2].
- Version 3 Transaction Format for Overwinter [4].
- Transaction Expiry [5].
With scheduled network upgrades, at the activation height, nodes on each consensus branch should disconnect from nodes on other consensus branches and only accept new incoming connections from nodes on the same consensus branch.
When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.
Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake [8] involves "version" and "verack" messages being exchanged.:
L -> R: Send version message with the local peer's version R -> L: Send version message back R -> L: Send verack message R: Sets version to the minimum of the 2 versions L -> R: Send verack message after receiving version message from R L: Sets version to the minimum of the 2 versions
To send a version message, the node will invoke PushVersion():
void CNode::PushVersion() {
...
PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe, ...);
...
}
where PROTOCOL_VERSION is the highest protocol version supported by the node.
Currently, nodes will reject connections from peers with an advertised protocol version lower than the other node's minimum supported protocol version.
This value is defined as:
//! disconnect from peers older than this proto version static const int MIN_PEER_PROTO_VERSION = 170002;
With rejection implemented as:
if (pfrom->nVersion < MIN_PEER_PROTO_VERSION)
{
// disconnect from old peers running protocol version we don't support.
Activation of Overwinter will take place first on testnet, and if successful, followed by mainnet.
To prepare for testnet activation, Overwinter nodes will contain the following constants:
static const int PROTOCOL_VERSION = 170003; static const int MIN_PEER_PROTO_VERSION = 170002;
Nodes running protocol version 170003 have a testnet activation height set, but do not have a mainnet activation height set.
On testnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170002.
These constants allow pre-Overwinter nodes that support protocol version 170002, and Overwinter nodes (which support both protocol versions 170002 and 170003 before Overwinter activation) to remain connected until the activation.
To prepare for mainnet activation, Overwinter nodes will contain the following constants:
static const int PROTOCOL_VERSION = 170005; static const int MIN_PEER_PROTO_VERSION = 170002;
On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the NODE_BLOOM service bit defined in [6].)
These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.
As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:
- reject new connections from pre-Overwinter nodes;
- disconnect any existing connections to pre-Overwinter nodes.
Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.
This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. [9]
To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.
Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:
if (nInbound >= nMaxInbound)
{
if (!AttemptToEvictConnection(whitelisted)) {
// No connection to evict, disconnect the new connection
LogPrint("net", "failed to find an eviction candidate - connection dropped (full)\n");
CloseSocket(hSocket);
return;
}
}
We update this process by adding behaviour so that the set of eviction candidates will prefer pre-Overwinter nodes, when the chain tip is in a period N blocks before the activation block height, where N is defined as:
/** 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 eviction candidates can be modified as so:
static bool AttemptToEvictConnection(bool fPreferNewConnection) {
...
// Protect connections with certain characteristics
...
// Check version of eviction candidates...
// If we are connected to any pre-Overwinter nodes, keep them in the eviction set and remove any Overwinter nodes
// If we are only connected to Overwinter nodes, continue with existing behaviour.
if (nActivationHeight > 0 &&
height < nActivationHeight &&
height >= nActivationHeight - NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD)
{
// Find any nodes which don't support Overwinter protocol version
BOOST_FOREACH(const CNodeRef &node, vEvictionCandidates) {
if (node->nVersion < params.vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion) {
vTmpEvictionCandidates.push_back(node);
}
}
// Prioritize these nodes by replacing eviction set with them
if (vTmpEvictionCandidates.size() > 0) {
vEvictionCandidates = vTmpEvictionCandidates;
}
}
The existing method of disconnecting a candidate remains:
vEvictionCandidates[0]->fDisconnect = true;
The existing eviction process will classify and divide eviction candidates into buckets called netgroups. If a netgroup only has one peer, it will not be evicted. This means at least one pre-Overwinter node will remain connected upto the activation block height, barring any network issues or a high ban score.
At the activation block height, an Overwinter node may still remain connected to pre-Overwinter nodes. Currently, when connecting, a node can only perform the networking handshake once, where it sends the version message before any other messages are processed. To disconnect existing pre-Overwinter connections, ProcessMessage is modified so that once Overwinter activates, if necessary, the protocol version of an existing peer is validated when inbound messages arrive.
Example code:
bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv, int64_t nTimeReceived)
...
else if (pfrom->nVersion == 0)
{
// Must have a version message before anything else
Misbehaving(pfrom->GetId(), 1);
return false;
}
else if (strCommand == "verack")
{
...
}
// Disconnect existing peer connection when:
// 1. The version message has been received
// 2. Overwinter is active
// 3. Peer version is pre-Overwinter
else if (NetworkUpgradeActive(GetHeight(), chainparams.GetConsensus(), Consensus::UPGRADE_OVERWINTER)
&& (pfrom->nVersion < chainparams.GetConsensus().vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion))
{
LogPrintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->id, pfrom->nVersion);
pfrom->PushMessage("reject", strCommand, REJECT_OBSOLETE,
strprintf("Version must be %d or greater",
chainparams.GetConsensus().vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion));
pfrom->fDisconnect = true;
return false;
}
The Overwinter network upgrade defines the following network upgrade constants [3]:
- CONSENSUS_BRANCH_ID
0x5ba81b19- ACTIVATION_HEIGHT
Testnet: 207500
Mainnet: 347500
The following ZIPs are deployed by Overwinter:
Prior to the network upgrade activating, Overwinter and pre-Overwinter nodes are compatible and can connect to each other. However, Overwinter nodes will have a preference for connecting to other Overwinter nodes, so pre-Overwinter nodes will gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Overwinter nodes can still accept the numerically larger protocol version used by Overwinter as being valid, Overwinter nodes will always disconnect peers using lower protocol versions.
| [1] | Key words for use in RFCs to Indicate Requirement Levels |
| [2] | (1, 2) ZIP 143: Transaction Signature Verification for Overwinter |
| [3] | (1, 2, 3, 4) ZIP 200: Network Upgrade Activation Mechanism |
| [4] | (1, 2) ZIP 202: Version 3 Transaction Format for Overwinter |
| [5] | (1, 2) ZIP 203: Transaction Expiry |
| [6] | BIP 111: NODE_BLOOM service bit |
| [7] | https://en.bitcoin.it/wiki/Protocol_documentation#version |
| [8] | https://en.bitcoin.it/wiki/Version_Handshake |
| [9] | Eclipse Attacks on Bitcoin’s Peer-to-Peer Network |
| [10] | Partition nodes with old protocol version from network in advance of hard fork |