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.