github.com/vipernet-xyz/tm@v0.34.24/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md (about) 1 # Proposer-Based Time - Part I 2 3 ## System Model 4 5 ### Time and Clocks 6 7 #### **[PBTS-CLOCK-NEWTON.0]** 8 9 There is a reference Newtonian real-time `t` (UTC). 10 11 Every correct validator `V` maintains a synchronized clock `C_V` that ensures: 12 13 #### **[PBTS-CLOCK-PRECISION.0]** 14 15 There exists a system parameter `PRECISION` such that for any two correct validators `V` and `W`, and at any real-time `t`, 16 `|C_V(t) - C_W(t)| < PRECISION` 17 18 19 ### Message Delays 20 21 We do not want to interfere with the Tendermint timing assumptions. We will postulate a timing restriction, which, if satisfied, ensures that liveness is preserved. 22 23 In general the local clock may drift from the global time. (It may progress faster, e.g., one second of clock time might take 1.005 seconds of real-time). As a result the local clock and the global clock may be measured in different time units. Usually, the message delay is measured in global clock time units. To estimate the correct local timeout precisely, we would need to estimate the clock time duration of a message delay taking into account the clock drift. For simplicity we ignore this, and directly postulate the message delay assumption in terms of local time. 24 25 26 #### **[PBTS-MSG-D.0]** 27 28 There exists a system parameter `MSGDELAY` for message end-to-end delays **counted in clock-time**. 29 30 > Observe that [PBTS-MSG-D.0] imposes constraints on message delays as well as on the clock. 31 32 #### **[PBTS-MSG-FAIR.0]** 33 34 The message end-to-end delay between a correct proposer and a correct validator (for `PROPOSE` messages) is less than `MSGDELAY`. 35 36 37 ## Problem Statement 38 39 In this section we define the properties of Tendermint consensus (cf. the [arXiv paper][arXiv]) in this new system model. 40 41 #### **[PBTS-PROPOSE.0]** 42 43 A proposer proposes a pair `(v,t)` of consensus value `v` and time `t`. 44 45 > We then restrict the allowed decisions along the following lines: 46 47 #### **[PBTS-INV-AGREEMENT.0]** 48 49 [Agreement] No two correct validators decide on different values `v`. 50 51 #### **[PBTS-INV-TIME-VAL.0]** 52 53 [Time-Validity] If a correct validator decides on `t` then `t` is "OK" (we will formalize this below), even if up to `2f` validators are faulty. 54 55 However, the properties of Tendermint consensus are of more interest with respect to the blocks, that is, what is written into a block and when. We therefore, in the following, will give the safety and liveness properties from this block-centric viewpoint. 56 For this, observe that the time `t` decided at consensus height `k` will be written in the block of height `k+1`, and will be supported by `2f + 1` `PRECOMMIT` messages of the same consensus round `r`. The time written in the block, we will denote by `b.time` (to distinguish it from the term `bfttime` used for median-based time). For this, it is important to have the following consensus algorithm property: 57 58 #### **[PBTS-INV-TIME-AGR.0]** 59 60 [Time-Agreement] If two correct validators decide in the same round, then they decide on the same `t`. 61 62 #### **[PBTS-DECISION-ROUND.0]** 63 64 Note that the relation between consensus decisions, on the one hand, and blocks, on the other hand, is not immediate; in particular if we consider time: In the proposed solution, 65 as validators may decide in different rounds, they may decide on different times. 66 The proposer of the next block, may pick a commit (at least `2f + 1` `PRECOMMIT` messages from one round), and thus it picks a decision round that is going to become "canonic". 67 As a result, the proposer implicitly has a choice of one of the times that belong to rounds in which validators decided. Observe that this choice was implicitly the case already in the median-based `bfttime`. 68 However, as most consensus instances terminate within one round on the Cosmos hub, this is hardly ever observed in practice. 69 70 71 72 Finally, observe that the agreement ([Agreement] and [Time-Agreement]) properties are based on the Tendermint security model [TMBC-FM-2THIRDS.0] of more than 2/3 correct validators, while [Time-Validity] is based on more than 1/3 correct validators. 73 74 ### SAFETY 75 76 Here we will provide specifications that relate local time to block time. However, since we do not assume (by now) that local time is linked to real-time, these specifications also do not provide a relation between block time and real-time. Such properties are given [later](#REAL-TIME-SAFETY). 77 78 For a correct validator `V`, let `beginConsensus(V,k)` be the local time when it sets its height to `k`, and let `endConsensus(V,k)` be the time when it sets its height to `k + 1`. 79 80 Let 81 82 - `beginConsensus(k)` be the minimum over `beginConsensus(V,k)`, and 83 - `last-beginConsensus(k)` be the maximum over `beginConsensus(V,k)`, and 84 - `endConsensus(k)` the maximum over `endConsensus(V,k)` 85 86 for all correct validators `V`. 87 88 > Observe that `beginConsensus(k) <= last-beginConsensus(k)` and if local clocks are monotonic, then `last-beginConsensus(k) <= endConsensus(k)`. 89 90 #### **[PBTS-CLOCK-GROW.0]** 91 92 We assume that during one consensus instance, local clocks are not set back, in particular for each correct validator `V` and each height `k`, we have `beginConsensus(V,k) < endConsensus(V,k)`. 93 94 95 #### **[PBTS-CONSENSUS-TIME-VALID.0]** 96 97 If 98 99 - there is a valid commit `c` for height `k`, and 100 - `c` contains a `PRECOMMIT` message by at least one correct validator, 101 102 then the time `b.time` in the block `b` that is signed by `c` satisfies 103 104 - `beginConsensus(k) - PRECISION <= b.time < endConsensus(k) + PRECISION + MSGDELAY`. 105 106 107 > [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain 108 109 #### **[PBTS-CONSENSUS-LIVE-VALID-CORR-PROP.0]** 110 111 If the proposer of round 1 is correct, and 112 113 - [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and 114 - [PBTS-MSG-FAIR.0], and 115 - [PBTS-CLOCK-PRECISION.0], and 116 - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?) 117 118 then eventually (within bounded time) every correct validator decides in round 1. 119 120 #### **[PBTS-CONSENSUS-SAFE-VALID-CORR-PROP.0]** 121 122 If the proposer of round 1 is correct, and 123 124 - [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and 125 - [PBTS-MSG-FAIR.0], and 126 - [PBTS-CLOCK-PRECISION.0], and 127 - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?) 128 129 then `beginConsensus_k <= b.time <= last-beginConsensus_k`. 130 131 132 > For the above two properties we will assume that a correct proposer `v` sends its `PROPOSAL` at its local time `beginConsensus(v,k)`. 133 134 ### LIVENESS 135 136 If 137 138 - [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and 139 - [PBTS-MSG-FAIR.0], 140 - [PBTS-CLOCK.0], and 141 - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?) 142 143 then eventually there is a valid commit `c` for height `k`. 144 145 146 ### REAL-TIME SAFETY 147 148 > We want to give a property that can be exploited from the outside, that is, given a block with some time stored in it, what is the estimate at which real-time the block was generated. To do so, we need to link clock-time to real-time; which is not the case with [PBTS-CLOCK.0]. For this, we introduce the following assumption on the clocks: 149 150 #### **[PBTS-CLOCKSYNC-EXTERNAL.0]** 151 152 There is a system parameter `ACCURACY`, such that for all real-times `t` and all correct validators `V`, 153 154 - `| C_V(t) - t | < ACCURACY`. 155 156 > `ACCURACY` is not necessarily visible at the code level. The properties below just show that the smaller 157 its value, the closer the block time will be to real-time 158 159 #### **[PBTS-CONSENSUS-PTIME.0]** 160 161 LET `m` be a propose message. We consider the following two real-times `proposalTime(m)` and `propRecvTime(m)`: 162 163 - if the proposer is correct and sends `m` at time `t`, we write `proposalTime(m)` for real-time `t`. 164 - if first correct validator receives `m` at time `t`, we write `propRecvTime(m)` for real-time `t`. 165 166 167 #### **[PBTS-CONSENSUS-REALTIME-VALID.0]** 168 169 Let `b` be a block with a valid commit that contains at least one `precommit` message by a correct validator (and `proposalTime` is the time for the height/round `propose` message `m` that triggered the `precommit`). Then: 170 171 `propRecvTime(m) - ACCURACY - PRECISION < b.time < propRecvTime(m) + ACCURACY + PRECISION + MSGDELAY` 172 173 174 #### **[PBTS-CONSENSUS-REALTIME-VALID-CORR.0]** 175 176 Let `b` be a block with a valid commit that contains at least one `precommit` message by a correct validator (and `proposalTime` is the time for the height/round `propose` message `m` that triggered the `precommit`). Then, if the proposer is correct: 177 178 `proposalTime(m) - ACCURACY < b.time < proposalTime(m) + ACCURACY` 179 180 > by the algorithm at time `proposalTime(m)` the proposer fixes `m.time <- now_p(proposalTime(m))` 181 182 > "triggered the `PRECOMMIT`" implies that the data in `m` and `b` are "matching", that is, `m` proposed the values that are actually stored in `b`. 183 184 Back to [main document][main]. 185 186 [main]: ./pbts_001_draft.md 187 188 [arXiv]: https://arxiv.org/abs/1807.04938 189 190 [tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md 191 192 [bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md 193 194 [lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md 195 196 [algorithm]: ./pbts-algorithm_001_draft.md 197 198 [sysmodel]: ./pbts-sysmodel_001_draft.md