In \crossref{blockchain}, define what a settled network upgrade is, specify requirements

for checkpointing, and allow nodes to impose a limitation on rollback depth. Also in
\crossref{bctv}, note that this checkpointing requirement mitigates the risks of not
performing BCTV14 zk proof verification.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-03-18 00:48:01 +00:00
parent a2efd493bb
commit 5c7c728e63
1 changed files with 42 additions and 8 deletions

View File

@ -719,6 +719,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\TAZ}{\termbf{TAZ}}
\newcommand{\zatoshi}{\term{zatoshi}}
\newcommand{\zcashd}{\termsf{zcashd}}
\newcommand{\zebra}{\termsf{zebra}}
\newcommand{\Makefile}{\texttt{Makefile}\xspace}
\newcommand{\MUST}{\conformance{MUST}}
@ -959,6 +960,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\networks}{\terms{network}}
\newcommand{\Mainnet}{\term{Mainnet}}
\newcommand{\Testnet}{\term{Testnet}}
\newcommand{\settled}{\term{settled}}
\newcommand{\rpcByteOrder}{\term{RPC byte order}}
\newcommand{\anchor}{\term{anchor}}
\newcommand{\anchors}{\terms{anchor}}
@ -3327,12 +3329,28 @@ absent future consensus changes.}
In order to choose the \defining{\bestValidBlockChain} in its view of the
overall \block tree, a node sums the work, as defined in \crossref{workdef}, of
all \blocks in each \validBlockChain, and considers the \validBlockChain with greatest
total work to be best. To break ties between leaf \blocks, a node will prefer the
\block that it received first.
total work to be best. To break ties between leaf \blocks, a node will prefer the \block
that it received first.
The consensus protocol is designed to ensure that for any given \blockHeight,
the vast majority of nodes should eventually agree on their \bestValidBlockChain
up to that height.
The consensus protocol is designed to ensure that for any given \blockHeight, the vast
majority of well-connected nodes should eventually agree on their \bestValidBlockChain
up to that height. A \fullValidator\footnote{There is reason to follow the requirements
in this section also for non-full validators, but those are outside the scope of this
protocol specification.} \SHOULD attempt to obtain candidate \blocks from multiple
sources in order to increase the likelihood that it will find a \validBlockChain that
reflects a recent consensus state.
A \networkUpgrade is \defining{\settled} on a given \network when there is a social
consensus that it has activated with a given \activationBlock hash. A \fullValidator
that potentially risks \Mainnet funds or displays \Mainnet \transaction information
to a user \MUST do so only for a \blockChain that includes the \activationBlock of
the most recent \settled \networkUpgrade, with the corresponding \activationBlock hash.
Currently, there is social consensus that \Canopy has activated on the \Zcash \Mainnet
and \Testnet with the \activationBlock hashes given in \crossref{networks}.
A \fullValidator \MAY impose a limit on the number of \blocks it will ``roll back'' when
switching from one \bestValidBlockChain to another that is not a descendent. For \zcashd
and \zebra this limit is $100$ \blocks.
\vspace{-1ex}
@ -11250,9 +11268,13 @@ generation \cite[Theorem 4.10]{BGG2017}.
}
\saplingonward{An implementation of \Zcash that checkpoints on a \block after \Sapling
\MAY choose to skip verification of \BCTV proofs. In this case, the implementation \MUST
only accept \blocks that are descendants of the known \Sapling \activationBlock on
the appropriate \network.}
\MAY choose to skip verification of \BCTV proofs. Note that in \crossref{blockchain},
there is a requirement that a \fullValidator that potentially risks \Mainnet funds
or displays \Mainnet \transaction information to a user \MUST do so only for a
\blockChain that includes the \activationBlock of the most recent \settled
\networkUpgrade, with its known \blockHash as specified in \crossref{networks}.
Since the most recent \settled \networkUpgrade is after the \Sapling \networkUpgrade,
this mitigates the potential risks due to skipping \BCTV proof verification.}
\introlist
\lsubsubsubsubsection{Encoding of \BCTVText{} Proofs}{bctvencoding}
@ -14557,6 +14579,18 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\lsection{Change History}{changehistory}
\historyentry{2022.3.0}{}
\begin{itemize}
\item In \crossref{blockchain}, define what a \settled \networkUpgrade is,
specify requirements for checkpointing, and allow nodes to impose
a limitation on rollback depth.
\sapling{
\item In \crossref{bctv}, note that the above checkpointing requirement
mitigates the risks of not performing \BCTV \zkProof verification.
} %sapling
\end{itemize}
\historyentry{2022.2.19}{2022-01-19}
\begin{itemize}
\nufive{