You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

95 lines
4.5 KiB

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