What are the actual semantics of Header.Time?
coriolinus opened this issue · 4 comments
It's clear from the documentation that this is an int64. However, that's hardly unambiguous. While it's probably either Unix or UnixNano, users just don't have any information about which semantics are expected.
Request documentation of:
- what exactly
abci/types.Header.Timerepresents - what validation, if any, tendermint performs to ensure that all nodes in the consensus agree on the block time
- how applications can perform custom validation of a proposed block time, if they have different or more stringent requirements for consensus about the current time than tendermint provides by default
It's .Unix(): https://github.com/tendermint/tendermint/blob/master/types/protobuf.go#L39.
Maybe we should change it to the google recommended Timestamp
What do you think ?
what validation, if any, tendermint performs to ensure that all nodes in the consensus agree on the block time
Currently we're just using the proposers time, but the plan is to take the median of the timestamps from the LastCommit signatures. See the spec.
We've been considering an alternative where the proposer can propose their local time and others will require it to be within some bounds (see spec and PR), but that creates new requirements on tendermint nodes to keep clocks synced.
For now we will stick with the median of the precommit timestamps. In the future when we want to move to BLS to compress signatures, we'll need to go back to proposer-based BFT time because BLS requires each vote to have the same content (besides signature).
how applications can perform custom validation of a proposed block time, if they have different or more stringent requirements for consensus about the current time than tendermint provides by default
This isn't possible yet because Tendermint checks block validity before talking to the app. In the future we'd like to open the possibility for the app to control proposals, but we haven't had a chance to work on the design. Perhaps you'd like to submit a proposal ?
Increasing the precision of the timestamp would be useful to us. We're agnostic as to whether it's the google recommended timestamp, UnixNano, or some other implementation.
I think that the current spec behavior for time, taking the median of timestamps from the voters, will satisfy our use case, though I'm going to have to think about that one a bit more. We definitely need more validation than just accepting whatever the proposer submits.
Thanks for answering this!
moved issue to tendermint/tendermint#1857