diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 8bfda485..b53bf6d6 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -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