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.

267 lines
9.0 KiB

  1. <!-- markdown-link-check-disable -->
  2. # Proposer-Based Time (first draft)
  3. ## Current BFTTime
  4. ### Description
  5. In Tendermint consensus, the first version of how time is computed and stored in a block works as follows:
  6. - validators send their current local time as part of `precommit` messages
  7. - upon collecting the `precommit` messages that the proposer uses to build a commit to be put in the next block, the proposer computes the `time` of the next block as the median (weighted over voting power) of the times in the `precommit` messages.
  8. ### Analysis
  9. 1. **Fault tolerance.** The computed median time is called [`bfttime`][bfttime] as it is indeed fault-tolerant: if **less than a third** of the validators is faulty (counted in voting power), it is guaranteed that the computed time lies between the minimum and the maximum times sent by correct validators.
  10. 1. **Effect of faulty validators.** If more than `1/2` of the voting power (which is in fact more than one third and less than two thirds of the voting power) is held by faulty validators, then the time is under total control of the faulty validators. (This is particularly challenging in the context of [lightclient][lcspec] security.)
  11. 1. **Proposer influence on block time.** The proposer of the next block has a degree of freedom in choosing the `bfttime`, since it computes the median time based on the timestamps from `precommit` messages sent by
  12. `2f + 1` correct validators.
  13. 1. If there are `n` different timestamps in the `precommit` messages, the proposer can use any subset of timestamps that add up to `2f + 1`
  14. of the voting power in order to compute the median.
  15. 1. If the validators decide in different rounds, the proposer can decide on which round the median computation is based.
  16. 1. **Liveness.** The liveness of the protocol:
  17. 1. does not depend on clock synchronization,
  18. 1. depends on bounded message delays.
  19. 1. **Relation to real time.** There is no clock synchronizaton, which implies that there is **no relation** between the computed block `time` and real time.
  20. 1. **Aggregate signatures.** As the `precommit` messages contain the local times, all these `precommit` messages typically differ in the time field, which **prevents** the use of aggregate signatures.
  21. ## Suggested Proposer-Based Time
  22. ### Outline
  23. An alternative approach to time has been discussed: Rather than having the validators send the time in the `precommit` messages, the proposer in the consensus algorithm sends its time in the `propose` message, and the validators locally check whether the time is OK (by comparing to their local clock).
  24. This proposed solution adds the requirement of having synchronized clocks, and other implicit assumptions.
  25. ### Comparison of the Suggested Method to the Old One
  26. 1. **Fault tolerance.** Maintained in the suggested protocol.
  27. 1. **Effect of faulty validators.** Eliminated in the suggested protocol,
  28. that is, the block `time` can be corrupted only in the extreme case when
  29. `>2/3` of the validators are faulty.
  30. 1. **Proposer influence on block time.** The proposer of the next block
  31. has less freedom when choosing the block time.
  32. 1. This scenario is eliminated in the suggested protocol, provided that there are `<1/3` faulty validators.
  33. 1. This scenario is still there.
  34. 1. **Liveness.** The liveness of the suggested protocol:
  35. 1. depends on the introduced assumptions on synchronized clocks (see below),
  36. 1. still depends on the message delays (unavoidable).
  37. 1. **Relation to real time.** We formalize clock synchronization, and obtain a **well-defined relation** between the block `time` and real time.
  38. 1. **Aggregate signatures.** The `precommit` messages free of time, which **allows** for aggregate signatures.
  39. ### Protocol Overview
  40. #### Proposed Time
  41. We assume that the field `proposal` in the `PROPOSE` message is a pair `(v, time)`, of the proposed consensus value `v` and the proposed time `time`.
  42. #### Reception Step
  43. In the reception step at node `p` at local time `now_p`, upon receiving a message `m`:
  44. - **if** the message `m` is of type `PROPOSE` and satisfies `now_p - PRECISION < m.time < now_p + PRECISION + MSGDELAY`, then mark the message as `timely`.
  45. (`PRECISION` and `MSGDELAY` being system parameters, see [below](#safety-and-liveness))
  46. > after the presentation in the dev session, we realized that different semantics for the reception step is closer aligned to the implementation. Instead of dropping propose messages, we keep all of them, and mark timely ones.
  47. #### Processing Step
  48. - Start round
  49. <table>
  50. <tr>
  51. <th>arXiv paper</th>
  52. <th>Proposer-based time</th>
  53. </tr>
  54. <tr>
  55. <td>
  56. ```go
  57. function StartRound(round) {
  58. round_p ← round
  59. step_p ← propose
  60. if proposer(h_p, round_p) = p {
  61. if validValue_p != nil {
  62. proposal ← validValue_p
  63. } else {
  64. proposal ← getValue()
  65. }
  66. broadcast ⟨PROPOSAL, h_p, round_p, proposal, validRound_p⟩
  67. } else {
  68. schedule OnTimeoutPropose(h_p,round_p) to
  69. be executed after timeoutPropose(round_p)
  70. }
  71. }
  72. ```
  73. </td>
  74. <td>
  75. ```go
  76. function StartRound(round) {
  77. round_p ← round
  78. step_p ← propose
  79. if proposer(h_p, round_p) = p {
  80. // new wait condition
  81. wait until now_p > block time of block h_p - 1
  82. if validValue_p != nil {
  83. // add "now_p"
  84. proposal ← (validValue_p, now_p)
  85. } else {
  86. // add "now_p"
  87. proposal ← (getValue(), now_p)
  88. }
  89. broadcast ⟨PROPOSAL, h_p, round_p, proposal, validRound_p⟩
  90. } else {
  91. schedule OnTimeoutPropose(h_p,round_p) to
  92. be executed after timeoutPropose(round_p)
  93. }
  94. }
  95. ```
  96. </td>
  97. </tr>
  98. </table>
  99. - Rule on lines 28-35
  100. <table>
  101. <tr>
  102. <th>arXiv paper</th>
  103. <th>Proposer-based time</th>
  104. </tr>
  105. <tr>
  106. <td>
  107. ```go
  108. upon timely(⟨PROPOSAL, h_p, round_p, v, vr⟩)
  109. from proposer(h_p, round_p)
  110. AND 2f + 1 ⟨PREVOTE, h_p, vr, id(v)⟩
  111. while step_p = propose ∧ (vr ≥ 0 ∧ vr < round_p) do {
  112. if valid(v) ∧ (lockedRound_p ≤ vr ∨ lockedValue_p = v) {
  113. broadcast ⟨PREVOTE, h_p, round_p, id(v)⟩
  114. } else {
  115. broadcast ⟨PREVOTE, hp, round_p, nil⟩
  116. }
  117. }
  118. ```
  119. </td>
  120. <td>
  121. ```go
  122. upon timely(⟨PROPOSAL, h_p, round_p, (v, tprop), vr⟩)
  123. from proposer(h_p, round_p)
  124. AND 2f + 1 ⟨PREVOTE, h_p, vr, id(v, tvote)⟩
  125. while step_p = propose ∧ (vr ≥ 0 ∧ vr < round_p) do {
  126. if valid(v) ∧ (lockedRound_p ≤ vr ∨ lockedValue_p = v) {
  127. // send hash of v and tprop in PREVOTE message
  128. broadcast ⟨PREVOTE, h_p, round_p, id(v, tprop)⟩
  129. } else {
  130. broadcast ⟨PREVOTE, hp, round_p, nil⟩
  131. }
  132. }
  133. ```
  134. </td>
  135. </tr>
  136. </table>
  137. - Rule on lines 49-54
  138. <table>
  139. <tr>
  140. <th>arXiv paper</th>
  141. <th>Proposer-based time</th>
  142. </tr>
  143. <tr>
  144. <td>
  145. ```go
  146. upon ⟨PROPOSAL, h_p, r, v, ∗⟩ from proposer(h_p, r)
  147. AND 2f + 1 ⟨PRECOMMIT, h_p, r, id(v)⟩
  148. while decisionp[h_p] = nil do {
  149. if valid(v) {
  150. decision_p [h_p] = v
  151. h_p ← h_p + 1
  152. reset lockedRound_p , lockedValue_p, validRound_p and
  153. validValue_p to initial values and empty message log
  154. StartRound(0)
  155. }
  156. }
  157. ```
  158. </td>
  159. <td>
  160. ```go
  161. upon ⟨PROPOSAL, h_p, r, (v,t), ∗⟩ from proposer(h_p, r)
  162. AND 2f + 1 ⟨PRECOMMIT, h_p, r, id(v,t)⟩
  163. while decisionp[h_p] = nil do {
  164. if valid(v) {
  165. // decide on time too
  166. decision_p [h_p] = (v,t)
  167. h_p ← h_p + 1
  168. reset lockedRound_p , lockedValue_p, validRound_p and
  169. validValue_p to initial values and empty message log
  170. StartRound(0)
  171. }
  172. }
  173. ```
  174. </td>
  175. </tr>
  176. </table>
  177. - Other rules are extended in a similar way, or remain unchanged
  178. ### Property Overview
  179. #### Safety and Liveness
  180. For safety (Point 1, Point 2, Point 3i) and liveness (Point 4) we need
  181. the following assumptions:
  182. - There exists a system parameter `PRECISION` such that for any two correct validators `V` and `W`, and at any real-time `t`, their local times `C_V(t)` and `C_W(t)` differ by less than `PRECISION` time units,
  183. i.e., `|C_V(t) - C_W(t)| < PRECISION`
  184. - The message end-to-end delay between a correct proposer and a correct validator (for `PROPOSE` messages) is less than `MSGDELAY`.
  185. #### Relation to Real-Time
  186. For analyzing real-time safety (Point 5), we use a system parameter `ACCURACY`, such that for all real-times `t` and all correct validators `V`, we have `| C_V(t) - t | < ACCURACY`.
  187. > `ACCURACY` is not necessarily visible at the code level. We might even view `ACCURACY` as variable over time. The smaller it is during a consensus instance, the closer the block time will be to real-time.
  188. >
  189. > Note that `PRECISION` and `MSGDELAY` show up in the code.
  190. ### Detailed Specification
  191. This specification describes the changes needed to be done to the Tendermint consensus algorithm as described in the [arXiv paper][arXiv] and the simplified specification in [TLA+][tlatender], and makes precise the underlying assumptions and the required properties.
  192. - [Part I - System Model and Properties][sysmodel_v1]
  193. - [Part II - Protocol specification][algorithm_v1]
  194. - [TLA+ Specification][proposertla]
  195. [algorithm_v1]: ./pbts-algorithm_001_draft.md
  196. [sysmodel_v1]: ./pbts-sysmodel_001_draft.md
  197. [proposertla]: ../tla/TendermintPBT_001_draft.tla
  198. [bfttime]: ../../bft-time.md
  199. [tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md
  200. [lcspec]: ../../light-client/
  201. [arXiv]: https://arxiv.org/abs/1807.04938