diff --git a/consensus/consensus.tex b/consensus/consensus.tex index 06f37894..72d5e9b1 100644 --- a/consensus/consensus.tex +++ b/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 diff --git a/consensus/definitions.tex b/consensus/definitions.tex index 6cfefe0c..a6babaee 100644 --- a/consensus/definitions.tex +++ b/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 diff --git a/consensus/intro.tex b/consensus/intro.tex index 39735381..745dcd14 100644 --- a/consensus/intro.tex +++ b/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}.