From ada16af1211a1eeb9246a023012adc0f763f14a0 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 13:45:08 +0100 Subject: [PATCH 01/14] PBTS: brief context and proposal added to README --- .../proposer-based-timestamp/README.md | 70 ++++++++++++++++++- 1 file changed, 68 insertions(+), 2 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index b2bbfb2e..3d2a131c 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -1,7 +1,71 @@ # Proposer-Based Timestamps -This section describes a version of the Tendermint consensus protocol, -which uses proposer-based timestamps. +This section describes a version of the Tendermint consensus protocol +that uses proposer-based timestamps. + +## Context + +Tendermint provides a deterministic, Byzantine fault-tolerant, source of time, +defined by the `Time` field present in the headers of committed blocks, +representing the block's timestamp. + +In the current consensus implementation, the timestamp of a block is +computed by the [BFT Time][bfttime] algorithm: + +- Validators timestamps the `Precommit` messages they broadcast. +Timestamps are retrieved from the validator's local clocks, +with the only restriction that they must be monotonic: + + - The timestamp of a `Precommit` message for a block + cannot be earlier than the `Time` field of that block. + +- The timestamp of a block is deterministically computed from the timestamps of +a set of `Precommit` messages that certify the commit of the previous block. +This certificate, a set of `Precommit` messages from a round of the previous height, +is selected by the block's proposer and stored in the `Commit` field of the block. + + - The block timestamp is the *median* of the timestamps of the `Precommit` messages + included in the `Commit` field, weighted by their voting power. + Since timestamps of valid `Precommit` messages are monotonic, so are block timestamps: + the timestamp of block `h+1` is larger than the timestamp of block `h`. + + - Let `f` be voting power controlled by Byzantine validators. + Provided that the cumulative voting power of a `Commit` set is at least `2f+1`, + the block timestamp is retrieved from the clock of a non-faulty validator. + +## Proposal + +In the proposed solution, the timestamp of a block is assigned by its +proposer, according with its local clock. +In other words, the proposer of a block also *proposes* a timestamp for the block. +Validators can accept or reject a proposed block. +A block is only accepted if its timestamp is acceptable. +A proposed timestamp is acceptable if it is *received* within a certain time window, +determined by synchronous parameters. + +PBTS therefore augments the system model considered by Tendermint with *synchronous assumptions*: + +- **Synchronized clocks**: simultaneous clock reads at any two correct validators +differ by at most `PRECISION`; + +- **Bounded message delays**: the end-to-end delay for delivering a message to all correct validators +is bounded by `MSGDELAY`. +This assumption is restricted to `Proposal` messages, broadcast by proposers. + +`PRECISION` and `MSGDELAY` are consensus parameters, shared by all validators, +that define whether the timestamp of a block is acceptable. +Let `t` be the time, read from its local clock, at which a validator +receives, for the first time, a proposal with timestamp `ts`: + +- **[Time-Validity]** The proposed timestamp `ts` received at local time `t` +is accepted if it satisfies the **timely** predicate: +> `ts - PRECISION <= t <= ts + MSGDELAY + PRECISION` + +The left inequality of the *timely* predicate establishes that proposed timestamps +should be in the past, when adjusted by the clocks `PRECISION`. +The right inequality of the *timely* predicate establishes that proposed timestamps +should not be too much in the past, more precisely, not more than `MSGDELAY` in the past, +when adjusted by the clocks `PRECISION`. ## Contents @@ -11,6 +75,8 @@ which uses proposer-based timestamps. - [TLA+ Specification][proposertla] +[bfttime]: ../bft-time.md + [algorithm]: ./pbts-algorithm_002_draft.md [sysmodel]: ./pbts-sysmodel_001_draft.md From 9524e901e478346821ef2f123ad803209b60bbcd Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 14:52:22 +0100 Subject: [PATCH 02/14] PBTS: summary of algorithmic solution added to README --- .../proposer-based-timestamp/README.md | 48 +++++++++++++++++-- 1 file changed, 43 insertions(+), 5 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 3d2a131c..4f7246b4 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -67,20 +67,58 @@ The right inequality of the *timely* predicate establishes that proposed timesta should not be too much in the past, more precisely, not more than `MSGDELAY` in the past, when adjusted by the clocks `PRECISION`. -## Contents +Refer to the [System Model and Properties][sysmodel] document +for a more detailed and formalized description. -- [Proposer-Based Time][main] (entry point) -- [Part I - System Model and Properties][sysmodel] -- [Part II - Protocol Specification][algorithm] -- [TLA+ Specification][proposertla] +## Implementation +The implementation of PBTS requires some changes in Tendermint consensus algorithm, +summarized below: + +- A proposer timestamps a block with the current time, read from its local clock. +The block's timestamp represents the time at which it was assembled +(after the `getValue()` call in line 18 of the [arXiv][arXiv] algorithm): + + - Block timestamps are definitive, meaning that the original timestamp + is retained when a block is re-proposed (line 16); + + - To preserve monotonicity, a proposer might need to wait until its clock + reads a time greater than the timestamp of the previous block; + +- A validator only prevotes for *timely* blocks, +that is, blocks whose timestamps are considered *timely* (check added to line 23). +If the block proposed in a round is considered *untimely*, +the validator prevotes `nil` (line 26): + + - Validators register the time at which they received `Proposal` messages, + in order to evaluate the *timely* predicate; + + - Blocks that are re-proposed because they received `2f+1 Prevotes` + in a previous round (line 28) are not subject to the *timely* predicate, + as they have already been evaluated as *timely* at a previous round. + +The more complex change proposed regards blocks that can be re-proposed in multiple rounds. +The current solution improves the [first version][algorithm_v1] +by simplifying the way this situation is handled, +from a recursive reasoning regarding valid blocks that are re-proposed. + +The full solution is detailed and formalized in the [protocol specification][algorithm] document. + +## Further details + +- [System Model and Properties][sysmodel] +- [Protocol Specification][algorithm] +- [TLA+ Specification][proposertla] (**outdated**) [bfttime]: ../bft-time.md [algorithm]: ./pbts-algorithm_002_draft.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_001_draft.md [main]: ./pbts_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla + +[arXiv]: https://arxiv.org/abs/1807.04938 From 16213c0f1d3ca5d8df55bfab1e8e1b84fd0cadd2 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 17:19:57 +0100 Subject: [PATCH 03/14] PBTS: Context section of README improved --- .../proposer-based-timestamp/README.md | 46 +++++++++++++------ 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 4f7246b4..6b9f2914 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -14,24 +14,39 @@ computed by the [BFT Time][bfttime] algorithm: - Validators timestamps the `Precommit` messages they broadcast. Timestamps are retrieved from the validator's local clocks, -with the only restriction that they must be monotonic: +with the only restriction that they must be **monotonic**: - - The timestamp of a `Precommit` message for a block - cannot be earlier than the `Time` field of that block. + - The timestamp of a `Precommit` message voting for a block + cannot be earlier than the `Time` field of that block; - The timestamp of a block is deterministically computed from the timestamps of a set of `Precommit` messages that certify the commit of the previous block. This certificate, a set of `Precommit` messages from a round of the previous height, -is selected by the block's proposer and stored in the `Commit` field of the block. +is selected by the block's proposer and stored in the `Commit` field of the block: - The block timestamp is the *median* of the timestamps of the `Precommit` messages included in the `Commit` field, weighted by their voting power. - Since timestamps of valid `Precommit` messages are monotonic, so are block timestamps: - the timestamp of block `h+1` is larger than the timestamp of block `h`. - - - Let `f` be voting power controlled by Byzantine validators. - Provided that the cumulative voting power of a `Commit` set is at least `2f+1`, - the block timestamp is retrieved from the clock of a non-faulty validator. + Block timestamps are **monotonic** because + timestamps of valid `Precommit` messages are monotonic; + +Assuming that the voting power controlled by Byzantine validators is bounded by `f`, +the cumulative voting power of any valid `Commit` set must be at least `2f+1`. +As a result, the timestamp computed by [BFT Time][bfttime] is not influenced by Byzantine validators, +as the weighted median of `Commit` timestamps comes from the clock of a non-faulty validator. + +Tendermint does not make any assumptions regarding the clocks of (correct) validators, +as block timestamps have no impact in the consensus protocol. +However, the `Time` field of committed blocks is used by other components of Tendermint, +such as IBC, the evidence, staking, and slashing modules. +And it is used based on the common belief that block timestamps +should bear some resemblance to real time, which is **not guaranteed**. + +A more comprehensive discussion of the limitations of the current method to assign timestamps to blocks +can be found in the [first draft][main_v1] of the PBTS proposal. +Of particular interest is to possibility of having validators equipped "faulty" clocks, +in the sense of not fairly accurate with real time, that detain more than `f` voting power, +plus the flexibility that a proposer has to select a `Commit` set, +and thus to choose the timestamp for a block. ## Proposal @@ -102,7 +117,7 @@ The current solution improves the [first version][algorithm_v1] by simplifying the way this situation is handled, from a recursive reasoning regarding valid blocks that are re-proposed. -The full solution is detailed and formalized in the [protocol specification][algorithm] document. +The full solution is detailed and formalized in the [Protocol Specification][algorithm] document. ## Further details @@ -110,15 +125,16 @@ The full solution is detailed and formalized in the [protocol specification][alg - [Protocol Specification][algorithm] - [TLA+ Specification][proposertla] (**outdated**) -[bfttime]: ../bft-time.md +[main_v1]: ./pbts_001_draft.md [algorithm]: ./pbts-algorithm_002_draft.md [algorithm_v1]: ./pbts-algorithm_001_draft.md -[sysmodel]: ./pbts-sysmodel_001_draft.md - -[main]: ./pbts_001_draft.md +[sysmodel]: ./pbts-sysmodel_002_draft.md +[sysmodel_v1]: ./pbts-sysmodel_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla +[bfttime]: ../bft-time.md [arXiv]: https://arxiv.org/abs/1807.04938 + From 638093f6649c9017b310c2a9a79afb941814434e Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 17:56:29 +0100 Subject: [PATCH 04/14] PBTS: fixing links and page titles --- .../proposer-based-timestamp/README.md | 22 ++++++++-------- .../pbts-algorithm_001_draft.md | 19 ++++++-------- .../pbts-algorithm_002_draft.md | 23 +++++++++-------- .../pbts-sysmodel_001_draft.md | 22 ++++++---------- .../pbts-sysmodel_002_draft.md | 15 ++++++++--- .../pbts_001_draft.md | 25 ++++++++----------- 6 files changed, 59 insertions(+), 67 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 6b9f2914..4eefcca5 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -1,4 +1,4 @@ -# Proposer-Based Timestamps +# Proposer-Based Timestamps (PBTS) This section describes a version of the Tendermint consensus protocol that uses proposer-based timestamps. @@ -10,7 +10,7 @@ defined by the `Time` field present in the headers of committed blocks, representing the block's timestamp. In the current consensus implementation, the timestamp of a block is -computed by the [BFT Time][bfttime] algorithm: +computed by the [`BFTTime`][bfttime] algorithm: - Validators timestamps the `Precommit` messages they broadcast. Timestamps are retrieved from the validator's local clocks, @@ -31,7 +31,7 @@ is selected by the block's proposer and stored in the `Commit` field of the bloc Assuming that the voting power controlled by Byzantine validators is bounded by `f`, the cumulative voting power of any valid `Commit` set must be at least `2f+1`. -As a result, the timestamp computed by [BFT Time][bfttime] is not influenced by Byzantine validators, +As a result, the timestamp computed by `BFTTime` is not influenced by Byzantine validators, as the weighted median of `Commit` timestamps comes from the clock of a non-faulty validator. Tendermint does not make any assumptions regarding the clocks of (correct) validators, @@ -41,12 +41,12 @@ such as IBC, the evidence, staking, and slashing modules. And it is used based on the common belief that block timestamps should bear some resemblance to real time, which is **not guaranteed**. -A more comprehensive discussion of the limitations of the current method to assign timestamps to blocks -can be found in the [first draft][main_v1] of the PBTS proposal. +A more comprehensive discussion of the limitations of `BFTTime` +can be found in the [first draft][main_v1] of this proposal. Of particular interest is to possibility of having validators equipped "faulty" clocks, -in the sense of not fairly accurate with real time, that detain more than `f` voting power, -plus the flexibility that a proposer has to select a `Commit` set, -and thus to choose the timestamp for a block. +not fairly accurate with real time, that detain more than `f` voting power, +plus the proposer's flexibility when selecting a `Commit` set, +and thus determining the timestamp for a block. ## Proposal @@ -82,8 +82,8 @@ The right inequality of the *timely* predicate establishes that proposed timesta should not be too much in the past, more precisely, not more than `MSGDELAY` in the past, when adjusted by the clocks `PRECISION`. -Refer to the [System Model and Properties][sysmodel] document -for a more detailed and formalized description. +A more detailed and formalized description is available in the +[System Model and Properties][sysmodel] document ## Implementation @@ -135,6 +135,6 @@ The full solution is detailed and formalized in the [Protocol Specification][alg [proposertla]: ./tla/TendermintPBT_001_draft.tla -[bfttime]: ../bft-time.md +[bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md index 5f17d353..00ea41f9 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md @@ -1,6 +1,6 @@ -# Proposer-Based Time - Part II +# PBTS: Protocol Specification (first draft) -This specification is **OUTDATED**. Please refer to the [new version][v2]. +This specification is **OUTDATED**. Please refer to the [new version][algorithm]. ## Updated Consensus Algorithm @@ -152,16 +152,11 @@ upon ⟨PROPOSAL, h_p, r, (v,t), ∗⟩ from proposer(h_p, r) AND 2f + 1 ⟨PREC **All other rules remains unchanged.** -Back to [main document][main]. +Back to [main document][main_v1]. -[main]: ./pbts_001_draft.md +[main_v1]: ./pbts_001_draft.md -[arXiv]: https://arxiv.org/abs/1807.04938 - -[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md - -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md +[algorithm]: ./pbts-algorithm_002_draft.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md -[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md - -[v2]: ./pbts-algorithm_002_draft.md +[arXiv]: https://arxiv.org/abs/1807.04938 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 15f303d5..3cf0f653 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -1,4 +1,4 @@ -# Proposer-Based Time v2 - Part II +# PBTS: Protocol Specification ## Proposal Time @@ -6,7 +6,7 @@ PBTS computes for a proposed value `v` the proposal time `v.time`, with bounded The proposal time is read from the clock of the process that proposes a value for the first time, its original proposer. With PBTS, therefore, we assume that processes have access to **synchronized clocks**. -The proper definition of what it means can be found in the [system model][model], +The proper definition of what it means can be found in the [system model][sysmodel], but essentially we assume that two correct processes do not simultaneous read from their clocks time values that differ more than `PRECISION`, which is a system parameter. @@ -20,7 +20,7 @@ A value `v` should re-proposed when it becomes locked by the network, i.e., when This means that processes with `2f + 1`-equivalent voting power accepted, in round `r`, both `v` and its associated time `v.time`. Since the originally proposed value and its associated time were considered valid, there is no reason for reassigning `v.time`. -In the [first version][v1] of this specification, proposals were defined as pairs `(v, time)`. +In the [first version][algorithm_v1] of this specification, proposals were defined as pairs `(v, time)`. In addition, the same value `v` could be proposed, in different rounds, but would be associated to distinct times each time it was reproposed. Since this possibility does not exist in this second specification, the proposal time became part of the proposed value. With this simplification, several small changes to the [arXiv][arXiv] algorithm are no longer required. @@ -38,8 +38,8 @@ it should postpone the generation of its proposal until `now_p > decision_p[h_p- > Although it should be considered, this scenario is unlikely during regular operation, as from `decision_p[h_p-1].time` and the start of height `h_p`, a complete consensus instance need to terminate. -Notice that monotonicity is not introduced by this proposal, being already ensured by [`bfttime`][bfttime]. -In `bfttime`, the `Timestamp` field of every `Precommit` message of height `h_p` sent by a correct process is required to be larger than `decision_p[h_p-1].time`, as one of such `Timestamp` fields becomes the time assigned to a value proposed at height `h_p`. +Notice that monotonicity is not introduced by this proposal, being already ensured by [`BFTTime`][bfttime]. +In `BFTTime`, the `Timestamp` field of every `Precommit` message of height `h_p` sent by a correct process is required to be larger than `decision_p[h_p-1].time`, as one of such `Timestamp` fields becomes the time assigned to a value proposed at height `h_p`. 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. @@ -48,7 +48,7 @@ A value rejected by the `valid()` implementation is not accepted by any correct PBTS introduces a new requirement for a process to accept a proposal: the proposal must be `timely`. It is a temporal requirement, associated with the following synchrony (that is, timing) -[assumptions][model] regarding the behavior of processes and the network: +[assumptions][sysmodel] regarding the behavior of processes and the network: - Synchronized clocks: the values simultaneously read from clocks of any two correct processes differ by at most `PRECISION`; - Bounded transmission delays: the real time interval between the sending of a proposal at a correct process, and the reception of the proposal at any correct process is upper bounded by `MSGDELAY`. @@ -138,8 +138,11 @@ and because, since `v` was re-proposed as a `validValue` (line 16), `v.time` has Back to [main document][main]. +[main]: ./README.md + +[algorithm_v1]: ./pbts-algorithm_001_draft.md + +[sysmodel]: ./pbts-sysmodel_002_draft.md + +[bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md [arXiv]: https://arxiv.org/abs/1807.04938 -[v1]: ./pbts-algorithm_001_draft.md -[main]: ./pbts_001_draft.md -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md -[model]: ./pbts-sysmodel_002_draft.md diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md index f9c6d3f3..b87da65c 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md @@ -1,6 +1,6 @@ -# Proposer-Based Time - Part I +# PBTS: System Model and Properties (first draft) -This specification is **OUTDATED**. Please refer to the [new version][v2]. +This specification is **OUTDATED**. Please refer to the [new version][sysmodel]. ## System Model @@ -183,20 +183,12 @@ Let `b` be a block with a valid commit that contains at least one `precommit` me > "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`. -Back to [main document][main]. +Back to [main document][main_v1]. -[main]: ./pbts_001_draft.md +[main_v1]: ./pbts_001_draft.md -[arXiv]: https://arxiv.org/abs/1807.04938 - -[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md - -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md -[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md +[sysmodel]: ./pbts-sysmodel_002_draft.md -[algorithm]: ./pbts-algorithm_001_draft.md - -[sysmodel]: ./pbts-sysmodel_001_draft.md - -[v2]: ./pbts-sysmodel_002_draft.md +[arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md index a5ed4638..f6f7d5e7 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md @@ -1,4 +1,4 @@ -# Proposer-Based Time v2 - Part I +# PBTS: System Model and Properties ## System Model @@ -37,7 +37,7 @@ from their local clocks, so that their clocks can be considered synchronized. #### Accuracy -The [original specification][v1] included a second clock-related parameter, `ACCURACY`, +The [first draft][sysmodel_v1] of this specification included a second clock-related parameter, `ACCURACY`, that relates the values read by processes from their synchronized clocks with real time: - If `p` is a process is equipped with a synchronized clock, then at real time @@ -248,6 +248,13 @@ The precise behavior for this workaround is under [discussion](https://github.co Back to [main document][main]. -[main]: ./pbts_001_draft.md -[v1]: ./pbts-sysmodel_001_draft.md +[main]: ./README.md +[main_v1]: ./pbts_001_draft.md + +[algorithm]: ./pbts-algorithm_002_draft.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md + +[sysmodel]: ./pbts-sysmodel_002_draft.md +[sysmodel_v1]: ./pbts-sysmodel_001_draft.md + [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md index c3c40036..a85b6aa6 100644 --- a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md @@ -1,6 +1,6 @@ -# Proposer-Based Time +# Proposer-Based Time (first draft) ## Current BFTTime @@ -251,22 +251,17 @@ For analyzing real-time safety (Point 5), we use a system parameter `ACCURACY`, 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. -- [Part I - System Model and Properties][sysmodel] -- [Part II - Protocol specification][algorithm] +- [Part I - System Model and Properties][sysmodel_v1] +- [Part II - Protocol specification][algorithm_v1] - [TLA+ Specification][proposertla] -[arXiv]: https://arxiv.org/abs/1807.04938 - -[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md - -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md - -[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md -[algorithm]: ./pbts-algorithm_002_draft.md - -[sysmodel]: ./pbts-sysmodel_002_draft.md - -[main]: ./pbts_001_draft.md +[sysmodel_v1]: ./pbts-sysmodel_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla + +[bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md +[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md +[lcspec]: https://github.com/tendermint/spec/tree/master/spec/light-client +[arXiv]: https://arxiv.org/abs/1807.04938 From 13ec03a097e8ca004cdf2d6bbf620ad7b6402296 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 18:11:45 +0100 Subject: [PATCH 05/14] PBTS: moved first drafts to v1/, links updated --- spec/consensus/proposer-based-timestamp/README.md | 6 +++--- .../proposer-based-timestamp/pbts-algorithm_002_draft.md | 2 +- .../proposer-based-timestamp/pbts-sysmodel_002_draft.md | 4 +--- .../{ => v1}/pbts-algorithm_001_draft.md | 2 +- .../{ => v1}/pbts-sysmodel_001_draft.md | 2 +- .../proposer-based-timestamp/{ => v1}/pbts_001_draft.md | 2 +- 6 files changed, 8 insertions(+), 10 deletions(-) rename spec/consensus/proposer-based-timestamp/{ => v1}/pbts-algorithm_001_draft.md (99%) rename spec/consensus/proposer-based-timestamp/{ => v1}/pbts-sysmodel_001_draft.md (99%) rename spec/consensus/proposer-based-timestamp/{ => v1}/pbts_001_draft.md (99%) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 4eefcca5..eba8be15 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -125,13 +125,13 @@ The full solution is detailed and formalized in the [Protocol Specification][alg - [Protocol Specification][algorithm] - [TLA+ Specification][proposertla] (**outdated**) -[main_v1]: ./pbts_001_draft.md +[main_v1]: ./v1/pbts_001_draft.md [algorithm]: ./pbts-algorithm_002_draft.md -[algorithm_v1]: ./pbts-algorithm_001_draft.md +[algorithm_v1]: ./v1/pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_002_draft.md -[sysmodel_v1]: ./pbts-sysmodel_001_draft.md +[sysmodel_v1]: ./v1/pbts-sysmodel_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla 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 3cf0f653..73c4f484 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -140,7 +140,7 @@ Back to [main document][main]. [main]: ./README.md -[algorithm_v1]: ./pbts-algorithm_001_draft.md +[algorithm_v1]: ./v1/pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_002_draft.md diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md index f6f7d5e7..f207a480 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md @@ -249,12 +249,10 @@ The precise behavior for this workaround is under [discussion](https://github.co Back to [main document][main]. [main]: ./README.md -[main_v1]: ./pbts_001_draft.md [algorithm]: ./pbts-algorithm_002_draft.md -[algorithm_v1]: ./pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_002_draft.md -[sysmodel_v1]: ./pbts-sysmodel_001_draft.md +[sysmodel_v1]: ./v1/pbts-sysmodel_001_draft.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md b/spec/consensus/proposer-based-timestamp/v1/pbts-algorithm_001_draft.md similarity index 99% rename from spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md rename to spec/consensus/proposer-based-timestamp/v1/pbts-algorithm_001_draft.md index 00ea41f9..c8fd08ef 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/v1/pbts-algorithm_001_draft.md @@ -156,7 +156,7 @@ Back to [main document][main_v1]. [main_v1]: ./pbts_001_draft.md -[algorithm]: ./pbts-algorithm_002_draft.md +[algorithm]: ../pbts-algorithm_002_draft.md [algorithm_v1]: ./pbts-algorithm_001_draft.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/v1/pbts-sysmodel_001_draft.md similarity index 99% rename from spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md rename to spec/consensus/proposer-based-timestamp/v1/pbts-sysmodel_001_draft.md index b87da65c..e721fe07 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/v1/pbts-sysmodel_001_draft.md @@ -189,6 +189,6 @@ Back to [main document][main_v1]. [algorithm_v1]: ./pbts-algorithm_001_draft.md -[sysmodel]: ./pbts-sysmodel_002_draft.md +[sysmodel]: ../pbts-sysmodel_002_draft.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/v1/pbts_001_draft.md similarity index 99% rename from spec/consensus/proposer-based-timestamp/pbts_001_draft.md rename to spec/consensus/proposer-based-timestamp/v1/pbts_001_draft.md index a85b6aa6..e269cc79 100644 --- a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/v1/pbts_001_draft.md @@ -259,7 +259,7 @@ This specification describes the changes needed to be done to the Tendermint con [sysmodel_v1]: ./pbts-sysmodel_001_draft.md -[proposertla]: ./tla/TendermintPBT_001_draft.tla +[proposertla]: ../tla/TendermintPBT_001_draft.tla [bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md [tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md From e163001107b36ea17219ae552cdd22ea1072bc19 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 18:28:12 +0100 Subject: [PATCH 06/14] PBTS: added issues to README, link to arXiv PDF --- .../proposer-based-timestamp/README.md | 26 ++++++++++++++++--- .../pbts-algorithm_002_draft.md | 2 +- .../pbts-sysmodel_002_draft.md | 2 +- 3 files changed, 24 insertions(+), 6 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index eba8be15..1d2fae54 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -74,7 +74,7 @@ receives, for the first time, a proposal with timestamp `ts`: - **[Time-Validity]** The proposed timestamp `ts` received at local time `t` is accepted if it satisfies the **timely** predicate: -> `ts - PRECISION <= t <= ts + MSGDELAY + PRECISION` + > `ts - PRECISION <= t <= ts + MSGDELAY + PRECISION` The left inequality of the *timely* predicate establishes that proposed timestamps should be in the past, when adjusted by the clocks `PRECISION`. @@ -123,7 +123,19 @@ The full solution is detailed and formalized in the [Protocol Specification][alg - [System Model and Properties][sysmodel] - [Protocol Specification][algorithm] -- [TLA+ Specification][proposertla] (**outdated**) +- [TLA+ Specification][proposertla] (first draft, not updated) + +### Open issues + +- [PBTS: evidence #355][issue355]: not really clear the context, probably not going to be solved. +- [PBTS: should synchrony parameters be adaptive? #371][issue371] +- [PBTS: Treat proposal and block parts explicitly in the spec #372][issue372] +- [PBTS: margins for proposal times assigned by Byzantine proposers #377][issue377] + +### Closed issues + +- [Proposer time - fix message filter condition #353][issue353] +- [PBTS: association between timely predicate and timeout_commit #370][issue370] [main_v1]: ./v1/pbts_001_draft.md @@ -136,5 +148,11 @@ The full solution is detailed and formalized in the [Protocol Specification][alg [proposertla]: ./tla/TendermintPBT_001_draft.tla [bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md -[arXiv]: https://arxiv.org/abs/1807.04938 - +[arXiv]: https://arxiv.org/pdf/1807.04938.pdf + +[issue353]: https://github.com/tendermint/spec/issues/353 +[issue355]: https://github.com/tendermint/spec/issues/355 +[issue370]: https://github.com/tendermint/spec/issues/370 +[issue371]: https://github.com/tendermint/spec/issues/371 +[issue372]: https://github.com/tendermint/spec/issues/372 +[issue377]: https://github.com/tendermint/spec/issues/377 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 73c4f484..8e60c013 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -145,4 +145,4 @@ Back to [main document][main]. [sysmodel]: ./pbts-sysmodel_002_draft.md [bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md -[arXiv]: https://arxiv.org/abs/1807.04938 +[arXiv]: https://arxiv.org/pdf/1807.04938.pdf diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md index f207a480..832d11c9 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md @@ -255,4 +255,4 @@ Back to [main document][main]. [sysmodel]: ./pbts-sysmodel_002_draft.md [sysmodel_v1]: ./v1/pbts-sysmodel_001_draft.md -[arXiv]: https://arxiv.org/abs/1807.04938 +[arXiv]: https://arxiv.org/pdf/1807.04938.pdf From a5e80af6cb7b4175a0a6c723295cccaf6e25c605 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 13:45:08 +0100 Subject: [PATCH 07/14] PBTS: brief context and proposal added to README --- .../proposer-based-timestamp/README.md | 70 ++++++++++++++++++- 1 file changed, 68 insertions(+), 2 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index b2bbfb2e..3d2a131c 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -1,7 +1,71 @@ # Proposer-Based Timestamps -This section describes a version of the Tendermint consensus protocol, -which uses proposer-based timestamps. +This section describes a version of the Tendermint consensus protocol +that uses proposer-based timestamps. + +## Context + +Tendermint provides a deterministic, Byzantine fault-tolerant, source of time, +defined by the `Time` field present in the headers of committed blocks, +representing the block's timestamp. + +In the current consensus implementation, the timestamp of a block is +computed by the [BFT Time][bfttime] algorithm: + +- Validators timestamps the `Precommit` messages they broadcast. +Timestamps are retrieved from the validator's local clocks, +with the only restriction that they must be monotonic: + + - The timestamp of a `Precommit` message for a block + cannot be earlier than the `Time` field of that block. + +- The timestamp of a block is deterministically computed from the timestamps of +a set of `Precommit` messages that certify the commit of the previous block. +This certificate, a set of `Precommit` messages from a round of the previous height, +is selected by the block's proposer and stored in the `Commit` field of the block. + + - The block timestamp is the *median* of the timestamps of the `Precommit` messages + included in the `Commit` field, weighted by their voting power. + Since timestamps of valid `Precommit` messages are monotonic, so are block timestamps: + the timestamp of block `h+1` is larger than the timestamp of block `h`. + + - Let `f` be voting power controlled by Byzantine validators. + Provided that the cumulative voting power of a `Commit` set is at least `2f+1`, + the block timestamp is retrieved from the clock of a non-faulty validator. + +## Proposal + +In the proposed solution, the timestamp of a block is assigned by its +proposer, according with its local clock. +In other words, the proposer of a block also *proposes* a timestamp for the block. +Validators can accept or reject a proposed block. +A block is only accepted if its timestamp is acceptable. +A proposed timestamp is acceptable if it is *received* within a certain time window, +determined by synchronous parameters. + +PBTS therefore augments the system model considered by Tendermint with *synchronous assumptions*: + +- **Synchronized clocks**: simultaneous clock reads at any two correct validators +differ by at most `PRECISION`; + +- **Bounded message delays**: the end-to-end delay for delivering a message to all correct validators +is bounded by `MSGDELAY`. +This assumption is restricted to `Proposal` messages, broadcast by proposers. + +`PRECISION` and `MSGDELAY` are consensus parameters, shared by all validators, +that define whether the timestamp of a block is acceptable. +Let `t` be the time, read from its local clock, at which a validator +receives, for the first time, a proposal with timestamp `ts`: + +- **[Time-Validity]** The proposed timestamp `ts` received at local time `t` +is accepted if it satisfies the **timely** predicate: +> `ts - PRECISION <= t <= ts + MSGDELAY + PRECISION` + +The left inequality of the *timely* predicate establishes that proposed timestamps +should be in the past, when adjusted by the clocks `PRECISION`. +The right inequality of the *timely* predicate establishes that proposed timestamps +should not be too much in the past, more precisely, not more than `MSGDELAY` in the past, +when adjusted by the clocks `PRECISION`. ## Contents @@ -11,6 +75,8 @@ which uses proposer-based timestamps. - [TLA+ Specification][proposertla] +[bfttime]: ../bft-time.md + [algorithm]: ./pbts-algorithm_002_draft.md [sysmodel]: ./pbts-sysmodel_001_draft.md From 550db12fa35ecbd9d0d7ca40ec9c1088fd49b3c8 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 14:52:22 +0100 Subject: [PATCH 08/14] PBTS: summary of algorithmic solution added to README --- .../proposer-based-timestamp/README.md | 48 +++++++++++++++++-- 1 file changed, 43 insertions(+), 5 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 3d2a131c..4f7246b4 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -67,20 +67,58 @@ The right inequality of the *timely* predicate establishes that proposed timesta should not be too much in the past, more precisely, not more than `MSGDELAY` in the past, when adjusted by the clocks `PRECISION`. -## Contents +Refer to the [System Model and Properties][sysmodel] document +for a more detailed and formalized description. -- [Proposer-Based Time][main] (entry point) -- [Part I - System Model and Properties][sysmodel] -- [Part II - Protocol Specification][algorithm] -- [TLA+ Specification][proposertla] +## Implementation +The implementation of PBTS requires some changes in Tendermint consensus algorithm, +summarized below: + +- A proposer timestamps a block with the current time, read from its local clock. +The block's timestamp represents the time at which it was assembled +(after the `getValue()` call in line 18 of the [arXiv][arXiv] algorithm): + + - Block timestamps are definitive, meaning that the original timestamp + is retained when a block is re-proposed (line 16); + + - To preserve monotonicity, a proposer might need to wait until its clock + reads a time greater than the timestamp of the previous block; + +- A validator only prevotes for *timely* blocks, +that is, blocks whose timestamps are considered *timely* (check added to line 23). +If the block proposed in a round is considered *untimely*, +the validator prevotes `nil` (line 26): + + - Validators register the time at which they received `Proposal` messages, + in order to evaluate the *timely* predicate; + + - Blocks that are re-proposed because they received `2f+1 Prevotes` + in a previous round (line 28) are not subject to the *timely* predicate, + as they have already been evaluated as *timely* at a previous round. + +The more complex change proposed regards blocks that can be re-proposed in multiple rounds. +The current solution improves the [first version][algorithm_v1] +by simplifying the way this situation is handled, +from a recursive reasoning regarding valid blocks that are re-proposed. + +The full solution is detailed and formalized in the [protocol specification][algorithm] document. + +## Further details + +- [System Model and Properties][sysmodel] +- [Protocol Specification][algorithm] +- [TLA+ Specification][proposertla] (**outdated**) [bfttime]: ../bft-time.md [algorithm]: ./pbts-algorithm_002_draft.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_001_draft.md [main]: ./pbts_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla + +[arXiv]: https://arxiv.org/abs/1807.04938 From bb887c0623f6f2c97b46703510ca3f4db697e17d Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 17:19:57 +0100 Subject: [PATCH 09/14] PBTS: Context section of README improved --- .../proposer-based-timestamp/README.md | 46 +++++++++++++------ 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 4f7246b4..6b9f2914 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -14,24 +14,39 @@ computed by the [BFT Time][bfttime] algorithm: - Validators timestamps the `Precommit` messages they broadcast. Timestamps are retrieved from the validator's local clocks, -with the only restriction that they must be monotonic: +with the only restriction that they must be **monotonic**: - - The timestamp of a `Precommit` message for a block - cannot be earlier than the `Time` field of that block. + - The timestamp of a `Precommit` message voting for a block + cannot be earlier than the `Time` field of that block; - The timestamp of a block is deterministically computed from the timestamps of a set of `Precommit` messages that certify the commit of the previous block. This certificate, a set of `Precommit` messages from a round of the previous height, -is selected by the block's proposer and stored in the `Commit` field of the block. +is selected by the block's proposer and stored in the `Commit` field of the block: - The block timestamp is the *median* of the timestamps of the `Precommit` messages included in the `Commit` field, weighted by their voting power. - Since timestamps of valid `Precommit` messages are monotonic, so are block timestamps: - the timestamp of block `h+1` is larger than the timestamp of block `h`. - - - Let `f` be voting power controlled by Byzantine validators. - Provided that the cumulative voting power of a `Commit` set is at least `2f+1`, - the block timestamp is retrieved from the clock of a non-faulty validator. + Block timestamps are **monotonic** because + timestamps of valid `Precommit` messages are monotonic; + +Assuming that the voting power controlled by Byzantine validators is bounded by `f`, +the cumulative voting power of any valid `Commit` set must be at least `2f+1`. +As a result, the timestamp computed by [BFT Time][bfttime] is not influenced by Byzantine validators, +as the weighted median of `Commit` timestamps comes from the clock of a non-faulty validator. + +Tendermint does not make any assumptions regarding the clocks of (correct) validators, +as block timestamps have no impact in the consensus protocol. +However, the `Time` field of committed blocks is used by other components of Tendermint, +such as IBC, the evidence, staking, and slashing modules. +And it is used based on the common belief that block timestamps +should bear some resemblance to real time, which is **not guaranteed**. + +A more comprehensive discussion of the limitations of the current method to assign timestamps to blocks +can be found in the [first draft][main_v1] of the PBTS proposal. +Of particular interest is to possibility of having validators equipped "faulty" clocks, +in the sense of not fairly accurate with real time, that detain more than `f` voting power, +plus the flexibility that a proposer has to select a `Commit` set, +and thus to choose the timestamp for a block. ## Proposal @@ -102,7 +117,7 @@ The current solution improves the [first version][algorithm_v1] by simplifying the way this situation is handled, from a recursive reasoning regarding valid blocks that are re-proposed. -The full solution is detailed and formalized in the [protocol specification][algorithm] document. +The full solution is detailed and formalized in the [Protocol Specification][algorithm] document. ## Further details @@ -110,15 +125,16 @@ The full solution is detailed and formalized in the [protocol specification][alg - [Protocol Specification][algorithm] - [TLA+ Specification][proposertla] (**outdated**) -[bfttime]: ../bft-time.md +[main_v1]: ./pbts_001_draft.md [algorithm]: ./pbts-algorithm_002_draft.md [algorithm_v1]: ./pbts-algorithm_001_draft.md -[sysmodel]: ./pbts-sysmodel_001_draft.md - -[main]: ./pbts_001_draft.md +[sysmodel]: ./pbts-sysmodel_002_draft.md +[sysmodel_v1]: ./pbts-sysmodel_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla +[bfttime]: ../bft-time.md [arXiv]: https://arxiv.org/abs/1807.04938 + From ffd05dbee450a2b67f526207174499838ae4f7aa Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 17:56:29 +0100 Subject: [PATCH 10/14] PBTS: fixing links and page titles --- .../proposer-based-timestamp/README.md | 22 ++++++++-------- .../pbts-algorithm_001_draft.md | 19 ++++++-------- .../pbts-algorithm_002_draft.md | 23 +++++++++-------- .../pbts-sysmodel_001_draft.md | 22 ++++++---------- .../pbts-sysmodel_002_draft.md | 15 ++++++++--- .../pbts_001_draft.md | 25 ++++++++----------- 6 files changed, 59 insertions(+), 67 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 6b9f2914..4eefcca5 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -1,4 +1,4 @@ -# Proposer-Based Timestamps +# Proposer-Based Timestamps (PBTS) This section describes a version of the Tendermint consensus protocol that uses proposer-based timestamps. @@ -10,7 +10,7 @@ defined by the `Time` field present in the headers of committed blocks, representing the block's timestamp. In the current consensus implementation, the timestamp of a block is -computed by the [BFT Time][bfttime] algorithm: +computed by the [`BFTTime`][bfttime] algorithm: - Validators timestamps the `Precommit` messages they broadcast. Timestamps are retrieved from the validator's local clocks, @@ -31,7 +31,7 @@ is selected by the block's proposer and stored in the `Commit` field of the bloc Assuming that the voting power controlled by Byzantine validators is bounded by `f`, the cumulative voting power of any valid `Commit` set must be at least `2f+1`. -As a result, the timestamp computed by [BFT Time][bfttime] is not influenced by Byzantine validators, +As a result, the timestamp computed by `BFTTime` is not influenced by Byzantine validators, as the weighted median of `Commit` timestamps comes from the clock of a non-faulty validator. Tendermint does not make any assumptions regarding the clocks of (correct) validators, @@ -41,12 +41,12 @@ such as IBC, the evidence, staking, and slashing modules. And it is used based on the common belief that block timestamps should bear some resemblance to real time, which is **not guaranteed**. -A more comprehensive discussion of the limitations of the current method to assign timestamps to blocks -can be found in the [first draft][main_v1] of the PBTS proposal. +A more comprehensive discussion of the limitations of `BFTTime` +can be found in the [first draft][main_v1] of this proposal. Of particular interest is to possibility of having validators equipped "faulty" clocks, -in the sense of not fairly accurate with real time, that detain more than `f` voting power, -plus the flexibility that a proposer has to select a `Commit` set, -and thus to choose the timestamp for a block. +not fairly accurate with real time, that detain more than `f` voting power, +plus the proposer's flexibility when selecting a `Commit` set, +and thus determining the timestamp for a block. ## Proposal @@ -82,8 +82,8 @@ The right inequality of the *timely* predicate establishes that proposed timesta should not be too much in the past, more precisely, not more than `MSGDELAY` in the past, when adjusted by the clocks `PRECISION`. -Refer to the [System Model and Properties][sysmodel] document -for a more detailed and formalized description. +A more detailed and formalized description is available in the +[System Model and Properties][sysmodel] document ## Implementation @@ -135,6 +135,6 @@ The full solution is detailed and formalized in the [Protocol Specification][alg [proposertla]: ./tla/TendermintPBT_001_draft.tla -[bfttime]: ../bft-time.md +[bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md index 5f17d353..00ea41f9 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md @@ -1,6 +1,6 @@ -# Proposer-Based Time - Part II +# PBTS: Protocol Specification (first draft) -This specification is **OUTDATED**. Please refer to the [new version][v2]. +This specification is **OUTDATED**. Please refer to the [new version][algorithm]. ## Updated Consensus Algorithm @@ -152,16 +152,11 @@ upon ⟨PROPOSAL, h_p, r, (v,t), ∗⟩ from proposer(h_p, r) AND 2f + 1 ⟨PREC **All other rules remains unchanged.** -Back to [main document][main]. +Back to [main document][main_v1]. -[main]: ./pbts_001_draft.md +[main_v1]: ./pbts_001_draft.md -[arXiv]: https://arxiv.org/abs/1807.04938 - -[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md - -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md +[algorithm]: ./pbts-algorithm_002_draft.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md -[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md - -[v2]: ./pbts-algorithm_002_draft.md +[arXiv]: https://arxiv.org/abs/1807.04938 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 15f303d5..3cf0f653 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -1,4 +1,4 @@ -# Proposer-Based Time v2 - Part II +# PBTS: Protocol Specification ## Proposal Time @@ -6,7 +6,7 @@ PBTS computes for a proposed value `v` the proposal time `v.time`, with bounded The proposal time is read from the clock of the process that proposes a value for the first time, its original proposer. With PBTS, therefore, we assume that processes have access to **synchronized clocks**. -The proper definition of what it means can be found in the [system model][model], +The proper definition of what it means can be found in the [system model][sysmodel], but essentially we assume that two correct processes do not simultaneous read from their clocks time values that differ more than `PRECISION`, which is a system parameter. @@ -20,7 +20,7 @@ A value `v` should re-proposed when it becomes locked by the network, i.e., when This means that processes with `2f + 1`-equivalent voting power accepted, in round `r`, both `v` and its associated time `v.time`. Since the originally proposed value and its associated time were considered valid, there is no reason for reassigning `v.time`. -In the [first version][v1] of this specification, proposals were defined as pairs `(v, time)`. +In the [first version][algorithm_v1] of this specification, proposals were defined as pairs `(v, time)`. In addition, the same value `v` could be proposed, in different rounds, but would be associated to distinct times each time it was reproposed. Since this possibility does not exist in this second specification, the proposal time became part of the proposed value. With this simplification, several small changes to the [arXiv][arXiv] algorithm are no longer required. @@ -38,8 +38,8 @@ it should postpone the generation of its proposal until `now_p > decision_p[h_p- > Although it should be considered, this scenario is unlikely during regular operation, as from `decision_p[h_p-1].time` and the start of height `h_p`, a complete consensus instance need to terminate. -Notice that monotonicity is not introduced by this proposal, being already ensured by [`bfttime`][bfttime]. -In `bfttime`, the `Timestamp` field of every `Precommit` message of height `h_p` sent by a correct process is required to be larger than `decision_p[h_p-1].time`, as one of such `Timestamp` fields becomes the time assigned to a value proposed at height `h_p`. +Notice that monotonicity is not introduced by this proposal, being already ensured by [`BFTTime`][bfttime]. +In `BFTTime`, the `Timestamp` field of every `Precommit` message of height `h_p` sent by a correct process is required to be larger than `decision_p[h_p-1].time`, as one of such `Timestamp` fields becomes the time assigned to a value proposed at height `h_p`. 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. @@ -48,7 +48,7 @@ A value rejected by the `valid()` implementation is not accepted by any correct PBTS introduces a new requirement for a process to accept a proposal: the proposal must be `timely`. It is a temporal requirement, associated with the following synchrony (that is, timing) -[assumptions][model] regarding the behavior of processes and the network: +[assumptions][sysmodel] regarding the behavior of processes and the network: - Synchronized clocks: the values simultaneously read from clocks of any two correct processes differ by at most `PRECISION`; - Bounded transmission delays: the real time interval between the sending of a proposal at a correct process, and the reception of the proposal at any correct process is upper bounded by `MSGDELAY`. @@ -138,8 +138,11 @@ and because, since `v` was re-proposed as a `validValue` (line 16), `v.time` has Back to [main document][main]. +[main]: ./README.md + +[algorithm_v1]: ./pbts-algorithm_001_draft.md + +[sysmodel]: ./pbts-sysmodel_002_draft.md + +[bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md [arXiv]: https://arxiv.org/abs/1807.04938 -[v1]: ./pbts-algorithm_001_draft.md -[main]: ./pbts_001_draft.md -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md -[model]: ./pbts-sysmodel_002_draft.md diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md index f9c6d3f3..b87da65c 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md @@ -1,6 +1,6 @@ -# Proposer-Based Time - Part I +# PBTS: System Model and Properties (first draft) -This specification is **OUTDATED**. Please refer to the [new version][v2]. +This specification is **OUTDATED**. Please refer to the [new version][sysmodel]. ## System Model @@ -183,20 +183,12 @@ Let `b` be a block with a valid commit that contains at least one `precommit` me > "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`. -Back to [main document][main]. +Back to [main document][main_v1]. -[main]: ./pbts_001_draft.md +[main_v1]: ./pbts_001_draft.md -[arXiv]: https://arxiv.org/abs/1807.04938 - -[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md - -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md -[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md +[sysmodel]: ./pbts-sysmodel_002_draft.md -[algorithm]: ./pbts-algorithm_001_draft.md - -[sysmodel]: ./pbts-sysmodel_001_draft.md - -[v2]: ./pbts-sysmodel_002_draft.md +[arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md index a5ed4638..f6f7d5e7 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md @@ -1,4 +1,4 @@ -# Proposer-Based Time v2 - Part I +# PBTS: System Model and Properties ## System Model @@ -37,7 +37,7 @@ from their local clocks, so that their clocks can be considered synchronized. #### Accuracy -The [original specification][v1] included a second clock-related parameter, `ACCURACY`, +The [first draft][sysmodel_v1] of this specification included a second clock-related parameter, `ACCURACY`, that relates the values read by processes from their synchronized clocks with real time: - If `p` is a process is equipped with a synchronized clock, then at real time @@ -248,6 +248,13 @@ The precise behavior for this workaround is under [discussion](https://github.co Back to [main document][main]. -[main]: ./pbts_001_draft.md -[v1]: ./pbts-sysmodel_001_draft.md +[main]: ./README.md +[main_v1]: ./pbts_001_draft.md + +[algorithm]: ./pbts-algorithm_002_draft.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md + +[sysmodel]: ./pbts-sysmodel_002_draft.md +[sysmodel_v1]: ./pbts-sysmodel_001_draft.md + [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md index c3c40036..a85b6aa6 100644 --- a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md @@ -1,6 +1,6 @@ -# Proposer-Based Time +# Proposer-Based Time (first draft) ## Current BFTTime @@ -251,22 +251,17 @@ For analyzing real-time safety (Point 5), we use a system parameter `ACCURACY`, 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. -- [Part I - System Model and Properties][sysmodel] -- [Part II - Protocol specification][algorithm] +- [Part I - System Model and Properties][sysmodel_v1] +- [Part II - Protocol specification][algorithm_v1] - [TLA+ Specification][proposertla] -[arXiv]: https://arxiv.org/abs/1807.04938 - -[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md - -[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md - -[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md +[algorithm_v1]: ./pbts-algorithm_001_draft.md -[algorithm]: ./pbts-algorithm_002_draft.md - -[sysmodel]: ./pbts-sysmodel_002_draft.md - -[main]: ./pbts_001_draft.md +[sysmodel_v1]: ./pbts-sysmodel_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla + +[bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md +[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md +[lcspec]: https://github.com/tendermint/spec/tree/master/spec/light-client +[arXiv]: https://arxiv.org/abs/1807.04938 From 53efe84e1de7ea53340478fe28b863f6991d3a4f Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 18:11:45 +0100 Subject: [PATCH 11/14] PBTS: moved first drafts to v1/, links updated --- spec/consensus/proposer-based-timestamp/README.md | 6 +++--- .../proposer-based-timestamp/pbts-algorithm_002_draft.md | 2 +- .../proposer-based-timestamp/pbts-sysmodel_002_draft.md | 4 +--- .../{ => v1}/pbts-algorithm_001_draft.md | 2 +- .../{ => v1}/pbts-sysmodel_001_draft.md | 2 +- .../proposer-based-timestamp/{ => v1}/pbts_001_draft.md | 2 +- 6 files changed, 8 insertions(+), 10 deletions(-) rename spec/consensus/proposer-based-timestamp/{ => v1}/pbts-algorithm_001_draft.md (99%) rename spec/consensus/proposer-based-timestamp/{ => v1}/pbts-sysmodel_001_draft.md (99%) rename spec/consensus/proposer-based-timestamp/{ => v1}/pbts_001_draft.md (99%) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 4eefcca5..eba8be15 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -125,13 +125,13 @@ The full solution is detailed and formalized in the [Protocol Specification][alg - [Protocol Specification][algorithm] - [TLA+ Specification][proposertla] (**outdated**) -[main_v1]: ./pbts_001_draft.md +[main_v1]: ./v1/pbts_001_draft.md [algorithm]: ./pbts-algorithm_002_draft.md -[algorithm_v1]: ./pbts-algorithm_001_draft.md +[algorithm_v1]: ./v1/pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_002_draft.md -[sysmodel_v1]: ./pbts-sysmodel_001_draft.md +[sysmodel_v1]: ./v1/pbts-sysmodel_001_draft.md [proposertla]: ./tla/TendermintPBT_001_draft.tla 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 3cf0f653..73c4f484 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -140,7 +140,7 @@ Back to [main document][main]. [main]: ./README.md -[algorithm_v1]: ./pbts-algorithm_001_draft.md +[algorithm_v1]: ./v1/pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_002_draft.md diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md index f6f7d5e7..f207a480 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md @@ -249,12 +249,10 @@ The precise behavior for this workaround is under [discussion](https://github.co Back to [main document][main]. [main]: ./README.md -[main_v1]: ./pbts_001_draft.md [algorithm]: ./pbts-algorithm_002_draft.md -[algorithm_v1]: ./pbts-algorithm_001_draft.md [sysmodel]: ./pbts-sysmodel_002_draft.md -[sysmodel_v1]: ./pbts-sysmodel_001_draft.md +[sysmodel_v1]: ./v1/pbts-sysmodel_001_draft.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md b/spec/consensus/proposer-based-timestamp/v1/pbts-algorithm_001_draft.md similarity index 99% rename from spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md rename to spec/consensus/proposer-based-timestamp/v1/pbts-algorithm_001_draft.md index 00ea41f9..c8fd08ef 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/v1/pbts-algorithm_001_draft.md @@ -156,7 +156,7 @@ Back to [main document][main_v1]. [main_v1]: ./pbts_001_draft.md -[algorithm]: ./pbts-algorithm_002_draft.md +[algorithm]: ../pbts-algorithm_002_draft.md [algorithm_v1]: ./pbts-algorithm_001_draft.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/v1/pbts-sysmodel_001_draft.md similarity index 99% rename from spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md rename to spec/consensus/proposer-based-timestamp/v1/pbts-sysmodel_001_draft.md index b87da65c..e721fe07 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/v1/pbts-sysmodel_001_draft.md @@ -189,6 +189,6 @@ Back to [main document][main_v1]. [algorithm_v1]: ./pbts-algorithm_001_draft.md -[sysmodel]: ./pbts-sysmodel_002_draft.md +[sysmodel]: ../pbts-sysmodel_002_draft.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/v1/pbts_001_draft.md similarity index 99% rename from spec/consensus/proposer-based-timestamp/pbts_001_draft.md rename to spec/consensus/proposer-based-timestamp/v1/pbts_001_draft.md index a85b6aa6..e269cc79 100644 --- a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/v1/pbts_001_draft.md @@ -259,7 +259,7 @@ This specification describes the changes needed to be done to the Tendermint con [sysmodel_v1]: ./pbts-sysmodel_001_draft.md -[proposertla]: ./tla/TendermintPBT_001_draft.tla +[proposertla]: ../tla/TendermintPBT_001_draft.tla [bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md [tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md From 1c7a61d6dad1e24a9de760dc790945c751a7bd16 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Wed, 26 Jan 2022 18:28:12 +0100 Subject: [PATCH 12/14] PBTS: added issues to README, link to arXiv PDF --- .../proposer-based-timestamp/README.md | 26 ++++++++++++++++--- .../pbts-algorithm_002_draft.md | 2 +- .../pbts-sysmodel_002_draft.md | 2 +- 3 files changed, 24 insertions(+), 6 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index eba8be15..1d2fae54 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -74,7 +74,7 @@ receives, for the first time, a proposal with timestamp `ts`: - **[Time-Validity]** The proposed timestamp `ts` received at local time `t` is accepted if it satisfies the **timely** predicate: -> `ts - PRECISION <= t <= ts + MSGDELAY + PRECISION` + > `ts - PRECISION <= t <= ts + MSGDELAY + PRECISION` The left inequality of the *timely* predicate establishes that proposed timestamps should be in the past, when adjusted by the clocks `PRECISION`. @@ -123,7 +123,19 @@ The full solution is detailed and formalized in the [Protocol Specification][alg - [System Model and Properties][sysmodel] - [Protocol Specification][algorithm] -- [TLA+ Specification][proposertla] (**outdated**) +- [TLA+ Specification][proposertla] (first draft, not updated) + +### Open issues + +- [PBTS: evidence #355][issue355]: not really clear the context, probably not going to be solved. +- [PBTS: should synchrony parameters be adaptive? #371][issue371] +- [PBTS: Treat proposal and block parts explicitly in the spec #372][issue372] +- [PBTS: margins for proposal times assigned by Byzantine proposers #377][issue377] + +### Closed issues + +- [Proposer time - fix message filter condition #353][issue353] +- [PBTS: association between timely predicate and timeout_commit #370][issue370] [main_v1]: ./v1/pbts_001_draft.md @@ -136,5 +148,11 @@ The full solution is detailed and formalized in the [Protocol Specification][alg [proposertla]: ./tla/TendermintPBT_001_draft.tla [bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md -[arXiv]: https://arxiv.org/abs/1807.04938 - +[arXiv]: https://arxiv.org/pdf/1807.04938.pdf + +[issue353]: https://github.com/tendermint/spec/issues/353 +[issue355]: https://github.com/tendermint/spec/issues/355 +[issue370]: https://github.com/tendermint/spec/issues/370 +[issue371]: https://github.com/tendermint/spec/issues/371 +[issue372]: https://github.com/tendermint/spec/issues/372 +[issue377]: https://github.com/tendermint/spec/issues/377 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 73c4f484..8e60c013 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -145,4 +145,4 @@ Back to [main document][main]. [sysmodel]: ./pbts-sysmodel_002_draft.md [bfttime]: https://github.com/tendermint/spec/blob/master/spec/consensus/bft-time.md -[arXiv]: https://arxiv.org/abs/1807.04938 +[arXiv]: https://arxiv.org/pdf/1807.04938.pdf diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md index f207a480..832d11c9 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_002_draft.md @@ -255,4 +255,4 @@ Back to [main document][main]. [sysmodel]: ./pbts-sysmodel_002_draft.md [sysmodel_v1]: ./v1/pbts-sysmodel_001_draft.md -[arXiv]: https://arxiv.org/abs/1807.04938 +[arXiv]: https://arxiv.org/pdf/1807.04938.pdf From e0516f376e52df5f2205adc55503d795d62e0e38 Mon Sep 17 00:00:00 2001 From: Daniel Date: Fri, 4 Feb 2022 10:31:09 +0100 Subject: [PATCH 13/14] Apply suggestions from code review Co-authored-by: William Banfield <4561443+williambanfield@users.noreply.github.com> Co-authored-by: Josef Widder <44643235+josef-widder@users.noreply.github.com> --- spec/consensus/proposer-based-timestamp/README.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index 1d2fae54..c50de5ab 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -6,14 +6,13 @@ that uses proposer-based timestamps. ## Context Tendermint provides a deterministic, Byzantine fault-tolerant, source of time, -defined by the `Time` field present in the headers of committed blocks, -representing the block's timestamp. +defined by the `Time` field present in the headers of committed blocks. In the current consensus implementation, the timestamp of a block is computed by the [`BFTTime`][bfttime] algorithm: -- Validators timestamps the `Precommit` messages they broadcast. -Timestamps are retrieved from the validator's local clocks, +- Validators include a timestamp in the `Precommit` messages they broadcast. +Timestamps are retrieved from the validators' local clocks, with the only restriction that they must be **monotonic**: - The timestamp of a `Precommit` message voting for a block @@ -43,8 +42,8 @@ should bear some resemblance to real time, which is **not guaranteed**. A more comprehensive discussion of the limitations of `BFTTime` can be found in the [first draft][main_v1] of this proposal. -Of particular interest is to possibility of having validators equipped "faulty" clocks, -not fairly accurate with real time, that detain more than `f` voting power, +Of particular interest is to possibility of having validators equipped with "faulty" clocks, +not fairly accurate with real time, that control more than `f` voting power, plus the proposer's flexibility when selecting a `Commit` set, and thus determining the timestamp for a block. @@ -101,7 +100,7 @@ The block's timestamp represents the time at which it was assembled reads a time greater than the timestamp of the previous block; - A validator only prevotes for *timely* blocks, -that is, blocks whose timestamps are considered *timely* (check added to line 23). +that is, blocks whose timestamps are considered *timely* (compared to the original Tendermint consensus, a check is added to line 23). If the block proposed in a round is considered *untimely*, the validator prevotes `nil` (line 26): @@ -113,7 +112,7 @@ the validator prevotes `nil` (line 26): as they have already been evaluated as *timely* at a previous round. The more complex change proposed regards blocks that can be re-proposed in multiple rounds. -The current solution improves the [first version][algorithm_v1] +The current solution improves the [first version of the specification][algorithm_v1] (that never had been implemented) by simplifying the way this situation is handled, from a recursive reasoning regarding valid blocks that are re-proposed. From 78745e6d475a5e1e6e6bec06144e9c8f74c3841e Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Fri, 4 Feb 2022 10:38:23 +0100 Subject: [PATCH 14/14] Fixing linting problems --- spec/consensus/proposer-based-timestamp/README.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md index c50de5ab..6f52099c 100644 --- a/spec/consensus/proposer-based-timestamp/README.md +++ b/spec/consensus/proposer-based-timestamp/README.md @@ -15,7 +15,7 @@ computed by the [`BFTTime`][bfttime] algorithm: Timestamps are retrieved from the validators' local clocks, with the only restriction that they must be **monotonic**: - - The timestamp of a `Precommit` message voting for a block + - The timestamp of a `Precommit` message voting for a block cannot be earlier than the `Time` field of that block; - The timestamp of a block is deterministically computed from the timestamps of @@ -23,7 +23,7 @@ a set of `Precommit` messages that certify the commit of the previous block. This certificate, a set of `Precommit` messages from a round of the previous height, is selected by the block's proposer and stored in the `Commit` field of the block: - - The block timestamp is the *median* of the timestamps of the `Precommit` messages + - The block timestamp is the *median* of the timestamps of the `Precommit` messages included in the `Commit` field, weighted by their voting power. Block timestamps are **monotonic** because timestamps of valid `Precommit` messages are monotonic; @@ -93,10 +93,10 @@ summarized below: The block's timestamp represents the time at which it was assembled (after the `getValue()` call in line 18 of the [arXiv][arXiv] algorithm): - - Block timestamps are definitive, meaning that the original timestamp + - Block timestamps are definitive, meaning that the original timestamp is retained when a block is re-proposed (line 16); - - To preserve monotonicity, a proposer might need to wait until its clock + - To preserve monotonicity, a proposer might need to wait until its clock reads a time greater than the timestamp of the previous block; - A validator only prevotes for *timely* blocks, @@ -104,10 +104,10 @@ that is, blocks whose timestamps are considered *timely* (compared to the origin If the block proposed in a round is considered *untimely*, the validator prevotes `nil` (line 26): - - Validators register the time at which they received `Proposal` messages, + - Validators register the time at which they received `Proposal` messages, in order to evaluate the *timely* predicate; - - Blocks that are re-proposed because they received `2f+1 Prevotes` + - Blocks that are re-proposed because they received `2f+1 Prevotes` in a previous round (line 28) are not subject to the *timely* predicate, as they have already been evaluated as *timely* at a previous round.