mirror of https://github.com/zcash/zips.git
Draft of network upgrade activation logic ZIP
This commit is contained in:
parent
d4e2da7dfc
commit
c904f2ebae
|
@ -0,0 +1,179 @@
|
|||
::
|
||||
|
||||
ZIP: ???
|
||||
Title: Network Upgrade Activation Mechanism
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Comments-Summary: No comments yet.
|
||||
Category: Process
|
||||
Created: 2018-01-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.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines an activation mechanism for coordinating upgrades of the Zcash network, in order to
|
||||
remove ambiguity about when network upgrades will activate, provide defined periods in which users should
|
||||
upgrade their local software, and minimize the risks to both the upgrading network and those users opting out
|
||||
of the changes.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Zcash is a *consensual currency*: nobody is ever going to force someone to use a specific version or a
|
||||
specific branch of Zcash. [#consensual-currency]_ As such, different sub-communities will always have the
|
||||
freedom to choose different variants or branches which offer different design trade-offs.
|
||||
|
||||
The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version
|
||||
to automatically shut down 16 weeks after that version was released. This was implemented for several reasons
|
||||
[#release-lifecycle]_:
|
||||
|
||||
- It gives the same systemic advantage of removing old software as auto-upgrade behavior.
|
||||
|
||||
- It requires users to individually choose one of the following options:
|
||||
|
||||
- Upgrade to a more recent software release from the main network.
|
||||
|
||||
- Upgrade to an alternative release.
|
||||
|
||||
- Ignore the "deprecation" and keep running the older software.
|
||||
|
||||
Developers can rely on this cadence for coordinating network upgrades. Once the last pre-upgrade software
|
||||
version has been deprecated, they can reasonably assume that all node operators on the network either support
|
||||
the upgraded rules, or have explicitly chosen not to follow them.
|
||||
|
||||
However, this behaviour is not sufficient for performing network upgrades. A globally-understood on-chain
|
||||
activation mechanism is necessary so that nodes can unambiguously know at what point the changes from an
|
||||
upgrade come into effect (and can enforce consensus rule changes, for example).
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
The following constants are defined for every network upgrade:
|
||||
|
||||
BRANCH_ID
|
||||
A globally-unique 32-bit identifier.
|
||||
|
||||
ACTIVATION_HEIGHT
|
||||
The block height at which the network upgrade rules will come into effect, and be enforced as part of the
|
||||
blockchain consensus.
|
||||
|
||||
For removal of ambiguity, the block at height ``ACTIVATION_HEIGHT - 1`` is subject to the pre-upgrade
|
||||
consensus rules, and would be the last common block in the event of a persistent pre-upgrade branch.
|
||||
|
||||
It MUST be greater than the value of ``DEPRECATION_HEIGHT`` in the last software version that will not
|
||||
contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after
|
||||
the first software version containing support for the network upgrade is released.
|
||||
|
||||
Activation mechanism
|
||||
--------------------
|
||||
|
||||
There MUST only be one network upgrade at a time in progress. Concretely, this means that the Zcash blockchain
|
||||
is broken into "epochs" of block height intervals ``[ACTIVATION_HEIGHT_{N-1}, ACTIVATION_HEIGHT_N)`` (ie.
|
||||
including ``ACTIVATION_HEIGHT_{N-1}`` and exluding ``ACTIVATION_HEIGHT_N``), on which consensus rule sets are
|
||||
defined.
|
||||
|
||||
Consensus rules themselves (and any network behavior or surrounding code that depends on them) MUST be gated
|
||||
by block height checks. For example:
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
if (chainActive.Tip()->nHeight >= OVERWINTER.ACTIVATION_HEIGHT) {
|
||||
// Overwinter-specific logic
|
||||
} else {
|
||||
// Pre-Overwinter logic
|
||||
}
|
||||
|
||||
// ...
|
||||
|
||||
if (pindex->nHeight >= OVERWINTER.ACTIVATION_HEIGHT) {
|
||||
// Overwinter consensus rules applied to block
|
||||
} else {
|
||||
// Pre-Overwinter consensus rules applied to block
|
||||
}
|
||||
|
||||
|
||||
Block parsing
|
||||
`````````````
|
||||
Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be
|
||||
parsed under the consensus rules corresponding to their height.
|
||||
|
||||
Incoming blocks with unknown heights (because at least one block in their parent chain is unknown) MUST NOT be
|
||||
considered valid, but MAY be cached for future consideration after all their parents have been received.
|
||||
|
||||
Memory pool
|
||||
-----------
|
||||
|
||||
While the current chain tip height is below ``ACTIVATION_HEIGHT``, nodes SHOULD NOT accept transactions that
|
||||
will only be valid on the post-upgrade chain.
|
||||
|
||||
When the current chain tip height reaches ``ACTIVATION_HEIGHT``, the node's local transaction memory pool
|
||||
SHOULD be cleared.
|
||||
|
||||
Two-way replay protection
|
||||
-------------------------
|
||||
|
||||
Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the
|
||||
MSB of the transaction version is set to 1. From the perspective of old nodes, the transactions will have a
|
||||
negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes
|
||||
old transactions invalid on the Overwinter branch.
|
||||
|
||||
After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures
|
||||
committing to a specific ``BRANCH_ID``. [#zip-0143]_
|
||||
|
||||
Wipe-out protection
|
||||
-------------------
|
||||
|
||||
Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from
|
||||
``ACTIVATION_HEIGHT``. The chain from that height will not reorg to a pre-upgrade branch if any block would
|
||||
violate the new consensus rules (such as including any old-format transaction).
|
||||
|
||||
[TODO: if the non-upgraded chain only had empty blocks, technically that would be valid under new rules, so
|
||||
could cause a wipe-out. Fixing this would require at least changing the block version, in which case blocks
|
||||
may as well commit to a ``BRANCH_ID``.]
|
||||
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
TBC
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This proposal will be deployed with the Overwinter network upgrade.
|
||||
|
||||
|
||||
Backward compatibility
|
||||
======================
|
||||
|
||||
This proposal intentionally creates what is known as a "bilateral hard fork". Use of this mechanism requires
|
||||
that all network participants upgrade their software to a compatible version within the upgrade window. Older
|
||||
software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
TBC
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#consensual-currency] https://z.cash/blog/consensual-currency.html
|
||||
.. [#release-lifecycle]
|
||||
- https://z.cash/blog/release-cycle-and-lifetimes.html
|
||||
- https://z.cash/blog/release-cycle-update.html
|
||||
.. [#roadmap-2018] https://z.cash/blog/roadmap-update-2017-12.html
|
||||
.. [#zip-0143] Transaction Signature Verification for Overwinter
|
Loading…
Reference in New Issue