From 0d3c1ddbbdbe398ba0df2268cf2d2cfd2ebb00e2 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Thu, 12 May 2022 17:06:45 +0200 Subject: [PATCH] PBTS: using proper Markdown subscripts in spec [2] --- .../pbts-algorithm_002_draft.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md index 031fe0c70..d15fbd31b 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -24,14 +24,14 @@ Since the originally proposed value and its associated time were considered vali Values decided in successive heights of consensus must have increasing times, so: -- Monotonicity: for any process `p` and any two decided heights `h` and `h'`, if `h > h'` then `decisionp[h].time > decisionp[h'].time`. +- Monotonicity: for any process `p` and any two decided heights `h` and `h'`, if `h > h'` then decisionp[h].time > decisionp[h'].time. -For ensuring time monotonicity, it is enough to ensure that a value `v` proposed by process `p` at height `hp` has `v.time > decisionp[hp-1].time`. -So, if process `p` is the proposer of a round of height `hp` and reads from its clock a time `nowp <= decisionp[hp-1]`, -it should postpone the generation of its proposal until `nowp > decisionp[hp-1]`. +For ensuring time monotonicity, it is enough to ensure that a value `v` proposed by process `p` at height hp has v.time > decisionp[hp-1].time. +So, if process `p` is the proposer of a round of height hp and reads from its clock a time nowp <= decisionp[hp-1], +it should postpone the generation of its proposal until nowp > decisionp[hp-1]. > Although it should be considered, this scenario is unlikely during regular operation, -as from `decisionp[hp-1].time` and the start of height `hp`, a complete consensus instance need to terminate. +as from decisionp[hp-1].time and the start of height hp, a complete consensus instance need to terminate. The time monotonicity of values proposed in heights of consensus is verified by the `valid()` predicate, to which every proposed value is submitted. A value rejected by the `valid()` implementation is not accepted by any correct process. @@ -47,18 +47,18 @@ It is a temporal requirement, associated with the following synchrony (that is, #### **[PBTS-RECEPTION-STEP.1]** -Let `nowp` be the time, read from the clock of process `p`, at which `p` receives the proposed value `v`. +Let nowp be the time, read from the clock of process `p`, at which `p` receives the proposed value `v`. The proposal is considered `timely` by `p` when: -1. `nowp >= v.time - PRECISION` -1. `nowp <= v.time + MSGDELAY + PRECISION` +1. nowp >= v.time - PRECISION +1. nowp <= v.time + MSGDELAY + PRECISION The first condition derives from the fact that the generation and sending of `v` precedes its reception. -The minimum receiving time `nowp` for `v` be considered `timely` by `p` is derived from the extreme scenario when +The minimum receiving time nowp for `v` be considered `timely` by `p` is derived from the extreme scenario when the clock of `p` is `PRECISION` *behind* of the clock of the proposer of `v`, and the proposal's transmission delay is `0` (minimum). The second condition derives from the assumption of an upper bound for the transmission delay of a proposal. -The maximum receiving time `nowp` for `v` be considered `timely` by `p` is derived from the extreme scenario when +The maximum receiving time nowp for `v` be considered `timely` by `p` is derived from the extreme scenario when the clock of `p` is `PRECISION` *ahead* of the clock of the proposer of `v`, and the proposal's transmission delay is `MSGDELAY` (maximum). ## Updated Consensus Algorithm