You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

187 lines
6.7 KiB

  1. # Tendermint Consensus Reactor
  2. Tendermint Consensus is a distributed protocol executed by validator processes to agree on
  3. the next block to be added to the Tendermint blockchain. The protocol proceeds in rounds, where
  4. each round is a try to reach agreement on the next block. A round starts by having a dedicated
  5. process (called proposer) suggesting to other processes what should be the next block with
  6. the `ProposalMessage`.
  7. The processes respond by voting for a block with `VoteMessage` (there are two kinds of vote
  8. messages, prevote and precommit votes). Note that a proposal message is just a suggestion what the
  9. next block should be; a validator might vote with a `VoteMessage` for a different block. If in some
  10. round, enough number of processes vote for the same block, then this block is committed and later
  11. added to the blockchain. `ProposalMessage` and `VoteMessage` are signed by the private key of the
  12. validator. The internals of the protocol and how it ensures safety and liveness properties are
  13. explained in a forthcoming document.
  14. For efficiency reasons, validators in Tendermint consensus protocol do not agree directly on the
  15. block as the block size is big, i.e., they don't embed the block inside `Proposal` and
  16. `VoteMessage`. Instead, they reach agreement on the `BlockID` (see `BlockID` definition in
  17. [Blockchain](https://github.com/tendermint/spec/blob/master/spec/core/data_structures.md#blockid) section)
  18. that uniquely identifies each block. The block itself is
  19. disseminated to validator processes using peer-to-peer gossiping protocol. It starts by having a
  20. proposer first splitting a block into a number of block parts, that are then gossiped between
  21. processes using `BlockPartMessage`.
  22. Validators in Tendermint communicate by peer-to-peer gossiping protocol. Each validator is connected
  23. only to a subset of processes called peers. By the gossiping protocol, a validator send to its peers
  24. all needed information (`ProposalMessage`, `VoteMessage` and `BlockPartMessage`) so they can
  25. reach agreement on some block, and also obtain the content of the chosen block (block parts). As
  26. part of the gossiping protocol, processes also send auxiliary messages that inform peers about the
  27. executed steps of the core consensus algorithm (`NewRoundStepMessage` and `NewValidBlockMessage`), and
  28. also messages that inform peers what votes the process has seen (`HasVoteMessage`,
  29. `VoteSetMaj23Message` and `VoteSetBitsMessage`). These messages are then used in the gossiping
  30. protocol to determine what messages a process should send to its peers.
  31. We now describe the content of each message exchanged during Tendermint consensus protocol.
  32. ## ProposalMessage
  33. ProposalMessage is sent when a new block is proposed. It is a suggestion of what the
  34. next block in the blockchain should be.
  35. ```go
  36. type ProposalMessage struct {
  37. Proposal Proposal
  38. }
  39. ```
  40. ### Proposal
  41. Proposal contains height and round for which this proposal is made, BlockID as a unique identifier
  42. of proposed block, timestamp, and POLRound (a so-called Proof-of-Lock (POL) round) that is needed for
  43. termination of the consensus. If POLRound >= 0, then BlockID corresponds to the block that
  44. is locked in POLRound. The message is signed by the validator private key.
  45. ```go
  46. type Proposal struct {
  47. Height int64
  48. Round int
  49. POLRound int
  50. BlockID BlockID
  51. Timestamp Time
  52. Signature Signature
  53. }
  54. ```
  55. ## VoteMessage
  56. VoteMessage is sent to vote for some block (or to inform others that a process does not vote in the
  57. current round). Vote is defined in the
  58. [Blockchain](https://github.com/tendermint/spec/blob/master/spec/core/data_structures.md#blockidd)
  59. section and contains validator's
  60. information (validator address and index), height and round for which the vote is sent, vote type,
  61. blockID if process vote for some block (`nil` otherwise) and a timestamp when the vote is sent. The
  62. message is signed by the validator private key.
  63. ```go
  64. type VoteMessage struct {
  65. Vote Vote
  66. }
  67. ```
  68. ## BlockPartMessage
  69. BlockPartMessage is sent when gossiping a piece of the proposed block. It contains height, round
  70. and the block part.
  71. ```go
  72. type BlockPartMessage struct {
  73. Height int64
  74. Round int
  75. Part Part
  76. }
  77. ```
  78. ## NewRoundStepMessage
  79. NewRoundStepMessage is sent for every step transition during the core consensus algorithm execution.
  80. It is used in the gossip part of the Tendermint protocol to inform peers about a current
  81. height/round/step a process is in.
  82. ```go
  83. type NewRoundStepMessage struct {
  84. Height int64
  85. Round int
  86. Step RoundStepType
  87. SecondsSinceStartTime int
  88. LastCommitRound int
  89. }
  90. ```
  91. ## NewValidBlockMessage
  92. NewValidBlockMessage is sent when a validator observes a valid block B in some round r,
  93. i.e., there is a Proposal for block B and 2/3+ prevotes for the block B in the round r.
  94. It contains height and round in which valid block is observed, block parts header that describes
  95. the valid block and is used to obtain all
  96. block parts, and a bit array of the block parts a process currently has, so its peers can know what
  97. parts it is missing so they can send them.
  98. In case the block is also committed, then IsCommit flag is set to true.
  99. ```go
  100. type NewValidBlockMessage struct {
  101. Height int64
  102. Round int
  103. BlockPartsHeader PartSetHeader
  104. BlockParts BitArray
  105. IsCommit bool
  106. }
  107. ```
  108. ## ProposalPOLMessage
  109. ProposalPOLMessage is sent when a previous block is re-proposed.
  110. It is used to inform peers in what round the process learned for this block (ProposalPOLRound),
  111. and what prevotes for the re-proposed block the process has.
  112. ```go
  113. type ProposalPOLMessage struct {
  114. Height int64
  115. ProposalPOLRound int
  116. ProposalPOL BitArray
  117. }
  118. ```
  119. ## HasVoteMessage
  120. HasVoteMessage is sent to indicate that a particular vote has been received. It contains height,
  121. round, vote type and the index of the validator that is the originator of the corresponding vote.
  122. ```go
  123. type HasVoteMessage struct {
  124. Height int64
  125. Round int
  126. Type byte
  127. Index int
  128. }
  129. ```
  130. ## VoteSetMaj23Message
  131. VoteSetMaj23Message is sent to indicate that a process has seen +2/3 votes for some BlockID.
  132. It contains height, round, vote type and the BlockID.
  133. ```go
  134. type VoteSetMaj23Message struct {
  135. Height int64
  136. Round int
  137. Type byte
  138. BlockID BlockID
  139. }
  140. ```
  141. ## VoteSetBitsMessage
  142. VoteSetBitsMessage is sent to communicate the bit-array of votes a process has seen for a given
  143. BlockID. It contains height, round, vote type, BlockID and a bit array of
  144. the votes a process has.
  145. ```go
  146. type VoteSetBitsMessage struct {
  147. Height int64
  148. Round int
  149. Type byte
  150. BlockID BlockID
  151. Votes BitArray
  152. }
  153. ```