Add finality-related params for eth_getBlockByNumber

[eshon]

Checklist

• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated feature request to propose.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

Currently eth_getBlockByNumber params related to the finality of a block are not completely implemented in the Lotus Eth RPC API.

Here is a more detailed description of the params.

It might be helpful for RPC API users to understand the finality of a block in a way similar to Ethereum semantics so that they can better prepare themselves in the event of a reorg.

Describe the solution you'd like

safe could be used for blocks after a 30 epoch delay (as explained here)

Describe alternatives you've considered

No response

Additional context

No response

[snissn]

I see that the for api eth_getBlockByNumber has a param "finalized" - https://docs.alchemy.com/reference/eth-getblockbynumber

String - Either the hex value of a block number OR One of the following block tags:

• pending - A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet.
• latest - The most recent block in the canonical chain observed by the client, this block may be re-orged out of the canonical chain even under healthy/normal conditions.
• safe - The most recent crypto-economically secure block, cannot be re-orged outside of manual intervention driven by community coordination. Intuitively, this block is “unlikely” to be re-orged.
• finalized - The most recent crypto-economically secure block, that has been accepted by >2/3 of validators. Cannot be re-orged outside of manual intervention driven by community coordination. Intuitively, this block is very unlikely to be re-orged.
• earliest - The lowest numbered block the client has available. Intuitively, you can think of this as the first block created.

It looks like lotus currently supports pending and latest, explicitly doesn't support earliest and have no mention of safe or finalized.

For safe and finalized what values should we use? I woud want to defer to someone more familiar with the protocol for explaining what algorithm to use to find the appropriate "safe" and "finalized" block, then it should be a straightforward ticket to complete

[trruckerfling]

For safe and finalized what values should we use?

@aarshkshah1992 @rvagg would either of you know? TIA

[rvagg]

finalized I would say would map to Filecoin's finality @ 900 epochs behind. From what I understand, Eth doesn't have a concept of true finality, which we do.

safe is the tricky one, someone has to make a call about that. Axelar might call that 100. I suspect there's some value smaller than that which most participants would be happy with, but there's risk all the way up to 900 and suggesting that it's "safe" is going to give developers a false sense of security.

https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0089.md might be of some help, at least in the information it presents. From what I understand, there wasn't going to be an FRC-0089 implementation done for Lotus because we have F3 around the corner that would make it (mostly) irrelevant. But it would be really helpful to have an implementation of it and then dynamically adjust safe based on its output. I wonder if we could convince someone to implement this in Go for Lotus so we could poll it for this API ...

When F3 lands, this all changes, and we need to figure that out.

[Stebalien]

From what I understand, Eth doesn't have a concept of true finality, which we do.

Other way around. Eth now has a concept of true finality, we only have probabilistic (until we get F3). Although, at 900 epochs, the probability of a reorg is basically zero.