Prevent long-range attacks

[Wondertan]

currently, if nodes start following a fork (outside of the unbonding period), they will discard the subjective head (which was given by a subjectively chosen trusted peer or the default baked in trusted peer in node). This is an issue that can easily be fixed by:

• either by backwards-sync (which would be very time consuming), or
• a simpler fix: once your fork passed the time or the height of the subjective header (inside of the unbonding period), you realize you are actually on a fork and you (store the fork as evidence and) halt; it’s important that the fork headers aren’t gossiped. Recovering from this requires you to restart the node, ideally blacklisting the peers that fooled you

Originally posted by @liamsi in https://github.com/celestiaorg/go-header/issues/79#issuecomment-1632473047

[renaynay]

Design

Prio 1: Fork following prevention

• save subjective head as canonical sync target, do not throw it away if it does not pass verification when applied to n-1, throw away the chain that was synced and restart the syncing process (until we have saving fork evidence as a feat)
• use pending only for additional headers that come in through headersub and do not pass verification (SoftFailure == true), try to apply them where possible (where they pass adjacent verification against n-1)

Prio 2: Saving fork as evidence

this can come a bit later, but if it's found that n-1 does not apply to the canonical subjective head, then the headerchain should be saved to some datastore (fork) and log.Fatal'ed

[Wondertan]

save subjective head as canonical sync target,

Just to keep our terminologies in place, let's avoid saying the subjective head is a sync target. We should differentiate between them.

restart the syncing process (until we have saving fork evidence as a feat)

We should avoid implementing syncing restart logic, in favor of future backward syncing, s.t we don't do anything unnecessary. For now we can panic, I guess.

use pending only for additional headers that come in through headersub and do not pass verification (SoftFailure == true), try to apply them where possible (where they pass adjacent verification against n-1)

We should use pending for both subjective headers and sync targets(soft failure == true), s.t. syncer loop knows how to sync them. But we need to differentiate between them in pending, s.t. same syncer loop can apply different logic on them in case verification fails, s.t. We can do the first point

[renaynay]

@Wondertan we should also consider the scenario where the node begins to follow a fork after applying the trusted subjective head.

It is possible that a node comes online after a while, retrieves a trusted head from Exchange, sets as subjective head, syncs up a good chain and applies the subjective head and then continues listening for new incoming headers from gossipsub. Technically, the node could be eclipsed at this point because it could continue following a chain of "valid" network headers and doesn't have any trusted sync target to verify against.

[nashqueue]

We should create a second Fraudproof type consisting of 2 valid headers for a single height. If both headers are valid that means at least 1/3 +1 validators doubled signed.

[Wondertan]

This is what we discussed with Eiger folks yesterday. We will eventually get there, and first of all, we need a core network to be able to submit equivocation proofs to the DA network, as FPs

[nashqueue]

2 valid headers on the DA-Network are enough to create an FP , ANd you should be getting both headers so should be doable without core getting involved, or am i missing something ?

[Wondertan]

I brought up core because it has a notion of evidences that we planned to submit over the DA network at some point. It might not be necessary for the DA network as nodes can generate proofs if they detect equivocation. This even includes light nodes targeted with a validator that wants to trick them into following a faulty fork.

It also seems to me that Rollups may have similar issues with sequencers, so I agree that we should make fraud-type living in go-header once it learns the notion of validators. Right now we just abstract that away with Verify but that should change. We also want to introduce validators so that we don't duplicate validator sets in headers when they don't change.