github.com/ari-anchor/sei-tendermint@v0.0.0-20230519144642-dc826b7b56bb/docs/tendermint-core/consensus/README.md (about)

     1  ---
     2  order: 1
     3  parent:
     4    title: Consensus
     5    order: 6
     6  ---
     7  
     8  # Consensus
     9  
    10  Tendermint Consensus is a distributed protocol executed by validator processes to agree on
    11  the next block to be added to the Tendermint blockchain. The protocol proceeds in rounds, where
    12  each round is a try to reach agreement on the next block. A round starts by having a dedicated
    13  process (called proposer) suggesting to other processes what should be the next block with
    14  the `ProposalMessage`.
    15  The processes respond by voting for a block with `VoteMessage` (there are two kinds of vote
    16  messages, prevote and precommit votes). Note that a proposal message is just a suggestion what the
    17  next block should be; a validator might vote with a `VoteMessage` for a different block. If in some
    18  round, enough number of processes vote for the same block, then this block is committed and later
    19  added to the blockchain. `ProposalMessage` and `VoteMessage` are signed by the private key of the
    20  validator. The internals of the protocol and how it ensures safety and liveness properties are
    21  explained in a forthcoming document.
    22  
    23  For efficiency reasons, validators in Tendermint consensus protocol do not agree directly on the
    24  block as the block size is big, i.e., they don't embed the block inside `Proposal` and
    25  `VoteMessage`. Instead, they reach agreement on the `BlockID` (see `BlockID` definition in
    26  [Blockchain](https://github.com/tendermint/tendermint/blob/master/spec/core/data_structures.md#blockid) section)
    27  that uniquely identifies each block. The block itself is
    28  disseminated to validator processes using peer-to-peer gossiping protocol. It starts by having a
    29  proposer first splitting a block into a number of block parts, that are then gossiped between
    30  processes using `BlockPartMessage`.
    31  
    32  Validators in Tendermint communicate by peer-to-peer gossiping protocol. Each validator is connected
    33  only to a subset of processes called peers. By the gossiping protocol, a validator send to its peers
    34  all needed information (`ProposalMessage`, `VoteMessage` and `BlockPartMessage`) so they can
    35  reach agreement on some block, and also obtain the content of the chosen block (block parts). As
    36  part of the gossiping protocol, processes also send auxiliary messages that inform peers about the
    37  executed steps of the core consensus algorithm (`NewRoundStepMessage` and `NewValidBlockMessage`), and
    38  also messages that inform peers what votes the process has seen (`HasVoteMessage`,
    39  `VoteSetMaj23Message` and `VoteSetBitsMessage`). These messages are then used in the gossiping
    40  protocol to determine what messages a process should send to its peers.
    41  
    42  We now describe the content of each message exchanged during Tendermint consensus protocol.