github.com/aakash4dev/cometbft@v0.38.2/spec/consensus/consensus-paper/definitions.tex (about)

     1  \section{Definitions} \label{sec:definitions}
     2  
     3  \subsection{Model}
     4  
     5  We consider a system of processes that communicate by exchanging messages.
     6  Processes can be correct or faulty, where a faulty process can behave in an
     7  arbitrary way, i.e., we consider Byzantine faults. We assume that each process
     8  has some amount of voting power (voting power of a process can be $0$).
     9  Processes in our model are not part of a single administrative domain;
    10  therefore we cannot enforce a direct network connectivity between all
    11  processes. Instead, we assume that each process is connected to a subset of
    12  processes called peers, such that there is an indirect communication channel
    13  between all correct processes. Communication between processes is established
    14  using a gossip protocol \cite{Dem1987:gossip}.
    15  
    16  Formally, we model the network communication using a variant of the \emph{partially
    17  synchronous system model}~\cite{DLS88:jacm}: in all executions of the system
    18  there is a bound $\Delta$ and an instant GST (Global Stabilization Time) such
    19  that all communication among correct processes after GST is reliable and
    20  $\Delta$-timely, i.e., if a correct process $p$ sends message $m$ at time $t
    21  \ge GST$ to a correct process $q$, then $q$ will receive $m$ before $t +
    22  \Delta$\footnote{Note that as we do not assume direct communication channels
    23      among all correct processes, this implies that before the message $m$
    24      reaches $q$, it might pass through a number of correct processes that will
    25  forward the message $m$ using gossip protocol towards $q$.}. 
    26  In addition to the standard \emph{partially
    27  	synchronous system model}~\cite{DLS88:jacm}, we assume an auxiliary property 
    28  that captures gossip-based nature of communication\footnote{The details of the Tendermint gossip protocol will be discussed in a separate
    29  	technical report. }:
    30  
    31  
    32  \begin{itemize} \item \emph{Gossip communication:} If a correct process $p$
    33  	sends some message $m$ at time $t$, all correct processes will receive
    34  	$m$ before $max\{t, GST\} + \Delta$. Furthermore, if a correct process $p$
    35  	receives some message $m$ at time $t$, all correct processes will receive
    36  	$m$ before $max\{t, GST\} + \Delta$.    \end{itemize}
    37  
    38  
    39  The bound $\Delta$ and GST are system
    40  parameters whose values are not required to be known for the safety of our
    41  algorithm. Termination of the algorithm is guaranteed within a bounded duration
    42  after GST.  In practice, the algorithm will work correctly in the slightly
    43  weaker variant of the model where the system alternates between (long enough)
    44  good periods (corresponds to the \emph{after} GST period where system is
    45  reliable and $\Delta$-timely) and bad periods (corresponds to the period
    46  \emph{before} GST during which the system is asynchronous and messages can be
    47  lost), but consideration of the GST model simplifies the discussion.  
    48  
    49  We assume that process steps (which might include sending and receiving
    50  messages) take zero time.  Processes are equipped with clocks so they can
    51  measure local timeouts.  
    52  Spoofing/impersonation attacks are assumed to be impossible at all times due to
    53  the use of public-key cryptography, i.e., we assume that all protocol messages contains a digital signature.
    54  Therefore, when a correct
    55  process $q$ receives a signed message $m$ from its peer, the process $q$ can
    56  verify who was the original sender of the message $m$ and if the message signature is valid.
    57  We do not explicitly state a signature verification step in the pseudo-code of the algorithm to improve readability;
    58  we assume that only messages with the valid signature are considered at that level (and messages with invalid signatures
    59  are dropped).  
    60  
    61  
    62  
    63  %Messages that are being gossiped are created by the consensus layer. We can
    64      %think about consensus protocol as a content creator, which %defines what
    65      %messages should be disseminated using the gossip protocol. A correct
    66      %process creates the message for dissemination either i) %explicitly, by
    67      %invoking \emph{send} function as part of the consensus protocol or ii)
    68      %implicitly, by receiving a message from some other %process. Note that in
    69      %the case ii) gossiping of messages is implicit, i.e., it happens without
    70      %explicit send clause in the consensus algorithm %whenever a correct
    71      %process receives some messages in the consensus algorithm\footnote{If a
    72      %message is received by a correct process at %the consensus level then it
    73      %is considered valid from the protocol point of view, i.e., it has a
    74      %correct signature, a proper message structure %and a valid height and
    75      %round number.}. 
    76  
    77  %\item Processes keep resending messages (in case of failures or message loss)
    78      %until all its peers get them. This ensures that every message %sent or
    79      %received by a correct process is eventually received by all correct
    80      %processes. 
    81  
    82  \subsection{State Machine Replication}
    83  
    84  State machine replication (SMR) is a general approach for replicating services
    85  modeled as a deterministic state machine~\cite{Lam78:cacm,Sch90:survey}.  The
    86  key idea of this approach is to guarantee that all replicas start in the same
    87  state and then apply requests from clients in the same order, thereby
    88  guaranteeing that the replicas' states will not diverge.  Following
    89  Schneider~\cite{Sch90:survey}, we note that the following is key for
    90  implementing a replicated state machine tolerant to (Byzantine) faults:
    91  
    92  \begin{itemize} \item \emph{Replica Coordination.} All [non-faulty] replicas
    93      receive and process the same sequence of requests.  \end{itemize}
    94  
    95  Moreover, as Schneider also notes, this property can be decomposed into two
    96  parts, \emph{Agreement} and \emph{Order}: Agreement requires all (non-faulty)
    97  replicas to receive all requests, and Order requires that the order of received
    98  requests is the same at all replicas.
    99  
   100  There is an additional requirement that needs to be ensured by Byzantine
   101  tolerant state machine replication: only requests (called transactions in the
   102  Tendermint terminology) proposed by clients are executed. In Tendermint,
   103  transaction verification is the responsibility of the service that is being
   104  replicated; upon receiving a transaction from the client, the Tendermint
   105  process will ask the service if the request is valid, and only valid requests
   106  will be processed. 
   107  
   108   \subsection{Consensus} \label{sec:consensus}
   109  
   110  Tendermint solves state machine replication by sequentially executing consensus
   111  instances to agree on each block of transactions that are
   112  then executed by the service being replicated. We consider a variant of the
   113  Byzantine consensus problem called Validity Predicate-based Byzantine consensus
   114  that is motivated by blockchain systems~\cite{GLR17:red-belly-bc}. The problem
   115  is defined by an agreement, a termination, and a validity property.
   116  
   117   \begin{itemize} \item \emph{Agreement:} No two correct processes decide on
   118           different values.  \item \emph{Termination:} All correct processes
   119           eventually decide on a value.  \item \emph{Validity:} A decided value
   120               is valid, i.e., it satisfies the predefined predicate denoted
   121               \emph{valid()}.  \end{itemize}
   122  
   123   This variant of the Byzantine consensus problem has an application-specific
   124   \emph{valid()} predicate to indicate whether a value is valid. In the context
   125   of blockchain systems, for example, a value is not valid if it does not
   126   contain an appropriate hash of the last value (block) added to the blockchain.