mirror of https://github.com/zcash/zips.git
The first rule of Fork Club is: We don't talk about "forks".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
108fa4daa0
commit
5cac8e9b6a
|
@ -6023,11 +6023,7 @@ These parameters were obtained by a multi-party computation described in \todo{}
|
|||
|
||||
\sapling{
|
||||
\introsection
|
||||
\section{\Sapling Transition} \label{saplingtransition}
|
||||
|
||||
\todo{Separate this out into a ZIP that describes the bilateral
|
||||
hard fork strategy generally, and then describe the \Sapling
|
||||
transition as an instance of that.}
|
||||
\section{Network Upgrades} \label{networkupgrades}
|
||||
|
||||
\Zcash launched with a protocol revision that we call \Sprout.
|
||||
At the time of writing, two upgrades are planned: \NUZero, and
|
||||
|
@ -6038,53 +6034,45 @@ The upgrade mechanism is described in \cite{ZIP-200}.
|
|||
The specifications of the \NUZero upgrade are described in \cite{ZIP-201},
|
||||
\cite{ZIP-202}, \cite{ZIP-203}, and \cite{ZIP-143}.
|
||||
|
||||
\NUZero and \Sapling will each be introduced in a
|
||||
``bilateral hard fork''. In this kind of fork,
|
||||
\NUZero and \Sapling will each be introduced as a
|
||||
\quotedterm{bilateral consensus rule change}. In this kind of upgrade,
|
||||
|
||||
\begin{itemize}
|
||||
\item there is a \blockHeight at which the fork takes effect;
|
||||
\item there is a \blockHeight at which the \consensusRuleChange
|
||||
takes effect;
|
||||
\item \blocks and \transactions that are valid according to
|
||||
the post-fork rules are not valid before the forking \block;
|
||||
the post-upgrade rules are not valid before the upgrade
|
||||
\blockHeight;
|
||||
\item \blocks and \transactions that are valid according to
|
||||
the pre-fork rules are no longer valid in or after the
|
||||
forking \block.
|
||||
the pre-upgrade rules are no longer valid at or after the
|
||||
upgrade \blockHeight.
|
||||
\end{itemize}
|
||||
|
||||
Full support for each upgrade is indicated by a minimum version
|
||||
of the peer-to-peer protocol. Before the planned fork \blockHeight,
|
||||
nodes that support \Sapling will disconnect from (and will not
|
||||
of the peer-to-peer protocol. At the planned upgrade \blockHeight,
|
||||
nodes that support a given upgrade will disconnect from (and will not
|
||||
reconnect to) nodes with a protocol version lower than this
|
||||
minimum.
|
||||
minimum. See \cite{ZIP-201} for how this applies to the \NUZero
|
||||
upgrade.
|
||||
|
||||
This ensures that \Sapling-supporting nodes transition cleanly
|
||||
This ensures that upgrade-supporting nodes transition cleanly
|
||||
from the old protocol to the new protocol. Nodes that do not
|
||||
support \Sapling will find themselves, in advance of the fork,
|
||||
on a network that uses the old protocol and is fully partitioned
|
||||
from the \Sapling-supporting network.
|
||||
support the upgrade will find themselves on a network that uses
|
||||
the old protocol and is fully partitioned from the upgrade-supporting
|
||||
network.
|
||||
|
||||
This allows us to specify arbitrary protocol changes that
|
||||
take effect at a given \blockHeight. Note, however, that a
|
||||
\blockchain reorganization across a forking \block is possible.
|
||||
\blockchain reorganization across the upgrade \blockHeight is possible.
|
||||
In the case of such a reorganization, \blocks at a height
|
||||
before the forking \blockHeight will still be created and
|
||||
validated according to the pre-\Sapling rules, and
|
||||
\Sapling-supporting nodes \MUST allow for this.
|
||||
However, once a node has seen 99 valid \blocks on top of a
|
||||
forking \block, it may assume that the fork is ``locked in''
|
||||
and need not support reorganizations that roll back to before
|
||||
that forking \block.
|
||||
before the upgrade \blockHeight will still be created and
|
||||
validated according to the pre-upgrade rules, and
|
||||
upgrade-supporting nodes \MUST allow for this.
|
||||
|
||||
For the \Sapling hard fork (but not necessarily for bilateral
|
||||
hard forks in general), both the \blockVersionNumber and the
|
||||
\transactionVersionNumber are set to a value that was invalid
|
||||
according to the pre-\Sapling rules. (They are actually
|
||||
decreased, not increased.) The pre-\Sapling \blockVersionNumber
|
||||
is not accepted for the forking \block or subsequent blocks,
|
||||
and the pre-\Sapling \transactionVersionNumber is not accepted
|
||||
for \transactions in such blocks.
|
||||
%\todo{how upgrade-dependent rules are described in this specification.}
|
||||
|
||||
A new \Sapling \nullifierSet and \noteCommitmentTree are created
|
||||
for use by \Sapling \transactions.
|
||||
%For the \Sapling upgrade, a new \nullifierSet and \noteCommitmentTree
|
||||
%are created for use by \Sapling \transactions.
|
||||
}
|
||||
|
||||
|
||||
|
@ -6178,8 +6166,8 @@ The encoding of $\joinSplitPubKey$ and the data to be signed are specified in
|
|||
identically to version $2$ \transactions.
|
||||
\nuzeroonwarditem{Once \NUZero has activated, limits on the maximum
|
||||
\transactionVersionNumber are consensus rules.}
|
||||
\item Note that a future hard fork might use \emph{any} \transactionVersionNumber.
|
||||
It is likely that a hard fork that changes the \transactionVersionNumber
|
||||
\item Note that a future upgrade might use \emph{any} \transactionVersionNumber.
|
||||
It is likely that an upgrade that changes the \transactionVersionNumber
|
||||
will also change the \transaction format, and software that parses
|
||||
\transactions{} \SHOULD take this into account.
|
||||
\sprout{
|
||||
|
@ -6432,13 +6420,13 @@ rejected by this rule at a given point in time may later be accepted.
|
|||
\item The exclusion of \blocks with \blockVersionNumber{} \emph{greater than} $4$
|
||||
is not a consensus rule; such \blocks may exist in the \blockchain
|
||||
and \MUST be treated identically to version $4$ \blocks by \fullValidators.
|
||||
Note that a future hard fork might use \blockVersionNumber{} either
|
||||
greater than or less than $4$. It is likely that such a hard fork will
|
||||
Note that a future upgrade might use \blockVersionNumber{} either
|
||||
greater than or less than $4$. It is likely that such an upgrade will
|
||||
change the \block header and/or \transaction format, and software that
|
||||
parses \blocks{} \SHOULD take this into account.
|
||||
\item The $\nVersion$ field is a signed integer. (It was specified
|
||||
as unsigned in a previous version of this specification.) A future
|
||||
hard fork might use negative values for this field, or otherwise change
|
||||
upgrade might use negative values for this field, or otherwise change
|
||||
its interpretation.
|
||||
\item There is no relation between the values of the $\versionField$ field of a \transaction,
|
||||
and the $\nVersion$ field of a \blockHeader.
|
||||
|
@ -6834,7 +6822,7 @@ For the test network, $\FounderAddressList_\barerange{\mathrm{1}}{\NumFounderAdd
|
|||
\renewcommand{\arraystretch}{\defaultarraystretch}
|
||||
|
||||
\pnote{For the test network only, the addresses from index 4 onward have been changed from
|
||||
what was implemented at launch. This reflects a hard fork on the test network, starting
|
||||
what was implemented at launch. This reflects an upgrade on the test network, starting
|
||||
from \blockHeight 53127. \cite{ZcashIssue-2113}}
|
||||
|
||||
Each address representation in $\FounderAddressList$ denotes a \transparent
|
||||
|
@ -7746,7 +7734,7 @@ Daira Hopwood, Sean Bowe, and Jack Grigg.
|
|||
\item Correct the order of arguments to $\CommitAlg$ in \crossref{concretesproutcommit}.
|
||||
\item Correct a statement about indistinguishability of \joinSplitDescriptions.
|
||||
\item Change the \foundersReward addresses, for the test network only, to
|
||||
reflect the hard fork described in \cite{ZcashIssue-2113}.
|
||||
reflect the hard-fork upgrade described in \cite{ZcashIssue-2113}.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
|
|
Loading…
Reference in New Issue