feat: implement safe tag in tipset selection

[masih]

Implement the ability to select a tipset by tag safe. The safe tag would select the earliest between finalised and heaviest - 200.

Part of: #12990

[github-actions]

Please update the PR title to match https://github.com/filecoin-project/lotus/blob/master/CONTRIBUTING.md#pr-title-conventions

PR title now matches the required format.

[BigLep]

Everything looks good to me other than introducing a different safe value for non-ETH APIs

[rvagg]

30 for Eth as it's encoded now comes partly from FRC-0089 related work. That FRC notes that the 900 epochs are meant to provide a 2^-30 guarantee of finality at 900 epochs, hence that choice for "finalized" today. Here's a brief thread of me looking at this by running the finality calculator from the FRC against recent (at that time) epochs where the chain was relatively healthy with a win count of ~5.

Here's what looks like with that 2^-30 guarantee line in green:

log scale:

When looking at this, I didn't observe it go beyond 25 epochs to get to this level, even when the chain got a bit choppy. But I don't think I went back and looked at particularly problematic points in the life of the chain either so it may get worse. But from a "not necessarily final, but most probably safe", 30 seemed like a reasonable choice.

There was a page somewhere that listed the current bridges and their choices of finality time, they ranged from 60 to 200 IIRC, that also gives an indication of what is considered "almost final" but mostly I think that just comes from our recommendations anyway. @eshon do you have any more info on this?

IMO 30 is a good compromise, it's not finalized, but having a "safe" that's distinct from "finalized" should suggest that it's not going to be 100%, you'd pick "finalized" if you wanted that. Hopefully with F3 working properly this becomes mostly irrelevant.

[Stebalien]

I'd be careful about just hard-coding something as low as "30 epochs" without having some kind of "is the chain healthy" check. I'm mostly worried about an API provider getting stuck on a fork and not responding within ~15m.

Ideally we'd use the finality calculator, or at least estimate the safe distance by counting blocks not epochs/tipsets. I.e., walk back from the heaviest tipset until we've passed 30*5 = 150 blocks.

[rvagg]

I have a semi-working FRC-0089 finality calculator in Go but got stuck with some of the math library dependencies so never managed to finish it, at least I got frustrated enough to put it down. I could dig that code up if someone wants to help get it over the line.

[masih]

So far I have not heard back from zondax on the value of constant.

I would vote for landing this with a more conservative value: either leave it to 200 or settle for 150 and revisit later.
Rationale:

• V2 APIs are marked as experimental - we can postpone this decision.
• Better to be conservative and relax it later than having to do it other way around.
• A 30 epoch value might not provide a "Useful" API to exchanges with financial/legal obligations.

Thoughts @rvagg @Stebalien @Kubuxu ?

[rvagg]

yep, good by me, I'll even adjust ETH APIs for /v2 to follow this behaviour when f3 isn't available, I'll leave /v1 alone for now

[eshon]

@rvagg - This is a comparison of high TPS chains that can be sorted by finality... https://chainspect.app/dashboard

(Bridge finality will depend on the finality of the chains being used but AxelarScan can probably update confirmations of Filecoin bridged txns based on updates to the Filecoin Eth RPC API.)

I am much more concerned that we are going to confuse exchanges greatly if we message them about F3 too soon because we won't be able to share expected confirmation times as in the Kraken Docs on confirmation times, and vigilant network monitoring will be required for a while until F3 participation is tied to BRs.

It would be bad PR if F3 halting became a news item that we had to explain to exchanges. Perhaps FilOz should delay F3 messaging for a couple months until further analysis can be done on its performance.

[masih]

I am much more concerned that we are going to confuse exchanges greatly if we message them about F3 too soon because we won't be able to share expected confirmation times as in the Kraken Docs on confirmation times, and vigilant network monitoring will be required for a while until F3 participation is tied to BRs.

It would be bad PR if F3 halting became a news item that we had to explain to exchanges. Perhaps FilOz should delay F3 messaging for a couple months until further analysis can be done on its performance.

I think this is reasonable and I would like to point out that this conversation just needs more data, which is being collected as we speak.

I suggest we revisit the messaging after the passive testing is done.

[masih]

Echoing my response to the review comment above:

• 200 is the most reasonable and conservative safe distance value compared to smaller alternatives.
• To truly understand the fitness of this constant for its purpose more data is needed, specifically empirical measurements of F3 on mainnet. This is being performed as part of passive testing right now.
• The entire v2 API is marked as experimental and these constants can and will change.

Based on the rationale above, I am merging this PR and postponing further discussion on the value of "safe" constant until there is more data.