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.

194 lines
8.9 KiB

  1. # PBTS: System Model and Properties (first draft)
  2. This specification is **OUTDATED**. Please refer to the [new version][sysmodel].
  3. ## System Model
  4. ### Time and Clocks
  5. #### **[PBTS-CLOCK-NEWTON.0]**
  6. There is a reference Newtonian real-time `t` (UTC).
  7. Every correct validator `V` maintains a synchronized clock `C_V` that ensures:
  8. #### **[PBTS-CLOCK-PRECISION.0]**
  9. There exists a system parameter `PRECISION` such that for any two correct validators `V` and `W`, and at any real-time `t`,
  10. `|C_V(t) - C_W(t)| < PRECISION`
  11. ### Message Delays
  12. 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.
  13. 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.
  14. #### **[PBTS-MSG-D.0]**
  15. There exists a system parameter `MSGDELAY` for message end-to-end delays **counted in clock-time**.
  16. > Observe that [PBTS-MSG-D.0] imposes constraints on message delays as well as on the clock.
  17. #### **[PBTS-MSG-FAIR.0]**
  18. The message end-to-end delay between a correct proposer and a correct validator (for `PROPOSE` messages) is less than `MSGDELAY`.
  19. ## Problem Statement
  20. In this section we define the properties of Tendermint consensus (cf. the [arXiv paper][arXiv]) in this new system model.
  21. #### **[PBTS-PROPOSE.0]**
  22. A proposer proposes a pair `(v,t)` of consensus value `v` and time `t`.
  23. > We then restrict the allowed decisions along the following lines:
  24. #### **[PBTS-INV-AGREEMENT.0]**
  25. [Agreement] No two correct validators decide on different values `v`.
  26. #### **[PBTS-INV-TIME-VAL.0]**
  27. [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.
  28. 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.
  29. 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:
  30. #### **[PBTS-INV-TIME-AGR.0]**
  31. [Time-Agreement] If two correct validators decide in the same round, then they decide on the same `t`.
  32. #### **[PBTS-DECISION-ROUND.0]**
  33. 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,
  34. as validators may decide in different rounds, they may decide on different times.
  35. 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".
  36. 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`.
  37. However, as most consensus instances terminate within one round on the Cosmos hub, this is hardly ever observed in practice.
  38. 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.
  39. ### SAFETY
  40. 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).
  41. 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`.
  42. Let
  43. - `beginConsensus(k)` be the minimum over `beginConsensus(V,k)`, and
  44. - `last-beginConsensus(k)` be the maximum over `beginConsensus(V,k)`, and
  45. - `endConsensus(k)` the maximum over `endConsensus(V,k)`
  46. for all correct validators `V`.
  47. > Observe that `beginConsensus(k) <= last-beginConsensus(k)` and if local clocks are monotonic, then `last-beginConsensus(k) <= endConsensus(k)`.
  48. #### **[PBTS-CLOCK-GROW.0]**
  49. 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)`.
  50. #### **[PBTS-CONSENSUS-TIME-VALID.0]**
  51. If
  52. - there is a valid commit `c` for height `k`, and
  53. - `c` contains a `PRECOMMIT` message by at least one correct validator,
  54. then the time `b.time` in the block `b` that is signed by `c` satisfies
  55. - `beginConsensus(k) - PRECISION <= b.time < endConsensus(k) + PRECISION + MSGDELAY`.
  56. > [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
  57. #### **[PBTS-CONSENSUS-LIVE-VALID-CORR-PROP.0]**
  58. If the proposer of round 1 is correct, and
  59. - [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
  60. - [PBTS-MSG-FAIR.0], and
  61. - [PBTS-CLOCK-PRECISION.0], and
  62. - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
  63. then eventually (within bounded time) every correct validator decides in round 1.
  64. #### **[PBTS-CONSENSUS-SAFE-VALID-CORR-PROP.0]**
  65. If the proposer of round 1 is correct, and
  66. - [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
  67. - [PBTS-MSG-FAIR.0], and
  68. - [PBTS-CLOCK-PRECISION.0], and
  69. - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
  70. then `beginConsensus_k <= b.time <= last-beginConsensus_k`.
  71. > For the above two properties we will assume that a correct proposer `v` sends its `PROPOSAL` at its local time `beginConsensus(v,k)`.
  72. ### LIVENESS
  73. If
  74. - [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
  75. - [PBTS-MSG-FAIR.0],
  76. - [PBTS-CLOCK.0], and
  77. - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
  78. then eventually there is a valid commit `c` for height `k`.
  79. ### REAL-TIME SAFETY
  80. > 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:
  81. #### **[PBTS-CLOCKSYNC-EXTERNAL.0]**
  82. There is a system parameter `ACCURACY`, such that for all real-times `t` and all correct validators `V`,
  83. - `| C_V(t) - t | < ACCURACY`.
  84. > `ACCURACY` is not necessarily visible at the code level. The properties below just show that the smaller
  85. its value, the closer the block time will be to real-time
  86. #### **[PBTS-CONSENSUS-PTIME.0]**
  87. LET `m` be a propose message. We consider the following two real-times `proposalTime(m)` and `propRecvTime(m)`:
  88. - if the proposer is correct and sends `m` at time `t`, we write `proposalTime(m)` for real-time `t`.
  89. - if first correct validator receives `m` at time `t`, we write `propRecvTime(m)` for real-time `t`.
  90. #### **[PBTS-CONSENSUS-REALTIME-VALID.0]**
  91. 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:
  92. `propRecvTime(m) - ACCURACY - PRECISION < b.time < propRecvTime(m) + ACCURACY + PRECISION + MSGDELAY`
  93. #### **[PBTS-CONSENSUS-REALTIME-VALID-CORR.0]**
  94. 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:
  95. `proposalTime(m) - ACCURACY < b.time < proposalTime(m) + ACCURACY`
  96. > by the algorithm at time `proposalTime(m)` the proposer fixes `m.time <- now_p(proposalTime(m))`
  97. > "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`.
  98. Back to [main document][main_v1].
  99. [main_v1]: ./pbts_001_draft.md
  100. [algorithm_v1]: ./pbts-algorithm_001_draft.md
  101. [sysmodel]: ../pbts-sysmodel_002_draft.md
  102. [arXiv]: https://arxiv.org/abs/1807.04938