Should go-header account for headers that fail skipping verification?

[renaynay]

We currently have the concept of SoftFailure inside go-header whereby we try to perform skipping verification on a non-adjacent header some distance into the future, and it could potentially fail verification (for celestia-node's case) if that header does not have 2/3 validator set overlap (even though, if applied adjacently, the header is valid).

The question here is: should go-header handle for the case where a header can fail skipping verification but may pass if applied adjacently?

The alternative, if were not to handle for it, would be to remove the concept of a SoftFailure and just discard the header, re-requesting it when it's needed for syncing where it can be applied adjacently. In the context of our backwards sync design, this would remove the need for a pending cache in syncer.

It would be good to nail down:

• is it a common or probable case on a real network where a header within the unbonding period could fail non-adjacent verification (cc @evan-forbes )
• if not, should go-header handle for such failures?

cc @cristaloleg @Wondertan

[evan-forbes]

is it a common or probable case on a real network where a header within the unbonding period could fail non-adjacent verification

its unlikely that the voting power would change > 1/3 in 3 weeks, however always a possibility and would halt the network if we don't have a way to handle it.

[Wondertan]

While explaining this issue to @walldiss, I realized a few things about skipping verification that will give us a definitive answer as to whether we need to keep forward sync or not.

• Skipping verification exists, and we want to use it to the max.
• Skipping verification exists because the SDK's staking module limits unstaking.
• Staking module behavior introduces assumptions that are subject to change.
  • Mainly, core-app and research teams wanted to make the rate-limited unstaking queue
    • Instead of a fixed time, unstaking has like per day limit of how much stake can leave the system, so if there no contention, unstaking might happen instantaneously and cause
      rapid validator set changes.
• Thus, If we make go-header hardcode rely on skipping verification, it will break again once staking module changes.
• Subsequently, let's keep forward verification to decouple the go-header from the assumptions of the staking module, even if it is worth additional complexity that we can still try to minimize.

[Wondertan]

Cc @evan-forbes to validate this thinking