Skip to content

Commit

Permalink
Merge pull request #35 from SeanAvery/casper-tfg-spellcheck
Browse files Browse the repository at this point in the history
Small misspelling fix (Casper TFG paper) above definition 2.1
  • Loading branch information
vladzamfir committed Nov 16, 2017
2 parents 5c84d06 + 868ad9b commit d13cb97
Show file tree
Hide file tree
Showing 2 changed files with 11 additions and 11 deletions.
Binary file modified papers/CasperTFG/CasperTFG.pdf
Binary file not shown.
22 changes: 11 additions & 11 deletions papers/CasperTFG/CasperTFG.tex
Original file line number Diff line number Diff line change
Expand Up @@ -130,7 +130,7 @@ \section{Casper the Friendly Binary Consensus}

Protocol messages have three parts. An ``estimate'' (a $0$ or a $1$), a ``sender'' (a validator name), and a ``justification''. The justification is itself a set of protocol messages. Validators use these protocol messages to update each other on their current estimates. Further, the estimate values are not arbitrary because a protocol message is ``valid'' only if the ``estimate'' is the result of applying the estimator on the message's ``justification''.

The definitions of the estimator and of validity appear later. For now, we denote the set of all possible protocol messages in the binary consensus pwill rotocol as $\mathcal{M}$, and define it as follows:
The definitions of the estimator and of validity appear later. For now, we denote the set of all possible protocol messages in the binary consensus protocol as $\mathcal{M}$, and define it as follows:

\begin{defn}[Protocol Messages, $\mathcal{M}$]
\begin{equation*}
Expand All @@ -143,9 +143,9 @@ \section{Casper the Friendly Binary Consensus}
\end{defn}

$\mathcal{M}_0$ is the ``base case'', the set of messages with ``null justifications''. $\mathcal{M}_n$ is the set of messages at ``height'' $n$, which have messages of height $n-1$ (and/or lower) in their justification. Note that messages $\mathcal{M}_0$ have height $0$. $\mathcal{P}$ denotes the ``power set'' function, which maps set to the set of all of its subsets, so $\mathcal{P}(\bigcup_{i=0}^{n-1} \mathcal{M}_i)$ denotes all sets of protocol messages at height $n-1$ or lower.

The estimator is a function that maps sets of protocol messages to $0$ or $1$, or a null value denoted by $\emptyset$:

\begin{equation*}
\begin{split}
\mathcal{E}:\mathcal{P}(\mathcal{M}) \to \{0, 1\} \cup \{\emptyset\}
Expand Down Expand Up @@ -179,7 +179,7 @@ \section{Casper the Friendly Binary Consensus}

\begin{equation*}
\begin{split}
D(m) = &\{m\}\cup \bigcup_{m' \in J(m)} D(m')
D(m) = &\{m\}\cup \bigcup_{m' \in J(m)} D(m')
\end{split}
\end{equation*}

Expand Down Expand Up @@ -241,7 +241,7 @@ \section{Casper the Friendly Binary Consensus}
\end{align}
\end{defn}

We then define the Byzantine nodes visible in $M$ as
We then define the Byzantine nodes visible in $M$ as

$$
B(M) = \{v \in V: B(v,M)\}
Expand Down Expand Up @@ -296,7 +296,7 @@ \section{Casper the Friendly Ghost}

Protocol messages are called ``blocks'' and have the same three components as the messages in the binary consensus protocol; an estimate, a sender and a justification. The estimate is a block, called ``the prevblock'' or ``the parent block''. For valid messages, the estimate is the block on the head of the blockchain chosen by the GHOST fork choice rule in the justification. The ``sender'' (a validator name) field is defined precisely as before. Finally, the justification is again simply a set of protocol messages.

Formally, in Casper the Friendly Ghost we have protocol messages, $\mathcal{M}$, with the following form (again parametric in a set of validator names, $\mathcal{V}$):
Formally, in Casper the Friendly Ghost we have protocol messages, $\mathcal{M}$, with the following form (again parametric in a set of validator names, $\mathcal{V}$):


\begin{defn}[Blocks]
Expand All @@ -316,7 +316,7 @@ \section{Casper the Friendly Ghost}

\begin{defn}[Blockchain membership, $b_1 \downarrow b_2$]
\begin{align}
b_1 \downarrow b_2 &\iff b_1 = b_2 \text{ or } b_1 \downarrow E(b_2)
b_1 \downarrow b_2 &\iff b_1 = b_2 \text{ or } b_1 \downarrow E(b_2)
\end{align}
\end{defn}

Expand Down Expand Up @@ -362,7 +362,7 @@ \section{Casper the Friendly Ghost}

We assume that ``hash'' has the property that out of any set of blocks, only one has the lowest hash. Using the hashes of blocks to eliminate ``ties'' means that the estimator for the blockchain consensus never outputs an exception. Previously the binary estimator return $\emptyset$ when $0$ and $1$ had the same score. This means that a message $m$ is valid if $E(m) = \mathcal{E}(J(m))$, and just as in the binary consensus we insist that all the blocks are valid. \footnote{Following the process decribed in the footnote about excluding invalid messages from the binary consensus.}

``Equivocation'', ``Byzantine faulty'', ``fault weight'', ``protocol states'', and ``protocol executions'' are defined here in \emph{precisely} the same way as in the binary consensus. We therefore do not give the definitions again.
``Equivocation'', ``Byzantine faulty'', ``fault weight'', ``protocol states'', and ``protocol executions'' are defined here in \emph{precisely} the same way as in the binary consensus. We therefore do not give the definitions again.

We can now give the definition of estimate safety for Casper the Friendly Ghost, for a block $b$ in a protocol state $\sigma$.

Expand All @@ -372,7 +372,7 @@ \section{Casper the Friendly Ghost}
$$
\end{defn}

Because this construction satisfies the terms of our consensus safety proof, we know that decisions on safe estimates in this protocol are consensus safe (if there are less than $t$ Byzantine faults (by weight)).
Because this construction satisfies the terms of our consensus safety proof, we know that decisions on safe estimates in this protocol are consensus safe (if there are less than $t$ Byzantine faults (by weight)).

We now present a mechanism that nodes can use to detect which of their estimates are safe in both the binary and the blockchain consensus.

Expand Down Expand Up @@ -424,7 +424,7 @@ \section{A Simple Safety Oracle}
We present the pseudocode for the ``clique oracle'' that uses this result to detect estimate safety:

\begin{algorithm}[H]
\KwData{An estimate $e$, a set of messages $M \in \Sigma_t$}
\KwData{An estimate $e$, a set of messages $M \in \Sigma_t$}
\KwResult{True or False, an indicator when $e$ is safe in $M \in \Sigma_t$}


Expand Down Expand Up @@ -452,7 +452,7 @@ \section{A Simple Safety Oracle}
\Return{False}
}

\If{2*clique\_weight $>$ total\_weight}{
\If{2*clique\_weight $>$ total\_weight}{
initial\_fault\_weight = $F(M)$ (this will be $\leq t$ because $M \in \Sigma_t$)

fault\_tolerance = 2*clique\_weight - total\_weight
Expand Down

0 comments on commit d13cb97

Please sign in to comment.