zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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:
Daira Hopwood 2018-03-18 20:38:55 +00:00
parent 108fa4daa0
commit 5cac8e9b6a
1 changed files with 31 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
protocol/protocol.tex
View File

@ -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