From 91c5ec922d867ca581fb33eda2f11aef744735eb Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sat, 4 Feb 2017 04:24:45 +0000 Subject: [PATCH] Split "The Block Chain" and "Transactions and Treestates" sections. Remove the concept of 'block chain views'. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 99 +++++++++++++++++++++++++------------------ 1 file changed, 58 insertions(+), 41 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 238783f..cf8c3a4 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -271,8 +271,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\shieldedNotes}{\term{shielded notes}} \newcommand{\xShielded}{\term{Shielded}} \newcommand{\Shielded}{\titleterm{Shielded}} -\newcommand{\blockchainview}{\term{block chain view}} \newcommand{\blockchain}{\term{block chain}} +\newcommand{\blockchains}{\term{block chains}} \newcommand{\mempool}{\term{mempool}} \newcommand{\treestate}{\term{treestate}} \newcommand{\treestates}{\term{treestates}} @@ -1121,30 +1121,52 @@ $\Memo$ represents a \memo associated with this \note. The usage of the } -\nsubsection{Transactions, Blocks, and the Block Chain} \label{blockchain} +\nsubsection{The Block Chain} \label{blockchain} -At a given point in time, the \blockchainview of each \fullnode consists of a -sequence of one or more valid \blocks. Each \block consists of a sequence of one or -more \transactions. To each \transaction there is associated an initial \treestate, -which consists of a \noteCommitmentTree (\crossref{merkletree}), \nullifierSet -(\crossref{nullifierset}), and data structures associated with \Bitcoin such as -the UTXO (Unspent Transaction Output) set. +At a given point in time, each \fullnode is aware of a set of candidate +\blocks. These form a tree rooted at the \genesisBlock, where each node +in the tree refers to its parent via the $\hashPrevBlock$ \blockHeader field +(see \crossref{blockheader}). + +A path from the root toward the leaves of the tree consisting of a sequence +of one or valid \blocks consistent with consensus rules, is called a valid +\blockchain. -Each \block in a \blockchainview has a \blockHeight. The \blockHeight of the +Each \block in a \blockchain has a \blockHeight. The \blockHeight of the \genesisBlock is 0, and the \blockHeight of each subsequent \block in the \blockchain increments by 1. +The consensus protocol is designed to ensure that for any given \blockHeight, +the vast majority of nodes should eventually agree on their ``best'' +\blockchain up to that height. + + +\nsubsection{Transactions and Treestates} \label{transactions} + +Each \block contains one or more \transactions. + Inputs to a \transaction insert value into a \transparentValuePool, and outputs remove value from this pool. As in \Bitcoin, the remaining value in the pool is available to miners as a fee. +\vspace{-3ex} +\consensusrule{ +The \transparentValuePool must have a nonnegative total value. +} +\vspace{2ex} + +To each \transaction there is associated an initial \treestate. A \treestate +consists of a \noteCommitmentTree (\crossref{merkletree}), \nullifierSet +(\crossref{nullifierset}), and data structures associated with \Bitcoin such as +the UTXO (Unspent Transaction Output) set. + An \anchor is a Merkle tree root of a \noteCommitmentTree. It uniquely identifies a \noteCommitmentTree state given the assumed security properties of the Merkle tree's hash function. Since the \nullifierSet is always updated together with the \noteCommitmentTree, this also identifies a particular state of the \nullifierSet. \introlist -In a given node's \blockchainview, \treestates are chained as follows: +In a given \blockchain, \treestates are chained as follows: \begin{itemize} \item The input \treestate of the first \block is the empty \treestate. @@ -1158,10 +1180,6 @@ In a given node's \blockchainview, \treestates are chained as follows: \todo{\joinSplitDescriptions also have input and output \treestates.} -We rely on Bitcoin-style consensus for \fullnodes to eventually converge on their -views of valid \blocks, and therefore of the sequence of \treestates in those -\blocks. - \nsubsection{\JoinSplitTransfers{} and Descriptions} \label{joinsplit} @@ -1176,21 +1194,18 @@ $\vpubNew$. Each \transaction is associated with a \sequenceOfJoinSplitDescriptions. -The input and output values of each \joinSplitTransfer{} \MUST balance exactly. The \changed{total $\vpubNew$ value adds to, and the total} $\vpubOld$ value subtracts from the \transparentValuePool of the containing \transaction. -\todo{Describe the interaction of \transparent value flows with the \joinSplitDescription's -\changed{$\vpubOld$ and} $\vpubNew$.} - +\begin{consensusrules} + \item The input and output values of each \joinSplitTransfer{} \MUST balance + exactly. \changed{ -The \anchor of each \joinSplitDescription in a \transaction must refer to either -some earlier \block's final \treestate, or to the output \treestate of any prior -\joinSplitDescription in the same \transaction. + \item The \anchor of each \joinSplitDescription in a \transaction{} \MUST refer + to either some earlier \block's final \treestate, or to the output + \treestate of any prior \joinSplitDescription in the same \transaction. } - -These conditions act as constraints on the blocks that a \fullnode will -accept into its \blockchainview. +\end{consensusrules} \nsubsection{\NoteCommitmentTree} \label{merkletree} @@ -1219,13 +1234,13 @@ is denoted $\MerkleNode{h}{i}$. \nsubsection{\NullifierSet} \label{nullifierset} -Each \fullnode maintains a \nullifierSet alongside the \noteCommitmentTree and UTXO set. +Each \fullnode maintains a \nullifierSet logically associated with each \treestate. As valid \transactions containing \joinSplitTransfers are processed, the \nullifiers revealed in \joinSplitDescriptions are inserted into this \nullifierSet. -If a \joinSplitDescription reveals a \nullifier that already exists in -the \fullnode's \blockchainview, the containing transaction will be rejected, since -it would otherwise result in a double-spend. +If a \joinSplitDescription reveals a \nullifier that already exists in the +\blockchain at the associated \treestate, the containing \transaction will be +rejected, since it would otherwise result in a double-spend. \nsubsection{Block Subsidy and Founders' Reward} \label{subsidyconcepts} @@ -1807,12 +1822,11 @@ according to client implementation. \nsubsection{\NoteCommitments{} and \Nullifiers} -A \transaction that contains one or more \joinSplitDescriptions, when entered into the -blockchain, appends to the \noteCommitmentTree with all constituent +A \transaction that contains one or more \joinSplitDescriptions, when entered +into the \blockchain, appends to the \noteCommitmentTree with all constituent \noteCommitments. All of the constituent \nullifiers are also entered into the -\nullifierSet of the \blockchainview \emph{and} \mempool. A \transaction is not -valid if it attempts to add a \nullifier to the \nullifierSet that already -exists in the set. +\nullifierSet of the associated \treestate. A \transaction is not valid if it +attempts to add a \nullifier to the \nullifierSet that already exists in the set. \nsubsection{\JoinSplitStatement} \label{jsstatement} @@ -2002,18 +2016,18 @@ is defined as follows: \end{itemize} } -To test whether a \note is unspent in a particular \blockchainview also requires +To test whether a \note is unspent in a particular \blockchain also requires the \spendingKey $\AuthPrivate$; the coin is unspent if and only if $\nf = \PRFnf{\AuthPrivate}(\NoteAddressRand)$ is not in the \nullifierSet -for that \blockchainview. +for that \blockchain. \begin{pnotes} \item The decryption algorithm corresponds to step 3 (b) i. and ii. (first bullet point) of the $\Receive$ algorithm shown in \cite[Figure 2]{BCG+2014}. - \item A \note can change from being unspent to spent on a given \blockchainview, - as \transactions are added to that view. Also, blockchain reorganisations - can cause the \transaction in which a \note was output to no longer be on - the consensus blockchain. + \item A \note can change from being unspent to spent as a node's view of the best + \blockchain is extended by new \transactions. Also, \blockchain reorganisations + can cause a node to switch to a different best \blockchain that does not + contain the \transaction in which a \note was output. \end{pnotes} See \crossref{inbandrationale} for further discussion of the security and @@ -3740,7 +3754,7 @@ of their funds, even if they have forgotten everything but the Instead, \Zcash enforces that an adversary must choose distinct values for each $\NoteAddressRand$, by making use of the fact that all of the -\nullifiers in \joinSplitDescriptions that appear in a valid \blockchainview +\nullifiers in \joinSplitDescriptions that appear in a valid \blockchain must be distinct. This is true regardless of whether the \nullifiers corresponded to real or dummy notes (see \crossref{dummynotes}). The \nullifiers are used as input to $\hSigCRH$ to derive a public value @@ -3762,7 +3776,7 @@ Now even if the creator of a \joinSplitDescription does not choose $\NoteAddressPreRand$ randomly, uniqueness of \nullifiers and collision resistance of both $\hSigCRH$ and $\PRFrho{}$ will ensure that the derived $\NoteAddressRand$ values are unique, at least for -any two \joinSplitDescriptions that get into a valid \blockchainview. +any two \joinSplitDescriptions that get into a valid \blockchain. This is sufficient to prevent the Faerie Gold attack. @@ -4056,6 +4070,9 @@ The errors in the proof of Ledger Indistinguishability mentioned in \begin{itemize} \item Add abstract and keywords. \item Fix a typo in the definition of \nullifier integrity. + \item Make the description of \blockchains more consistent with + upstream \Bitcoin documentation (referring to ``best`` chains + rather than using the concept of a \term{block chain view}). \end{itemize} \introlist