github.com/ari-anchor/sei-tendermint@v0.0.0-20230519144642-dc826b7b56bb/docs/tendermint-core/consensus/proposer-based-timestamps.md (about)

     1  ---
     2  order: 3
     3  ---
     4  
     5  # PBTS
     6  
     7   This document provides an overview of the Proposer-Based Timestamp (PBTS)
     8   algorithm added to Tendermint in the v0.36 release. It outlines the core
     9   functionality as well as the parameters and constraints of the this algorithm.
    10  
    11  ## Algorithm Overview
    12  
    13  The PBTS algorithm defines a way for a Tendermint blockchain to create block
    14  timestamps that are within a reasonable bound of the clocks of the validators on
    15  the network. This replaces the original BFTTime algorithm for timestamp
    16  assignment that computed a timestamp using the timestamps included in precommit
    17  messages.
    18  
    19  ## Algorithm Parameters
    20  
    21  The functionality of the PBTS algorithm is governed by two parameters within
    22  Tendermint. These two parameters are [consensus
    23  parameters](https://github.com/tendermint/tendermint/blob/master/spec/abci/apps.md#L291),
    24  meaning they are configured by the ABCI application and are therefore the same
    25  same across all nodes on the network.
    26  
    27  ### `Precision`
    28  
    29  The `Precision` parameter configures the acceptable upper-bound of clock drift
    30  among all of the nodes on a Tendermint network. Any two nodes on a Tendermint
    31  network are expected to have clocks that differ by at most `Precision`
    32  milliseconds any given instant.
    33  
    34  ### `MessageDelay`
    35  
    36  The `MessageDelay` parameter configures the acceptable upper-bound for
    37  transmitting a `Proposal` message from the proposer to _all_ of the validators
    38  on the network.
    39  
    40  Networks should choose as small a value for `MessageDelay` as is practical,
    41  provided it is large enough that messages can reach all participants with high
    42  probability given the number of participants and latency of their connections.
    43  
    44  ## Algorithm Concepts
    45  
    46  ### Block timestamps
    47  
    48  Each block produced by the Tendermint consensus engine contains a timestamp.
    49  The timestamp produced in each block is a meaningful representation of time that is
    50  useful for the protocols and applications built on top of Tendermint.
    51  
    52  The following protocols and application features require a reliable source of time:
    53  
    54  * 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.
    55  * Tendermint Evidence expiration is determined [either in terms of heights or in terms of time](https://github.com/tendermint/tendermint/blob/master/spec/consensus/evidence.md#verification).
    56  * Unbonding of staked assets in the Cosmos Hub [occurs after a period of 21
    57   days](https://github.com/cosmos/governance/blob/master/params-change/Staking.md#unbondingtime).
    58  * IBC packets can use either a [timestamp or a height to timeout packet
    59   delivery](https://docs.cosmos.network/v0.44/ibc/overview.html#acknowledgements)
    60  
    61  ### Proposer Selects a Block Timestamp
    62  
    63  When the proposer node creates a new block proposal, the node reads the time
    64  from its local clock and uses this reading as the timestamp for the proposed
    65  block.
    66  
    67  ### Timeliness
    68  
    69  When each validator on a Tendermint network receives a proposed block, it
    70  performs a series of checks to ensure that the block can be considered valid as
    71  a candidate to be the next block in the chain.
    72  
    73  The PBTS algorithm performs a validity check on the timestamp of proposed
    74  blocks. When a validator receives a proposal it ensures that the timestamp in
    75  the proposal is within a bound of the validator's local clock. Specifically, the
    76  algorithm checks that the timestamp is no more than `Precision` greater than the
    77  node's local clock and no less than `Precision` + `MessageDelay` behind than the
    78  node's local clock. This creates range of acceptable timestamps around the
    79  node's local time. If the timestamp is within this range, the PBTS algorithm
    80  considers the block **timely**. If a block is not **timely**, the node will
    81  issue a `nil` `prevote` for this block, signaling to the rest of the network
    82  that the node does not consider the block to be valid.
    83  
    84  ### Clock Synchronization
    85  
    86  The PBTS algorithm requires the clocks of the validators on a Tendermint network
    87  are within `Precision` of each other. In practice, this means that validators
    88  should periodically synchronize to a reliable NTP server. Validators that drift
    89  too far away from the rest of the network will no longer propose blocks with
    90  valid timestamps. Additionally they will not view the timestamps of blocks
    91  proposed by their peers to be valid either.
    92  
    93  ## See Also
    94  
    95  * [The PBTS specification](https://github.com/tendermint/tendermint/blob/master/spec/consensus/proposer-based-timestamp/README.md)
    96   contains all of the details of the algorithm.