mirror of https://github.com/zcash/zips.git
Merge pull request #258 from daira/zip208-updates
[Blossom] Add ZIP 206 and update ZIP 208. Also clean up ZIP metadata.
This commit is contained in:
Daira Hopwood
GitHub
commit
562c78f29b
47
zip-0000.rst
47
zip-0000.rst
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
ZIP: 0
|
||||
Title: ZIP Process
|
||||
Owners: Daira Hopwood
|
||||
Josh Cincinnati
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Josh Cincinnati <josh@zfnd.org>
|
||||
Status: Active
|
||||
Category: Process
|
||||
Created: 2019-02-16
|
||||
|
|
@ -31,9 +31,9 @@ technical specification of the feature and a rationale for the feature.
|
|||
|
||||
We intend ZIPs to be the primary mechanism for proposing new features,
|
||||
for collecting community input on an issue, and for documenting the
|
||||
design decisions that have gone into Zcash. The author(s) of the ZIP
|
||||
(known as Owners in this document) are responsible for building
|
||||
consensus within the community and documenting dissenting opinions.
|
||||
design decisions that have gone into Zcash. The Owner(s) of the ZIP
|
||||
(usually the authors(s)) are responsible for building consensus within
|
||||
the community and documenting dissenting opinions.
|
||||
|
||||
Because the ZIPs are maintained as text files in a versioned repository,
|
||||
their revision history is the historical record of the feature proposal.
|
||||
|
|
@ -50,18 +50,17 @@ The ZIP process begins with a new idea for Zcash. Each potential ZIP
|
|||
must have a Owner -- someone who writes the ZIP using the style and
|
||||
format described below, shepherds the discussions in the appropriate
|
||||
forums, and attempts to build community consensus around the idea. The
|
||||
ZIP Owner (a.k.a. author) should first attempt to ascertain whether
|
||||
the idea is ZIP-able. Small enhancements or patches to a particular
|
||||
piece of software often don't require standardisation between multiple
|
||||
projects; these don't need a ZIP and should be injected into the
|
||||
relevant project-specific development workflow with a patch submission
|
||||
to the applicable issue tracker. Additionally, many ideas have been
|
||||
brought forward for changing Zcash that have been rejected for various
|
||||
reasons. The first step should be to search past discussions to see if
|
||||
an idea has been considered before, and if so, what issues arose in its
|
||||
progression. After investigating past work, the best way to proceed is
|
||||
by posting about the new idea to the `Zcash Community Forum
|
||||
<https://forum.zcashcommunity.com/>`__.
|
||||
ZIP Owner should first attempt to ascertain whether the idea is ZIP-able.
|
||||
Small enhancements or patches to a particular piece of software often
|
||||
don't require standardisation between multiple projects; these don't
|
||||
need a ZIP and should be injected into the relevant project-specific
|
||||
development workflow with a patch submission to the applicable issue
|
||||
tracker. Additionally, many ideas have been brought forward for changing
|
||||
Zcash that have been rejected for various reasons. The first step should
|
||||
be to search past discussions to see if an idea has been considered
|
||||
before, and if so, what issues arose in its progression. After
|
||||
investigating past work, the best way to proceed is by posting about the
|
||||
new idea to the `Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
|
||||
|
||||
Vetting an idea publicly before going as far as writing a ZIP is meant
|
||||
to save both the potential Owner and the wider community time. Asking
|
||||
|
|
@ -130,6 +129,10 @@ Editors. If the original Owner doesn't respond to email in a timely
|
|||
manner, the ZIP Editors will make a unilateral decision (it's not like
|
||||
such decisions can't be reversed :).
|
||||
|
||||
If an author of a ZIP is no longer an Owner, an Original-Authors field
|
||||
SHOULD be added to the ZIP metadata indicating the original authorship,
|
||||
unless the original author(s) request otherwise.
|
||||
|
||||
|
||||
ZIP Editors
|
||||
-----------
|
||||
|
|
@ -278,9 +281,9 @@ Each ZIP SHOULD have the following parts:
|
|||
* Reference implementation -- Literal code implementing the ZIP's
|
||||
specification, and/or a link to the reference implementation of
|
||||
the ZIP's specification. The reference implementation must be
|
||||
completed before any ZIP is given status “Implemented”, but it
|
||||
generally need not be completed before the ZIP is accepted into
|
||||
Proposed.
|
||||
completed before any ZIP is given status “Implemented” or “Final”,
|
||||
but it generally need not be completed before the ZIP is accepted
|
||||
into “Proposed”.
|
||||
|
||||
ZIP header preamble
|
||||
-------------------
|
||||
|
|
@ -298,6 +301,8 @@ header fields are REQUIRED::
|
|||
|
||||
The following additional header fields are OPTIONAL::
|
||||
|
||||
Credits:
|
||||
Original-Authors:
|
||||
Discussions-To:
|
||||
Network Upgrade:
|
||||
Obsoleted by:
|
||||
|
|
@ -563,7 +568,7 @@ See Also
|
|||
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
|
||||
* `RFC 7282: On Consensus and Humming in the
|
||||
IETF <https://tools.ietf.org/html/rfc7282>`__
|
||||
* `Zcash Network Upgrade Pipeline <https://z.cash/blog/the-zcash-network-upgrade-pipeline/>`__
|
||||
* `Zcash Network Upgrade Pipeline <https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/>`__
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -2,11 +2,12 @@
|
|||
|
||||
ZIP: 32
|
||||
Title: Shielded Hierarchical Deterministic Wallets
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Daira Hopwood <daira@z.cash>
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Pieter Wuille <pieter.wuille@gmail.com>
|
||||
Marek Palatinus <slush@satoshilabs.com>
|
||||
Pavol Rusnak <stick@satoshilabs.com>
|
||||
Status: Final
|
||||
Category: Standards Track
|
||||
Created: 2018-05-22
|
||||
License: MIT
|
||||
|
|
|
|||
|
|
@ -2,11 +2,12 @@
|
|||
|
||||
ZIP: 143
|
||||
Title: Transaction Signature Verification for Overwinter
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Daira Hopwood <daira@z.cash>
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Johnson Lau <jl2012@xbt.hk>
|
||||
Pieter Wuille <pieter.wuille@gmail.com>
|
||||
Bitcoin-ABC
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2017-12-27
|
||||
License: MIT
|
||||
|
|
|
|||
|
|
@ -2,7 +2,8 @@
|
|||
|
||||
ZIP: 200
|
||||
Title: Network Upgrade Mechanism
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-08
|
||||
License: MIT
|
||||
|
|
@ -219,10 +220,10 @@ References
|
|||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#consensual-currency] https://z.cash/blog/consensual-currency.html
|
||||
.. [#consensual-currency] https://electriccoin.co/blog/consensual-currency/
|
||||
.. [#release-lifecycle]
|
||||
- https://z.cash/blog/release-cycle-and-lifetimes.html
|
||||
- https://z.cash/blog/release-cycle-update.html
|
||||
- https://electriccoin.co/blog/release-cycle-and-lifetimes/
|
||||
- https://electriccoin.co/blog/release-cycle-update/
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
|
||||
|
|
|
|||
|
|
@ -2,11 +2,14 @@
|
|||
|
||||
ZIP: 201
|
||||
Title: Network Peer Management for Overwinter
|
||||
Author: Simon Liu <simon@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu <simon@bitcartel.com>
|
||||
Status: Final
|
||||
Category: Network
|
||||
Created: 2018-01-15
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
|
|
|
|||
|
|
@ -2,11 +2,14 @@
|
|||
|
||||
ZIP: 202
|
||||
Title: Version 3 Transaction Format for Overwinter
|
||||
Author: Simon Liu <simon@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu <simon@bitcartel.com>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-10
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
|
||||
ZIP: 203
|
||||
Title: Transaction Expiry
|
||||
Author: Jay Graber <jay@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Jay Graber
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-09
|
||||
License: MIT
|
||||
|
|
|
|||
|
|
@ -2,12 +2,14 @@
|
|||
|
||||
ZIP: 205
|
||||
Title: Deployment of the Sapling Network Upgrade
|
||||
Author: Daira Hopwood <daira@z.cash>
|
||||
Credits: Simon Liu <simon@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu <simon@bitcartel.com>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-10-08
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,122 @@
|
|||
::
|
||||
|
||||
ZIP: 206
|
||||
Title: Deployment of the Blossom Network Upgrade
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu <simon@bitcartel.com>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
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 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 Blossom
|
||||
upgrade:
|
||||
|
||||
BRANCH_ID
|
||||
``0xXXXXXXXX``
|
||||
|
||||
|
||||
ACTIVATION_HEIGHT (Blossom)
|
||||
Testnet: XXXXXX
|
||||
|
||||
Mainnet: XXXXXX
|
||||
|
||||
|
||||
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 will be 170007.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Support in zcashd
|
||||
=================
|
||||
|
||||
Support for Blossom on testnet will be implemented in ``zcashd`` version 2.0.7, which
|
||||
will advertise protocol version 170008. Support for Blossom on mainnet will be
|
||||
implemented in ``zcashd`` version 2.1.0, which will advertise protocol version 170009.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <https://github.com/zcash/zips/blob/master/zip-0208.rst>`_
|
||||
10
zip-0207.rst
10
zip-0207.rst
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
ZIP: 207
|
||||
Title: Split Founders' Reward
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Category: Consensus
|
||||
Status: Withdrawn
|
||||
Created: 2019-01-04
|
||||
|
|
@ -19,7 +19,7 @@ RFC 2119. [#RFC2119]_
|
|||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines how the consensus rules are altered to split the original Founders' Reward across
|
||||
This Withdrawn proposal would have altered consensus rules to split the original Founders' Reward across
|
||||
several recipient addresses per block instead of one, corresponding to the several funding streams contained
|
||||
within it.
|
||||
|
||||
|
|
@ -446,7 +446,7 @@ Example implementation
|
|||
Deployment
|
||||
==========
|
||||
|
||||
This proposal will be deployed with the Blossom network upgrade. [#zip-0XXX]_
|
||||
This proposal was originally intended to be deployed with the Blossom network upgrade. [#zip-0206]_
|
||||
|
||||
|
||||
Backward compatibility
|
||||
|
|
@ -486,8 +486,8 @@ References
|
|||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#block-subsidy] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
|
||||
.. [#continued-funding] `Continued Funding and Transparency <https://z.cash/blog/continued-funding-and-transparency>`_
|
||||
.. [#continued-funding] `Continued Funding and Transparency <https://electriccoin.co/blog/continued-funding-and-transparency/>`_
|
||||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <https://github.com/zcash/zips/blob/master/zip-0208.rst>`_
|
||||
.. [#original-fr-consensus-rule] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
|
||||
.. [#protocol-constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
|
||||
.. [#zip-0XXX] `ZIP XXX: Blossom Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0XXX.rst>`_
|
||||
.. [#zip-0206] `ZIP 206: Blossom Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0206.rst>`_
|
||||
|
|
|
|||
206
zip-0208.rst
206
zip-0208.rst
|
|
@ -2,10 +2,12 @@
|
|||
|
||||
ZIP: 208
|
||||
Title: Shorter Block Target Spacing
|
||||
Author: Simon Liu <simon@z.cash>
|
||||
Daira Hopwood <daira@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Daira Hopwood <daira@electriccoin.co>
|
||||
Simon Liu <simon@bitcartel.com>
|
||||
Status: Implemented
|
||||
Category: Consensus
|
||||
Created: 2018-01-10
|
||||
Created: 2019-01-10
|
||||
License: MIT
|
||||
|
||||
|
||||
|
|
@ -52,6 +54,7 @@ increases more slowly than the decrease in block time, and so, up to a point,
|
|||
decreasing the block target spacing can provide a better trade-off between
|
||||
latency and security. This argument assumes that the verification and
|
||||
propagation time for a block remain small compared to the block target spacing.
|
||||
See [#slowfastblocks]_ for further analysis in various attack models.
|
||||
|
||||
|
||||
Specification
|
||||
|
|
@ -60,6 +63,9 @@ Specification
|
|||
The changes described in this section are to be made in [#latest-protocol]_,
|
||||
relative to the pre-Blossom specification in [#preblossom-protocol].
|
||||
|
||||
Consensus changes
|
||||
-----------------
|
||||
|
||||
Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval,
|
||||
and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain
|
||||
their values from [#preblossom-protocol]_ of 840000 (blocks) and 150 (seconds)
|
||||
|
|
@ -70,14 +76,12 @@ to the list of integer constants.
|
|||
|
||||
In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.
|
||||
|
||||
TODO: check that PostBlossomPoWTargetSpacing is reasonable.
|
||||
|
||||
For a given network (production or test), define BlossomActivationHeight as the height
|
||||
at which Blossom activates on that network, as specified in [#zip-0206]_.
|
||||
For a given network (production or test), define BlossomActivationHeight as the
|
||||
height at which Blossom activates on that network, as specified in [#zip-0206]_.
|
||||
|
||||
In section 7.6.3 (Difficulty adjustment), make the following changes:
|
||||
|
||||
Define IsBlossomActivated(height) to return true if height ≥ BlossomActivationHeight,
|
||||
Define IsBlossomActivated(*height*) to return true if *height* ≥ BlossomActivationHeight,
|
||||
otherwise false.
|
||||
|
||||
This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.
|
||||
|
|
@ -87,61 +91,61 @@ Define:
|
|||
- BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing
|
||||
- PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).
|
||||
|
||||
In the same section, redefine PoWTargetSpacing as a function taking a height parameter,
|
||||
as follows:
|
||||
In the same section, redefine PoWTargetSpacing as a function taking a *height*
|
||||
parameter, as follows:
|
||||
|
||||
- PoWTargetSpacing(height) :=
|
||||
- PoWTargetSpacing(*height*) :=
|
||||
|
||||
- PreBlossomPoWTargetSpacing, if not IsBlossomActivated(height)
|
||||
- PreBlossomPoWTargetSpacing, if not IsBlossomActivated(*height*)
|
||||
- PostBlossomPoWTargetSpacing, otherwise.
|
||||
|
||||
Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan,
|
||||
ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
|
||||
|
||||
- add a height parameter to each of these functions that does not already
|
||||
- add a *height* parameter to each of these functions that does not already
|
||||
have one;
|
||||
- ensure that each reference to any of these values, or to PoWTargetSpacing,
|
||||
are replaced with a function call passing the height parameter.
|
||||
are replaced with a function call passing the *height* parameter.
|
||||
|
||||
In [#latest-protocol]_ section 7.7 (Calculation of Block Subsidy and Founders’
|
||||
Reward), redefine the Halving and BlockSubsidy functions as follows:
|
||||
|
||||
- Halving(height) :=
|
||||
- Halving(*height*) :=
|
||||
|
||||
- floor((height - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(height)
|
||||
- floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (height - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise
|
||||
- floor((*height* - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(*height*)
|
||||
- floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (*height* - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise
|
||||
|
||||
- BlockSubsidy(height) :=
|
||||
- BlockSubsidy(*height*) :=
|
||||
|
||||
- SlowStartRate · height, if height < SlowStartInterval / 2
|
||||
- SlowStartRate · (height + 1), if SlowStartInterval / 2 ≤ height and height < SlowStartInterval
|
||||
- floor(MaxBlockSubsidy / 2\ :sup:`Halving(height)`\ ), if SlowStartInterval ≤ height and not IsBlossomActivated(height)
|
||||
- floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(height)`\ )), otherwise
|
||||
- SlowStartRate · *height*, if *height* < SlowStartInterval / 2
|
||||
- SlowStartRate · (*height* + 1), if SlowStartInterval / 2 ≤ *height* and *height* < SlowStartInterval
|
||||
- floor(MaxBlockSubsidy / 2\ :sup:`Halving(*height*)`\ ), if SlowStartInterval ≤ *height* and not IsBlossomActivated(*height*)
|
||||
- floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )), otherwise
|
||||
|
||||
TODO: ideally, BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing should be chosen so that:
|
||||
|
||||
- (BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (height - BlossomActivationHeight) / PostBlossomHalvingInterval)
|
||||
is exactly 1 for some integer height.
|
||||
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(height)`\ )
|
||||
- (BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (*height* - BlossomActivationHeight) / PostBlossomHalvingInterval)
|
||||
is exactly 1 for some integer *height*.
|
||||
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )
|
||||
is an integer for the next few periods.
|
||||
|
||||
In [#latest-protocol]_ section 7.8 (Payment of Founders’ Reward), define:
|
||||
|
||||
- FounderAddressAdjustedHeight(height) :=
|
||||
- FounderAddressAdjustedHeight(*height*) :=
|
||||
|
||||
- height, if not IsBlossomActivated(height)
|
||||
- BlossomActivationHeight + floor((height - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise
|
||||
- *height*, if not IsBlossomActivated(*height*)
|
||||
- BlossomActivationHeight + floor((*height* - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise
|
||||
|
||||
and in the definition of FounderAddressIndex, replace the use of height with FounderAddressAdjustedHeight(height).
|
||||
and in the definition of FounderAddressIndex, replace the use of *height* with FounderAddressAdjustedHeight(*height*).
|
||||
|
||||
Also define:
|
||||
|
||||
- FoundersRewardLastBlockHeight := max({ height ⦂ N | Halving(height) < 1 })
|
||||
- FoundersRewardLastBlockHeight := max({ *height* ⦂ N | Halving(*height*) < 1 })
|
||||
|
||||
Replace the first note in that section with:
|
||||
|
||||
- No Founders’ Reward is required to be paid for height > FoundersRewardLastBlockHeight
|
||||
(i.e. after the first halving), or for height = 0 (i.e. the genesis block).
|
||||
- No Founders’ Reward is required to be paid for *height* > FoundersRewardLastBlockHeight
|
||||
(i.e. after the first halving), or for *height* = 0 (i.e. the genesis block).
|
||||
|
||||
and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with
|
||||
FoundersRewardLastBlockHeight.
|
||||
|
|
@ -161,6 +165,33 @@ spacing to adjust to the new target, at the normal rate for a difficulty
|
|||
adjustment. The results of simulations are consistent with this expected
|
||||
behaviour.
|
||||
|
||||
Note that the change in AveragingWindowTimespan(height) takes effect
|
||||
immediately when calculating the target difficulty starting from the block at
|
||||
the Blossom activation height, even though the difficulty of the preceding
|
||||
PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target
|
||||
spacing. Therefore it is likely that the difficulty adjustment for the first
|
||||
few blocks after activation will be limited by PoWMaxAdjustDown. This is not
|
||||
anticipated to cause any problem.
|
||||
|
||||
|
||||
Minimum difficulty blocks on the test network
|
||||
'''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
On the test network from block height 299188 onward, the difficulty adjustment
|
||||
algorithm allows minimum-difficulty blocks, as described in [#zip-0205]_, when
|
||||
the block time exceeds a given threshold. This specification changes this
|
||||
threshold to be proportional to the block target spacing.
|
||||
|
||||
That is, if the block time of a block at height *height* ≥ 299188 is at least
|
||||
6 · PoWTargetSpacing(*height*) seconds 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 [#latest-protocol]_ section 5.3).
|
||||
|
||||
As before, the ``nBits`` field of a minimum-difficulty block is still computed
|
||||
according to the original difficulty adjustment algorithm, and only this field
|
||||
is used for the purpose of computing the MeanTarget values from which subsequent
|
||||
difficulty changes are calculated.
|
||||
|
||||
|
||||
Non-consensus node behaviour
|
||||
----------------------------
|
||||
|
|
@ -187,7 +218,111 @@ This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after
|
|||
Blossom activation, to maintain the approximate expiry time of 50 minutes.
|
||||
|
||||
|
||||
TODO: check for any other number-of-block constants.
|
||||
Fingerprinting mitigation
|
||||
'''''''''''''''''''''''''
|
||||
|
||||
A "fingerprinting attack" is a network analysis technique in which nodes are
|
||||
identified across network sessions, for example using information about which
|
||||
blocks they request or send.
|
||||
|
||||
``zcashd`` inherits from Bitcoin Core the following behaviour, described in a
|
||||
comment in ``main.cpp``, intended as a fingerprinting mitigation::
|
||||
|
||||
// To prevent fingerprinting attacks, only send blocks outside of the active
|
||||
// chain if they are valid, and no more than a month older (both in time, and in
|
||||
// best equivalent proof of work) than the best header chain we know about.
|
||||
|
||||
We make no assertion about the significance of fingerprinting for Zcash,
|
||||
and (despite the word "prevent" in the above comment) no claim about the
|
||||
effectiveness of this mitigation.
|
||||
|
||||
In any case, to estimate the "best equivalent proof of work" of a given block
|
||||
chain (measured in units of time), we take the total work of the chain as
|
||||
defined in [#latest-protocol]_ section 7.6.5, divide by the work of the
|
||||
block at the active tip, and multiply by the target block spacing of that block.
|
||||
|
||||
It is not a requirement of the Zcash protocol that this fingerprinting
|
||||
mitigation is used; however, if it is used, then it SHOULD use the target
|
||||
block spacing at the same block height that is used for the current work
|
||||
estimate.
|
||||
|
||||
|
||||
Monitoring for quicker- or slower-than-expected blocks
|
||||
''''''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
`zcashd` previously did this monitoring every 150 seconds; it is now done
|
||||
every 60 seconds.
|
||||
|
||||
|
||||
Block timeout
|
||||
'''''''''''''
|
||||
|
||||
The timeout for a requested block is calculated as the target block time,
|
||||
multiplied by 2 + (the number of queued validated headers)/2.
|
||||
|
||||
|
||||
Latency optimization when requesting blocks
|
||||
'''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
When ``zcashd`` sees an announced block that chains from headers that it does
|
||||
not already have, it will first ask for the headers, and then the block itself.
|
||||
A latency optimization is performed only if the chain is "nearly synced"::
|
||||
|
||||
// First request the headers preceding the announced block. In the normal fully-synced
|
||||
// case where a new block is announced that succeeds the current tip (no reorganization),
|
||||
// there are no such headers.
|
||||
// Secondly, and only when we are close to being synced, we request the announced block directly,
|
||||
// to avoid an extra round-trip. Note that we must *first* ask for the headers, so by the
|
||||
// time the block arrives, the header chain leading up to it is already validated. Not
|
||||
// doing this will result in the received block being rejected as an orphan in case it is
|
||||
// not a direct successor.
|
||||
|
||||
The heuristic for "nearly synced" is that the timestamp of the block at the active tip
|
||||
is no more than 20 block times before the current "adjusted time". In ``zcashd`` this
|
||||
calculation uses the block target spacing as of the best known header. Around Blossom
|
||||
activation when the block target spacing changes, this could cause the heuristic to be
|
||||
based on the pre-Blossom block target spacing until the node has synced headers past the
|
||||
activation block, but this is not anticipated to cause any problem.
|
||||
|
||||
|
||||
Response to getblocks message when pruning
|
||||
''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
If pruning is enabled, when ``zcashd`` responds to an "getblocks" peer-to-peer message,
|
||||
it will only include blocks that it has on disk, and is likely to still have on disk
|
||||
an hour after responding to the message::
|
||||
|
||||
// If pruning, don't inv blocks unless we have on disk and are likely to still have
|
||||
// for some reasonable time window (1 hour) that block relay might require.
|
||||
|
||||
For each block, when estimating whether it will still be on disk after an hour, we
|
||||
take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected
|
||||
in one hour at the target block spacing as of that block. Around Blossom activation,
|
||||
this might underestimate the number of blocks in the next hour, but given the value
|
||||
of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.
|
||||
|
||||
|
||||
Other block-related constants
|
||||
'''''''''''''''''''''''''''''
|
||||
|
||||
The following constants, measured in number of blocks, were reviewed and a
|
||||
decision was made not to change them::
|
||||
|
||||
/** The number of blocks within expiry height when a tx is considered to be expiring soon */
|
||||
TX_EXPIRING_SOON_THRESHOLD = 3
|
||||
|
||||
/** Maximum reorg length we will accept before we shut down and alert the user. */
|
||||
MAX_REORG_LENGTH = COINBASE_MATURITY - 1;
|
||||
|
||||
static const int COINBASE_MATURITY = 100;
|
||||
|
||||
/** Number of blocks that can be requested at any given time from a single peer. */
|
||||
static const int MAX_BLOCKS_IN_TRANSIT_PER_PEER = 16;
|
||||
|
||||
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;
|
||||
|
||||
/** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */
|
||||
static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
|
||||
|
||||
|
||||
Deployment
|
||||
|
|
@ -209,7 +344,7 @@ pre-upgrade branch that persists.
|
|||
Reference Implementation
|
||||
========================
|
||||
|
||||
https://github.com/zcash/zcash/pull/xxxx
|
||||
https://github.com/zcash/zcash/pull/4025
|
||||
|
||||
|
||||
References
|
||||
|
|
@ -219,4 +354,7 @@ References
|
|||
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) [Overwinter+Sapling] <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.rst>`_
|
||||
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0206.rst>`_
|
||||
.. [#slowfastblocks] On Slow and Fast Block Times <https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/>_
|
||||
|
||||
|
|
|
|||
|
|
@ -2,12 +2,13 @@
|
|||
|
||||
ZIP: 209
|
||||
Title: Prohibit Negative Shielded Value Pool
|
||||
Author: Sean Bowe <sean@z.cash>
|
||||
Category: Consensus
|
||||
Owners: Sean Bowe <sean@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-02-25
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
ZIP: 210
|
||||
Title: Sapling Anchor Deduplication within Transactions
|
||||
Owners: Jack Grigg <jack@z.cash>
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
Created: 2019-03-27
|
||||
|
|
|
|||
|
|
@ -2,9 +2,10 @@
|
|||
|
||||
ZIP: 243
|
||||
Title: Transaction Signature Verification for Sapling
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Daira Hopwood <daira@z.cash>
|
||||
Simon Liu <simon@z.cash> (Update 2018-10-15)
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu <simon@bitcartel.com> (Update 2018-10-15)
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-04-10
|
||||
License: MIT
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
ZIP: 308
|
||||
Title: Sprout to Sapling Migration
|
||||
Author: Daira Hopwood <daira@z.cash>
|
||||
Eirik Ogilvie-Wigley <eirik@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Eirik Ogilvie-Wigley <eirik@electriccoin.co>
|
||||
Status: Final
|
||||
Category: RPC/Wallet
|
||||
Created: 2018-11-27
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
Credits: First Credited <optional email>
|
||||
...
|
||||
Status: Draft
|
||||
Category: {Consensus | Standards Track | Informational | Process}
|
||||
Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
|
||||
Created: yyyy-mm-dd
|
||||
License: {usually MIT}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue