Proposal: Reject consensus messages with inconsistent timestamp #13
Description
Status
- Rejected: the solution proposed in this DIP is meant to solve a problem with forking. However, the same problem is already addressed by Rolling Finality. Moreover, the introduction of timestamp-based logics potentially introduces new issues and side-channels that can be exploited and lead to undesirable situations.
Summary
This DIP proposes to discard consensus messages if their timestamp is not coherent with the expected time frame for the iteration.
Possible solution design or implementation
At round R and iteration I:
-
set$T_{R,I} = TS(Candidate_{R-1}) + (I \times MaxIterationTime)$ - when a message for R,I is received:
-
assert$T_{R,I} - slippage < TS(Msg_{R,I}) < T_{R,I} + MaxIterationTime + slippage$
-
where:
-
$TS(Msg_{R,I})$ is the time when the message was received -
$TS(Candidate_{R-1})$ is the timestamp of the Candidate message for the accepted block in round R-1 -
$MaxIterationTime$ is the maximum time an iteration can take -
$slippage$ is the maximum margin of error for the timestamp