Skip to content

consensus: proposer-based timestamps #2840

@ebuchman

Description

@ebuchman

Current mechanism for BFT time includes a timestamp in every precommit, and just takes the median.

While simple and live despite arbitrary clock drift, it has some problems:

An alternative, originally proposed in #1615, is to let the proposer use their own local timestamp, and for validators to only vote for the block if the timestamp is within some range of their own clock. This requires all nodes to keep their clocks reasonably closely synced, and was originally rejected/postponed for this reason. But in order to solve the above two issues, we should reconsider this solution. We can also include an option to disable it, so folks that don't want to worry about synced clocks won't have to (but of course it means they might not have accurate timestamps in blocks).

We should write a new ADR for this and do some more analysis before fully moving forward with it.

Note there is also a follow up issue from the last BFT-time PR: #2309

Metadata

Metadata

Assignees

No one assigned

    Labels

    C:consensusComponent: ConsensusT:breakingType: Breaking Changestalefor use by stalebot

    Type

    No type

    Projects

    Status

    Done

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions