github.com/aakash4dev/cometbft@v0.38.2/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 timing assumptions of Tendermint consensus algorithm.
    22  We will postulate a timing restriction, which, if satisfied, ensures that liveness is preserved.
    23  
    24  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.
    25  
    26  
    27  #### **[PBTS-MSG-D.0]**
    28  
    29  There exists a system parameter `MSGDELAY` for message end-to-end delays **counted in clock-time**.
    30  
    31  > Observe that [PBTS-MSG-D.0] imposes constraints on message delays as well as on the clock.
    32  
    33  #### **[PBTS-MSG-FAIR.0]**
    34  
    35  The message end-to-end delay between a correct proposer and a correct validator (for `PROPOSE` messages) is less than `MSGDELAY`.
    36  
    37  
    38  ## Problem Statement
    39  
    40  In this section we define the properties of Tendermint consensus algorithm (cf. the [arXiv paper][arXiv]) in this new system model.
    41  
    42  #### **[PBTS-PROPOSE.0]**
    43  
    44  A proposer proposes a pair `(v,t)` of consensus value `v` and time `t`.
    45  
    46  > We then restrict the allowed decisions along the following lines:
    47  
    48  #### **[PBTS-INV-AGREEMENT.0]**
    49  
    50  [Agreement] No two correct validators decide on different values `v`.
    51  
    52  #### **[PBTS-INV-TIME-VAL.0]**
    53  
    54  [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.
    55  
    56  However, the properties of Tendermint consensus algorithm 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.  
    57  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:
    58  
    59  #### **[PBTS-INV-TIME-AGR.0]**
    60  
    61  [Time-Agreement] If two correct validators decide in the same round, then they decide on the same `t`.
    62  
    63  #### **[PBTS-DECISION-ROUND.0]**
    64  
    65  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,
    66  as validators may decide in different rounds, they may decide on different times.
    67  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".
    68  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`.
    69  However, as most consensus instances terminate within one round on the Cosmos hub, this is hardly ever observed in practice.
    70  
    71  
    72  
    73  Finally, observe that the agreement ([Agreement] and [Time-Agreement]) properties are based on the Cosmos security model [CMBC-FM-2THIRDS.0][CMBC-FM-2THIRDS-link] of more than 2/3 correct validators, while [Time-Validity] is based on more than 1/3 correct validators.
    74  
    75  ### SAFETY
    76  
    77  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).
    78  
    79  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`.
    80  
    81  Let
    82  
    83  - `beginConsensus(k)` be the minimum over `beginConsensus(V,k)`, and
    84  - `last-beginConsensus(k)` be the maximum over `beginConsensus(V,k)`, and
    85  - `endConsensus(k)` the maximum over `endConsensus(V,k)`
    86  
    87  for all correct validators `V`.
    88  
    89  > Observe that `beginConsensus(k) <= last-beginConsensus(k)` and if local clocks are monotonic, then `last-beginConsensus(k) <= endConsensus(k)`.
    90  
    91  #### **[PBTS-CLOCK-GROW.0]**
    92  
    93  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)`.
    94  
    95  
    96  #### **[PBTS-CONSENSUS-TIME-VALID.0]**
    97  
    98  If
    99  
   100  - there is a valid commit `c` for height `k`, and
   101  - `c` contains a `PRECOMMIT` message by at least one correct validator,
   102  
   103  then the time `b.time` in the block `b` that is signed by `c` satisfies
   104  
   105  - `beginConsensus(k) - PRECISION <= b.time < endConsensus(k) + PRECISION + MSGDELAY`.
   106  
   107  
   108  > [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
   109  
   110  #### **[PBTS-CONSENSUS-LIVE-VALID-CORR-PROP.0]**
   111  
   112  If the proposer of round 1 is correct, and
   113  
   114  - [CMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
   115  - [PBTS-MSG-FAIR.0], and
   116  - [PBTS-CLOCK-PRECISION.0], and
   117  - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
   118  
   119  then eventually (within bounded time) every correct validator decides in round 1.
   120  
   121  #### **[PBTS-CONSENSUS-SAFE-VALID-CORR-PROP.0]**
   122  
   123  If the proposer of round 1 is correct, and
   124  
   125  - [CMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
   126  - [PBTS-MSG-FAIR.0], and
   127  - [PBTS-CLOCK-PRECISION.0], and
   128  - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
   129  
   130  then `beginConsensus_k <= b.time <= last-beginConsensus_k`.
   131  
   132  
   133  > For the above two properties we will assume that a correct proposer `v` sends its `PROPOSAL` at its local time `beginConsensus(v,k)`.
   134  
   135  ### LIVENESS
   136  
   137  If
   138  
   139  - [CMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
   140  - [PBTS-MSG-FAIR.0],
   141  - [PBTS-CLOCK.0], and
   142  - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
   143  
   144  then eventually there is a valid commit `c` for height `k`.
   145  
   146  
   147  ### REAL-TIME SAFETY
   148  
   149  > 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:
   150  
   151  #### **[PBTS-CLOCKSYNC-EXTERNAL.0]**
   152  
   153  There is a system parameter `ACCURACY`, such that for all real-times `t` and all correct validators `V`,
   154  
   155  - `| C_V(t) - t | < ACCURACY`.
   156  
   157  > `ACCURACY` is not necessarily visible at the code level. The properties below just show that the smaller
   158  its value, the closer the block time will be to real-time
   159  
   160  #### **[PBTS-CONSENSUS-PTIME.0]**
   161  
   162  LET `m` be a propose message. We consider the following two real-times `proposalTime(m)` and `propRecvTime(m)`:
   163  
   164  - if the proposer is correct and sends `m` at time `t`, we write `proposalTime(m)` for real-time `t`.
   165  - if first correct validator receives `m` at time `t`, we write `propRecvTime(m)` for real-time `t`.
   166  
   167  
   168  #### **[PBTS-CONSENSUS-REALTIME-VALID.0]**
   169  
   170  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:
   171  
   172  `propRecvTime(m) - ACCURACY - PRECISION < b.time < propRecvTime(m) + ACCURACY + PRECISION + MSGDELAY`
   173  
   174  
   175  #### **[PBTS-CONSENSUS-REALTIME-VALID-CORR.0]**
   176  
   177  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:
   178  
   179  `proposalTime(m) - ACCURACY < b.time < proposalTime(m) + ACCURACY`
   180  
   181  > by the algorithm at time `proposalTime(m)` the proposer fixes `m.time <- now_p(proposalTime(m))`
   182  
   183  > "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`.
   184  
   185  Back to [main document][main].
   186  
   187  [main]: ./pbts_001_draft.md
   188  
   189  [arXiv]: https://arxiv.org/abs/1807.04938
   190  
   191  [CMBC-FM-2THIRDS-link]: https://github.com/aakash4dev/cometbft/blob/main/spec/light-client/verification/verification_002_draft.md#cmbc-fm-2thirds1