mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-09-19 14:34:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

pr feedback

Browse Source
This commit is contained in:
William Banfield
2022-03-03 16:24:43 -05:00
parent ca21cb28f4
commit fca4e7abce
1 changed files with 53 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tendermint-core/consensus/proposer-based-timestamps.md
+53 -48
View File
@@ -1,41 +1,42 @@
--- --- order: 3 ---
order: 3
---
# Proposer-Based Timestamps # PBTS
This document provides an overview of the Proposer-Based Timestamp algorithm This document provides an overview of the Proposer-Based Timestamp (PBTS)
added to Tendermint in the v0.36 release. This document outlines the core functionality algorithm added to Tendermint in the v0.36 release. It outlines the core
as well as the parameters and constraints of the this algorithm. functionality as well as the parameters and constraints of the this algorithm.
# Algorithm Overview ## Algorithm Overview
The proposer-based timestamps algorithm defines a way for a Tendermint blockchain The PBTS algorithm defines a way for a Tendermint blockchain to create block
to create block timestamps that are within a reasonable bound of the clocks of the timestamps that are within a reasonable bound of the clocks of the validators on
validators on the network. the network. This replaces the original BFTTime algorithm for timestamp
assignment that relied on the timestamps included in precommit messages.
## Algorithm Parameters ## Algorithm Parameters
The functionality of the Proposer-Based Timestamps algorithm is governed by two The functionality of the PBTS algorithm is governed by two parameters within
parameters within Tendermint. These two parameters are [consensus parameters](https://github.com/tendermint/tendermint/blob/c42c6d06d2986791ad1cb8742824818edd9b6323/spec/abci/apps.md#L291), Tendermint. These two parameters are [consensus
parameters](https://github.com/tendermint/tendermint/blob/master/spec/abci/apps.md#L291),
meaning they are configured by the ABCI application and are expected to be the meaning they are configured by the ABCI application and are expected to be the
same across all nodes on the network. same across all nodes on the network.
### `Precision` ### `Precision`
The `Precision` parameter configures the acceptable upper-bound of clock drift among The `Precision` parameter configures the acceptable upper-bound of clock drift
all of the nodes on a Tendermint network. Any two nodes on a Tendermint network among all of the nodes on a Tendermint network. Any two nodes on a Tendermint
are expected to have clocks that differ by at most `Precision` seconds? Ms? at network are expected to have clocks that differ by at most `Precision`
any given instant. milliseconds any given instant.
### `MessageDelay` ### `MessageDelay`
The `MessageDelay` parameter configures the acceptable upper-bound for transmitting The `MessageDelay` parameter configures the acceptable upper-bound for
a `Proposal` message from the proposer to _all_ of the validators on the network. transmitting a `Proposal` message from the proposer to _all_ of the validators
on the network.
Networks that want very tight bounds on their timestamps should set a smaller value Networks should choose as small a value for `MessageDelay` as is practical,
for `MessageDelay`. Highly distributed networks or networks with generally slow provided it is large enough that messages can reach all participants with high
rates of transmission should set a larger value for `MessageDelay`. probability given the number of participants and latency of their connections.
## Algorithm Concepts ## Algorithm Concepts
@@ -49,41 +50,45 @@ The following protocols and application features require a reliable source of ti
* Tendermint Light Clients [rely on correspondence between their known time](https://github.com/tendermint/tendermint/blob/master/spec/light-client/verification/README.md#definitions-1) and the block time for block verification. * Tendermint Light Clients [rely on correspondence between their known time](https://github.com/tendermint/tendermint/blob/master/spec/light-client/verification/README.md#definitions-1) and the block time for block verification.
* Tendermint Evidence validity is determined [either in terms of heights or in terms of time](https://github.com/tendermint/tendermint/blob/master/spec/consensus/evidence.md#verification). * Tendermint Evidence validity is determined [either in terms of heights or in terms of time](https://github.com/tendermint/tendermint/blob/master/spec/consensus/evidence.md#verification).
* Unbonding of staked assets in the Cosmos Hub [occurs after a period of 21 days](https://github.com/cosmos/governance/blob/master/params-change/Staking.md#unbondingtime). * Unbonding of staked assets in the Cosmos Hub [occurs after a period of 21
* IBC packets can use either a [timestamp or a height to timeout packet delivery](https://docs.cosmos.network/v0.44/ibc/overview.html#acknowledgements) days](https://github.com/cosmos/governance/blob/master/params-change/Staking.md#unbondingtime).
* IBC packets can use either a [timestamp or a height to timeout packet
delivery](https://docs.cosmos.network/v0.44/ibc/overview.html#acknowledgements)
### Proposer Selects a Block Timestamp ### Proposer Selects a Block Timestamp
When the proposer node creates a new block proposal, the node reads the time from When the proposer node creates a new block proposal, the node reads the time
its local clock and uses this reading as the timestamp for the proposed block. from its local clock and uses this reading as the timestamp for the proposed
block.
### Timely-ness ### Timeliness
When each validator on a Tendermint network receives a proposed block, it performs When each validator on a Tendermint network receives a proposed block, it
a series of checks to ensure that the block can be considered valid as a candidate performs a series of checks to ensure that the block can be considered valid as
to be the next block in the chain. a candidate to be the next block in the chain.
The Proposer-Based Timestamps algorithm performs a validity check on the timestamp of proposed blocks. The PBTS algorithm performs a validity check on the timestamp of proposed
When a validator receives a proposal it ensures that the timestamp in the proposal blocks. When a validator receives a proposal it ensures that the timestamp in
is within a bound of the validator's local clock. Specifically, the algorithm the proposal is within a bound of the validator's local clock. Specifically, the
checks that the timestamp is no more than `Precision` greater than the node's local clock algorithm checks that the timestamp is no more than `Precision` greater than the
and no less than `Precision` + `MessageDelay` behind than the node's local clock. node's local clock and no less than `Precision` + `MessageDelay` behind than the
This creates range of acceptable timestamps around the node's local time. If node's local clock. This creates range of acceptable timestamps around the
the timestamp is within this range, the Proposer-Based Timestamps algorithm considers node's local time. If the timestamp is within this range, the PBTS algorithm
the block `timely`. If a block is not `timely`, the node will issue a `nil` `prevote` considers the block **timely**. If a block is not **timely**, the node will
for this block, signaling to the rest of the network that the node does not consider issue a `nil` `prevote` for this block, signaling to the rest of the network
the block to be valid. that the node does not consider the block to be valid.
### Clock Synchronization ### Clock Synchronization
The Proposer-Based Timestamps algorithm requires the clocks of the validators on a The PBTS algorithm requires the clocks of the validators on a Tendermint network
Tendermint network are within `Precision` of each other. In practice, this means are within `Precision` of each other. In practice, this means that validators
that validators should periodically synchronize to a reliable NTP server. Validators should periodically synchronize to a reliable NTP server. Validators that drift
that drift too far away from the rest of the network will no longer propose too far away from the rest of the network will no longer propose blocks with
blocks with valid timestamps. Additionally they will not view the timestamps of blocks proposed valid timestamps. Additionally they will not view the timestamps of blocks
by their peers to be valid either. proposed by their peers to be valid either.
## See Also ## See Also
* [The Proposer-Based Timestamps specification][https://github.com/tendermint/tendermint/blob/master/spec/consensus/proposer-based-timestamp/README.md] contains all of the details of * [The PBTS specification](https://github.com/tendermint/tendermint/blob/master/spec/consensus/proposer-based-timestamp/README.md)
the algorithm. contains all of the details of the algorithm.