Investigate expensive fork handling in Forest

[elmattic]

Describe the bug

Forest does not currently handle "expensive forks" when executing messages, which is implemented in Lotus. Without this check, RPC calls can become very slow if an expensive migration is triggered.

Forest should return an ErrExpensiveFork error in these cases, similar to Lotus, to prevent performance degradation.

Lotus uses HasExpensiveForkBetween to check if executing tipsets between specified heights would trigger an expensive migration, excluding migrations at the target height.

Forest needs to implement similar functionality.

To reproduce

1. Run Forest with RPC enabled
2. Create and send a request that will trigger such expensive fork
3. Observe slowdown

Log output

Log Output

paste log output...

Expected behaviour

For all RPC methods affected by this issue (an exhaustive list should be established first), we should trigger an error instead of performing the expensive migration.

It is up to the implementer to determine which network upgrades can be considered fast enough to avoid being included in the expensive fork list. Likely candidates would be upgrades that take no longer than 100ms.

Screenshots

Environment (please complete the following information):

• OS:
• Branch/commit
• Hardware

Other information and links

Look for Expensive: true in https://github.com/filecoin-project/lotus/blob/master/chain/consensus/filcns/upgrades.go

HasExpensiveForkBetween function: https://github.com/filecoin-project/lotus/blob/master/chain/stmgr/forks.go#L230-L237

[LesnyRumcajs]

Create and send a request that will trigger such expensive fork

How would such request look like?

[elmattic]

Create and send a request that will trigger such expensive fork

How would such request look like?

Anything that would trigger a recompute of the state, such as a Filecoin.StateCompute RPC request with the appropriate height, comes to mind.

[AlexeyKrasnoperov]

We need to verify whether Lotus behaviour is implemented on the proxy side or in the node.

[sudo-shashank]

We need to verify whether Lotus behaviour is implemented on the proxy side or in the node.

this seems to be on the node side and not lotus-gateway.