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{ \sapling{
\introsection \introsection
\section{\Sapling Transition} \label{saplingtransition} \section{Network Upgrades} \label{networkupgrades}
\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.}
\Zcash launched with a protocol revision that we call \Sprout. \Zcash launched with a protocol revision that we call \Sprout.
At the time of writing, two upgrades are planned: \NUZero, and 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}, The specifications of the \NUZero upgrade are described in \cite{ZIP-201},
\cite{ZIP-202}, \cite{ZIP-203}, and \cite{ZIP-143}. \cite{ZIP-202}, \cite{ZIP-203}, and \cite{ZIP-143}.
\NUZero and \Sapling will each be introduced in a \NUZero and \Sapling will each be introduced as a
``bilateral hard fork''. In this kind of fork, \quotedterm{bilateral consensus rule change}. In this kind of upgrade,
\begin{itemize} \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 \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 \item \blocks and \transactions that are valid according to
the pre-fork rules are no longer valid in or after the the pre-upgrade rules are no longer valid at or after the
forking \block. upgrade \blockHeight.
\end{itemize} \end{itemize}
Full support for each upgrade is indicated by a minimum version Full support for each upgrade is indicated by a minimum version
of the peer-to-peer protocol. Before the planned fork \blockHeight, of the peer-to-peer protocol. At the planned upgrade \blockHeight,
nodes that support \Sapling will disconnect from (and will not nodes that support a given upgrade will disconnect from (and will not
reconnect to) nodes with a protocol version lower than this 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 from the old protocol to the new protocol. Nodes that do not
support \Sapling will find themselves, in advance of the fork, support the upgrade will find themselves on a network that uses
on a network that uses the old protocol and is fully partitioned the old protocol and is fully partitioned from the upgrade-supporting
from the \Sapling-supporting network. network.
This allows us to specify arbitrary protocol changes that This allows us to specify arbitrary protocol changes that
take effect at a given \blockHeight. Note, however, that a 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 In the case of such a reorganization, \blocks at a height
before the forking \blockHeight will still be created and before the upgrade \blockHeight will still be created and
validated according to the pre-\Sapling rules, and validated according to the pre-upgrade rules, and
\Sapling-supporting nodes \MUST allow for this. upgrade-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.
For the \Sapling hard fork (but not necessarily for bilateral %\todo{how upgrade-dependent rules are described in this specification.}
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.
A new \Sapling \nullifierSet and \noteCommitmentTree are created %For the \Sapling upgrade, a new \nullifierSet and \noteCommitmentTree
for use by \Sapling \transactions. %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. identically to version $2$ \transactions.
\nuzeroonwarditem{Once \NUZero has activated, limits on the maximum \nuzeroonwarditem{Once \NUZero has activated, limits on the maximum
\transactionVersionNumber are consensus rules.} \transactionVersionNumber are consensus rules.}
\item Note that a future hard fork might use \emph{any} \transactionVersionNumber. \item Note that a future upgrade might use \emph{any} \transactionVersionNumber.
It is likely that a hard fork that changes the \transactionVersionNumber It is likely that an upgrade that changes the \transactionVersionNumber
will also change the \transaction format, and software that parses will also change the \transaction format, and software that parses
\transactions{} \SHOULD take this into account. \transactions{} \SHOULD take this into account.
\sprout{ \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$ \item The exclusion of \blocks with \blockVersionNumber{} \emph{greater than} $4$
is not a consensus rule; such \blocks may exist in the \blockchain is not a consensus rule; such \blocks may exist in the \blockchain
and \MUST be treated identically to version $4$ \blocks by \fullValidators. and \MUST be treated identically to version $4$ \blocks by \fullValidators.
Note that a future hard fork might use \blockVersionNumber{} either Note that a future upgrade might use \blockVersionNumber{} either
greater than or less than $4$. It is likely that such a hard fork will 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 change the \block header and/or \transaction format, and software that
parses \blocks{} \SHOULD take this into account. parses \blocks{} \SHOULD take this into account.
\item The $\nVersion$ field is a signed integer. (It was specified \item The $\nVersion$ field is a signed integer. (It was specified
as unsigned in a previous version of this specification.) A future 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. its interpretation.
\item There is no relation between the values of the $\versionField$ field of a \transaction, \item There is no relation between the values of the $\versionField$ field of a \transaction,
and the $\nVersion$ field of a \blockHeader. and the $\nVersion$ field of a \blockHeader.
@ -6834,7 +6822,7 @@ For the test network, $\FounderAddressList_\barerange{\mathrm{1}}{\NumFounderAdd
\renewcommand{\arraystretch}{\defaultarraystretch} \renewcommand{\arraystretch}{\defaultarraystretch}
\pnote{For the test network only, the addresses from index 4 onward have been changed from \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}} from \blockHeight 53127. \cite{ZcashIssue-2113}}
Each address representation in $\FounderAddressList$ denotes a \transparent 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 the order of arguments to $\CommitAlg$ in \crossref{concretesproutcommit}.
\item Correct a statement about indistinguishability of \joinSplitDescriptions. \item Correct a statement about indistinguishability of \joinSplitDescriptions.
\item Change the \foundersReward addresses, for the test network only, to \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} \end{itemize}
\introlist \introlist