Merge pull request #28 from tendermint/bucky/fixes

various minor fixes

Author: ebuchman

consensus/consensus.tex

@@ -128,7 +128,7 @@ \section{Tendermint consensus algorithm} \label{sec:tendermint}
 log for every process. An upon rule is triggered once the message log contains
 messages such that the corresponding condition evaluates to $\tt{true}$. The
 condition that assumes reception of $X$ messages of a particular type and
-content, denotes a set of messages whose senders have aggregate voting power at
+content denotes a set of messages whose senders have aggregate voting power at
 least equal to $X$. The variables with index $p$ are process local state
 variables, while variables without index $p$ are value placeholders. The sign
 $*$ denotes any value.    
@@ -196,8 +196,9 @@ \section{Tendermint consensus algorithm} \label{sec:tendermint}
 $validRound$ is the last round in which $validValue$ is updated. Apart from
 those variables, a process also stores the current consensus instance ($h_p$,
 called \emph{height} in Tendermint), and the current round number ($round_p$)
-and attaches them to every message. Finally a process also stores an array of
-decisions (Tendermint assumes a sequence of consensus instances) $decision_p$. 
+and attaches them to every message. Finally, a process also stores an array of
+decisions, $decision_p$ (Tendermint assumes a sequence of consensus instances,
+one for each height).
 
 Every round starts by a proposer suggesting a value with the $\Proposal$
 message (see line \ref{line:tab:send-proposal}). In the initial round of each
@@ -217,7 +218,7 @@ \section{Tendermint consensus algorithm} \label{sec:tendermint}
 at time $t > GST$, by the \emph{Gossip communication} property, the
 corresponding $\Proposal$ and the $\Prevote$ messages will be received by all
 correct processes before time $t+\Delta$. Therefore, all correct processes will
-be able to verify the correctness of the suggested value as it supported by the
+be able to verify the correctness of the suggested value as it is supported by the
 $\Proposal$ and the corresponding $2f+1$ voting power equivalent $\Prevote$
 messages.   
 
@@ -227,7 +228,7 @@ \section{Tendermint consensus algorithm} \label{sec:tendermint}
 the value $v$ ($lockedValue = v$); see the line
 \ref{line:tab:accept-proposal-2}.  In case the proposed pair is $(v,r)$ and a
 correct process $p$ has locked some other value ($v' \neq v$), it will accept
-$v$ only if $v'$ was a more recent possible decision value\footnote{As
+$v$ only if $v$ was a more recent possible decision value\footnote{As
 explained above, the possible decision value in a round $r$ is the one for
 which $\Proposal$ and the corresponding $2f+1$ $\Prevote$ messages are received
 for the round $r$.} in a round $r > lockedRound_p$.  Otherwise, a correct
@@ -293,12 +294,12 @@ \subsection{Termination mechanism}
 
 The second thing to note is that during good period, because of the
 \emph{Gossip communication} property, if a correct process $p$ locks a value
-$v$ is some round $r$, all correct processes will update $validValue$ to $v$
+$v$ in some round $r$, all correct processes will update $validValue$ to $v$
 and $validRound$ to $r$ before the end of the round $r$ (we prove this formally
 in the Section~\ref{sec:proof}). The intuition is that messages that led to $p$
 locking a value $v$ in the round $r$ will be gossiped to all correct processes
 before the end of the round $r$, so it will update $validValue$ and
-$validRound$ (the lineline~\ref{line:tab:recvPrevote}). Therefore, if a correct
+$validRound$ (the line~\ref{line:tab:recvPrevote}). Therefore, if a correct
 process locks some value during good period, $validValue$ and $validRound$ are
 updated by all correct processes so that the value proposed in the following
 rounds will be acceptable by all correct processes. And last thing to note is

consensus/definitions.tex

@@ -99,7 +99,7 @@ \subsection{State Machine Replication}
  \subsection{Consensus} \label{sec:consensus}
 
 Tendermint solves state machine replication by sequentially executing consensus
-instances to agree on the content of the next block of transactions that are
+instances to agree on each block of transactions that are
 then executed by the service being replicated. We consider a variant of the
 Byzantine consensus problem called Validity Predicate-based Byzantine consensus
 that is motivated by blockchain systems~\cite{GLR17:red-belly-bc}. The problem

consensus/intro.tex

@@ -32,7 +32,7 @@ \section{Introduction} \label{sec:tendermint}
 that is at the core of the BFT SMR platform called Tendermint\footnote{The
 Tendermint platform is available open source at
 https://github.com/tendermint/tendermint.}. The Tendermint patform consists of
-a high-performance BFT SMR implementation in Go, a flexible interface for
+a high-performance BFT SMR implementation written in Go, a flexible interface for
 building arbitrary deterministic applications above the consensus, and a suite
 of tools for deployment and management.  
 
@@ -92,9 +92,9 @@ \section{Introduction} \label{sec:tendermint}
     value id, \item in Fast Byzantine Paxos~\cite{MA06:tdsc} it is the value
         itself that is being sent.  \end{itemize}
 
-In both cases, using this mechanism in the system model we consider (high
+In both cases, using this mechanism in our system model (ie. high
 number of nodes over gossip based network) would have high communication
-complexity that is increased with the number of processes: in the first case as
+complexity that increases with the number of processes: in the first case as
 the message sent depends on the total number of processes, and in the second
 case as the value (block of transactions) is sent by each process. The set of
 messages received in the first step are normally piggybacked on the proposal
@@ -114,7 +114,7 @@ \section{Introduction} \label{sec:tendermint}
 this makes Tendermint simpler to understand and implement correctly.  
 
 The remainder of the paper is as follows: Section~\ref{sec:definitions} defines
-a system model considered and gives the problem definitions. Tendermint
+the system model and gives the problem definitions. Tendermint
 consensus algorithm is introduced in Section~\ref{sec:tendermint} and the
 proofs are presented in Section~\ref{sec:proof}. We discuss related work in
 Section~\ref{sec:relatedWork} and conclude in Section~\ref{sec:conclusion}.