edsko
commented
4 years ago Re-prioritizing this, as this is a difficult problem to solve. Instead we will simply say that when the system clock is changed backwards, it's the user's responsibility to make a decision to wipe the DB or not. If the DB is not wiped, then some blocks might be considered to be immutable that should not have been. If the clock is only moved back a little bit, these blocks would have been nearly k deep into the chain and so almost certainly immutable anyway. The further the clock is moved back, the more likely it is that we adopted some blocks are immutable that we shouldn't have. In this case, the user may wish to decide to wipe their DB and do a fresh sync.
Note that if the user moves their clock back more than k (say, one day), the immutable DB might even contain blocks from the future; that we can and should detect, created a separate ticket for that at input-output-hk/ouroboros-network#1550.
When the system clock is moved back, some blocks that we thought were immutable might turn out not to be. When the node detects that the clock moves back. it will die with an exception (#759). When we subsequently restart the node, we should do a validation pass. When the imm DB is validating all blocks, it should validate that all blocks there really are immutable, i.e., older than
k(according to the wall clock).Any blocks that are not immutable should just be considered as invalid, and deleted. The ChainDB spec says that we should move them to the volatile DB instead; this is a possibility, but strictly an optimization. This is such an unlikely event that requiring the node to get (at most)
knew blocks from an upstream node would be no big deal at all.