From 880279b245021fba13acb8a751e3fc0b347d7a7e Mon Sep 17 00:00:00 2001 From: William Banfield Date: Fri, 12 Nov 2021 09:33:59 -0500 Subject: [PATCH] update timely description for non-polka --- docs/architecture/adr-071-proposer-based-timestamps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/architecture/adr-071-proposer-based-timestamps.md b/docs/architecture/adr-071-proposer-based-timestamps.md index d05f8b1ca..9bb1c245d 100644 --- a/docs/architecture/adr-071-proposer-based-timestamps.md +++ b/docs/architecture/adr-071-proposer-based-timestamps.md @@ -260,8 +260,8 @@ The [POLRound](https://github.com/tendermint/tendermint/blob/68ca65f5d79905abd55 A negative value in the `POLRound` field indicates that the block has not previously been proposed on the network. Therefore the validation logic will check for timely when `POLRound < 0`. -When a validator receives a `Proposal` message, the validator will check that the `Proposal.Timestamp` is within `PRECISION` and `MSGDELAY` of the current Unix time known to the validator. -If the timestamp is not within `PRECISION` and `MSGDELAY` of the current Unix time known to the validator, the proposed block will not be considered `timely`. +When a validator receives a `Proposal` message, the validator will check that the `Proposal.Timestamp` is at most `PRECISION` greater than the current Unix time known to the validator, and at minimum `PRECISION + MSGDELAY` less than the current Unix time known to the validator. +If the timestamp is not within these bounds, the proposed block will not be considered `timely`. Once a full block matching the `Proposal` message is received, the validator will also check that the timestamp in the `Header.Timestamp` of the block matches this `Proposal.Timestamp`. Using the `Proposal.Timestamp` to check `timely` allows for the `MSGDELAY` parameter to be more finely tuned since `Proposal` messages do not change sizes and are therefore faster to gossip than full blocks across the network.