search

filecoin-project / go-f3

Golang implementation of Fast Finality for Filecoin (F3)
Apache License 2.0
12 stars 7 forks source link

Prevent very large reverts based on finality certificates #717

Closed Kubuxu closed 1 month ago

Kubuxu commented 1 month ago

Lotus is not designed to handle only a few large reverts (for sure not 900+ epochs). Introduce a way to prevent that in Lotus and notify the operator.

Stebalien commented 1 month ago

Turns out we already handle this case: https://github.com/filecoin-project/lotus/blob/02a8b972db82eee0ff109366f57122caf7790128/chain/store/store.go#L813-L816 (although for the wrong reasons... I'll update the comment).

Stebalien commented 1 month ago

Ah... nvm. That refuses to go that far back into the past, but will still fork if the common ancestor is that far back.

Stebalien commented 1 month ago

Actually, that's fine? I don't want to go back 900 epochs, but if 2/3rds of the power does that and then makes process by finalizing tipsets < 900 epochs ago on the fork... I might as well switch. So I think we're good as-is.

Kubuxu commented 1 month ago

Turns out we already handle this case: https://github.com/filecoin-project/lotus/blob/02a8b972db82eee0ff109366f57122caf7790128/chain/store/store.go#L813-L816

Is it this case? I don't think it is, the 900 is how many blocks can get reverted (so it is head.Epoch - commonAncestor.Epoch), this only says that you cannot set a checkpoint that is too far in the past

Stebalien commented 1 month ago

See my later comments. But given F3's 100 epoch max-per-instance, we could end up reverting 1000 epochs, but no more.

Yeah, we should probably fix this regardless.

Stebalien commented 1 month ago

Hm.... well, that would be a very very special case. Basically, worst-case is that we could revert 900 epochs plus the worst-case natural revert (most likely 903-ish).

Stebalien commented 1 month ago

Eh, I'm just going to fully fix this so it's easy to reason about.