github.com/KYVENetwork/cometbft/v38@v38.0.3/spec/consensus/proposer-based-timestamp/pbts_001_draft.md (about) 1 # Proposer-Based Time 2 3 ## Current BFTTime 4 5 ### Description 6 7 In CometBFT, the first version of how time is computed and stored in a block works as follows: 8 9 - validators send their current local time as part of `precommit` messages 10 - 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. 11 12 ### Analysis 13 14 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. 15 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.) 16 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 17 `2f + 1` correct validators. 18 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` 19 of the voting power in order to compute the median. 20 1. If the validators decide in different rounds, the proposer can decide on which round the median computation is based. 21 1. **Liveness.** The liveness of the protocol: 22 1. does not depend on clock synchronization, 23 1. depends on bounded message delays. 24 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. 25 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. 26 27 ## Suggested Proposer-Based Time 28 29 ### Outline 30 31 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). 32 33 This proposed solution adds the requirement of having synchronized clocks, and other implicit assumptions. 34 35 ### Comparison of the Suggested Method to the Old One 36 37 1. **Fault tolerance.** Maintained in the suggested protocol. 38 1. **Effect of faulty validators.** Eliminated in the suggested protocol, 39 that is, the block `time` can be corrupted only in the extreme case when 40 `>2/3` of the validators are faulty. 41 1. **Proposer influence on block time.** The proposer of the next block 42 has less freedom when choosing the block time. 43 1. This scenario is eliminated in the suggested protocol, provided that there are `<1/3` faulty validators. 44 1. This scenario is still there. 45 1. **Liveness.** The liveness of the suggested protocol: 46 1. depends on the introduced assumptions on synchronized clocks (see below), 47 1. still depends on the message delays (unavoidable). 48 1. **Relation to real time.** We formalize clock synchronization, and obtain a **well-defined relation** between the block `time` and real time. 49 1. **Aggregate signatures.** The `precommit` messages free of time, which **allows** for aggregate signatures. 50 51 ### Protocol Overview 52 53 #### Proposed Time 54 55 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`. 56 57 #### Reception Step 58 59 In the reception step at node `p` at local time `now_p`, upon receiving a message `m`: 60 61 - **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`. 62 (`PRECISION` and `MSGDELAY` being system parameters, see [below](#safety-and-liveness)) 63 64 > 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. 65 66 #### Processing Step 67 68 - Start round 69 70 <table> 71 <tr> 72 <th>arXiv paper</th> 73 <th>Proposer-based time</th> 74 </tr> 75 76 <tr> 77 <td> 78 79 ```go 80 function StartRound(round) { 81 round_p ← round 82 step_p ← propose 83 if proposer(h_p, round_p) = p { 84 85 86 if validValue_p != nil { 87 88 proposal ← validValue_p 89 } else { 90 91 proposal ← getValue() 92 } 93 broadcast ⟨PROPOSAL, h_p, round_p, proposal, validRound_p⟩ 94 } else { 95 schedule OnTimeoutPropose(h_p,round_p) to 96 be executed after timeoutPropose(round_p) 97 } 98 } 99 ``` 100 101 </td> 102 103 <td> 104 105 ```go 106 function StartRound(round) { 107 round_p ← round 108 step_p ← propose 109 if proposer(h_p, round_p) = p { 110 // new wait condition 111 wait until now_p > block time of block h_p - 1 112 if validValue_p != nil { 113 // add "now_p" 114 proposal ← (validValue_p, now_p) 115 } else { 116 // add "now_p" 117 proposal ← (getValue(), now_p) 118 } 119 broadcast ⟨PROPOSAL, h_p, round_p, proposal, validRound_p⟩ 120 } else { 121 schedule OnTimeoutPropose(h_p,round_p) to 122 be executed after timeoutPropose(round_p) 123 } 124 } 125 ``` 126 127 </td> 128 </tr> 129 </table> 130 131 - Rule on lines 28-35 132 133 <table> 134 <tr> 135 <th>arXiv paper</th> 136 <th>Proposer-based time</th> 137 </tr> 138 139 <tr> 140 <td> 141 142 ```go 143 upon timely(⟨PROPOSAL, h_p, round_p, v, vr⟩) 144 from proposer(h_p, round_p) 145 AND 2f + 1 ⟨PREVOTE, h_p, vr, id(v)⟩ 146 while step_p = propose ∧ (vr ≥ 0 ∧ vr < round_p) do { 147 if valid(v) ∧ (lockedRound_p ≤ vr ∨ lockedValue_p = v) { 148 149 broadcast ⟨PREVOTE, h_p, round_p, id(v)⟩ 150 } else { 151 broadcast ⟨PREVOTE, hp, round_p, nil⟩ 152 } 153 } 154 ``` 155 156 </td> 157 158 <td> 159 160 ```go 161 upon timely(⟨PROPOSAL, h_p, round_p, (v, tprop), vr⟩) 162 from proposer(h_p, round_p) 163 AND 2f + 1 ⟨PREVOTE, h_p, vr, id(v, tvote)⟩ 164 while step_p = propose ∧ (vr ≥ 0 ∧ vr < round_p) do { 165 if valid(v) ∧ (lockedRound_p ≤ vr ∨ lockedValue_p = v) { 166 // send hash of v and tprop in PREVOTE message 167 broadcast ⟨PREVOTE, h_p, round_p, id(v, tprop)⟩ 168 } else { 169 broadcast ⟨PREVOTE, hp, round_p, nil⟩ 170 } 171 } 172 ``` 173 174 </td> 175 </tr> 176 </table> 177 178 - Rule on lines 49-54 179 180 <table> 181 <tr> 182 <th>arXiv paper</th> 183 <th>Proposer-based time</th> 184 </tr> 185 186 <tr> 187 <td> 188 189 ```go 190 upon ⟨PROPOSAL, h_p, r, v, ∗⟩ from proposer(h_p, r) 191 AND 2f + 1 ⟨PRECOMMIT, h_p, r, id(v)⟩ 192 while decisionp[h_p] = nil do { 193 if valid(v) { 194 195 decision_p [h_p] = v 196 h_p ← h_p + 1 197 reset lockedRound_p , lockedValue_p, validRound_p and 198 validValue_p to initial values and empty message log 199 StartRound(0) 200 } 201 } 202 ``` 203 204 </td> 205 206 <td> 207 208 ```go 209 upon ⟨PROPOSAL, h_p, r, (v,t), ∗⟩ from proposer(h_p, r) 210 AND 2f + 1 ⟨PRECOMMIT, h_p, r, id(v,t)⟩ 211 while decisionp[h_p] = nil do { 212 if valid(v) { 213 // decide on time too 214 decision_p [h_p] = (v,t) 215 h_p ← h_p + 1 216 reset lockedRound_p , lockedValue_p, validRound_p and 217 validValue_p to initial values and empty message log 218 StartRound(0) 219 } 220 } 221 ``` 222 223 </td> 224 </tr> 225 </table> 226 227 - Other rules are extended in a similar way, or remain unchanged 228 229 ### Property Overview 230 231 #### Safety and Liveness 232 233 For safety (Point 1, Point 2, Point 3i) and liveness (Point 4) we need 234 the following assumptions: 235 236 - 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, 237 i.e., `|C_V(t) - C_W(t)| < PRECISION` 238 - The message end-to-end delay between a correct proposer and a correct validator (for `PROPOSE` messages) is less than `MSGDELAY`. 239 240 #### Relation to Real-Time 241 242 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`. 243 244 > `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. 245 > 246 > Note that `PRECISION` and `MSGDELAY` show up in the code. 247 248 ### Detailed Specification 249 250 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. 251 252 - [Part I - System Model and Properties][sysmodel] 253 - [Part II - Protocol specification][algorithm] 254 - [TLA+ Specification][proposertla] 255 256 [arXiv]: https://arxiv.org/abs/1807.04938 257 258 [tlatender]: ../../light-client/accountability/README.md 259 260 [bfttime]: ../bft-time.md 261 262 [lcspec]: ../../light-client/README.md 263 264 [algorithm]: ./pbts-algorithm_001_draft.md 265 266 [sysmodel]: ./pbts-sysmodel_001_draft.md 267 268 269 [proposertla]: ./tla/TendermintPBT_001_draft.tla