mirror of https://github.com/zcash/zips.git
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:
parent
a2efd493bb
commit
5c7c728e63
|
@ -719,6 +719,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
|
||||||
\newcommand{\TAZ}{\termbf{TAZ}}
|
\newcommand{\TAZ}{\termbf{TAZ}}
|
||||||
\newcommand{\zatoshi}{\term{zatoshi}}
|
\newcommand{\zatoshi}{\term{zatoshi}}
|
||||||
\newcommand{\zcashd}{\termsf{zcashd}}
|
\newcommand{\zcashd}{\termsf{zcashd}}
|
||||||
|
\newcommand{\zebra}{\termsf{zebra}}
|
||||||
\newcommand{\Makefile}{\texttt{Makefile}\xspace}
|
\newcommand{\Makefile}{\texttt{Makefile}\xspace}
|
||||||
|
|
||||||
\newcommand{\MUST}{\conformance{MUST}}
|
\newcommand{\MUST}{\conformance{MUST}}
|
||||||
|
@ -959,6 +960,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
|
||||||
\newcommand{\networks}{\terms{network}}
|
\newcommand{\networks}{\terms{network}}
|
||||||
\newcommand{\Mainnet}{\term{Mainnet}}
|
\newcommand{\Mainnet}{\term{Mainnet}}
|
||||||
\newcommand{\Testnet}{\term{Testnet}}
|
\newcommand{\Testnet}{\term{Testnet}}
|
||||||
|
\newcommand{\settled}{\term{settled}}
|
||||||
\newcommand{\rpcByteOrder}{\term{RPC byte order}}
|
\newcommand{\rpcByteOrder}{\term{RPC byte order}}
|
||||||
\newcommand{\anchor}{\term{anchor}}
|
\newcommand{\anchor}{\term{anchor}}
|
||||||
\newcommand{\anchors}{\terms{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
|
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
|
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
|
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
|
total work to be best. To break ties between leaf \blocks, a node will prefer the \block
|
||||||
\block that it received first.
|
that it received first.
|
||||||
|
|
||||||
The consensus protocol is designed to ensure that for any given \blockHeight,
|
The consensus protocol is designed to ensure that for any given \blockHeight, the vast
|
||||||
the vast majority of nodes should eventually agree on their \bestValidBlockChain
|
majority of well-connected nodes should eventually agree on their \bestValidBlockChain
|
||||||
up to that height.
|
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}
|
\vspace{-1ex}
|
||||||
|
@ -11250,9 +11268,13 @@ generation \cite[Theorem 4.10]{BGG2017}.
|
||||||
}
|
}
|
||||||
|
|
||||||
\saplingonward{An implementation of \Zcash that checkpoints on a \block after \Sapling
|
\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
|
\MAY choose to skip verification of \BCTV proofs. Note that in \crossref{blockchain},
|
||||||
only accept \blocks that are descendants of the known \Sapling \activationBlock on
|
there is a requirement that a \fullValidator that potentially risks \Mainnet funds
|
||||||
the appropriate \network.}
|
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
|
\introlist
|
||||||
\lsubsubsubsubsection{Encoding of \BCTVText{} Proofs}{bctvencoding}
|
\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}
|
\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}
|
\historyentry{2022.2.19}{2022-01-19}
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\nufive{
|
\nufive{
|
||||||
|
|
Loading…
Reference in New Issue