Add ExpectedRewardForPower API

[beck-8]

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.

1. Calculate the current expected income.
2. Calculate fault punishment

Describe the solution you'd like

Implement this method in the API.

Describe alternatives you've considered

No response

Additional context

No response

[rvagg]

Thanks @beck-8, we are currently attempting to avoid adding methods to the API (especially v1; we are currently considering out options for the new v2 though) where they can be replicated by using the existing methods, including loading state values through the GetActor etc. methods, similar to #11997

Although, in this case we're missing a nice wrapper around the types for network version, so in #13138 I've introduced a miner.ExpectedRewardForPower() function to help do that, but you need to load both the reward actor state and power actor state for the particular tipset you want to calculate this for to fee those values into that function.

Let me know if that solves your use case here.

[rvagg]

Also #13138 includes a lotus-shed command and the code for that demonstrates how to pull all of this info out of state from a remote which just has access to an API (as long as you're using Go)

[beck-8]

I checked the data and there is no problem.

[beck-8]

we are currently attempting to avoid adding methods to the API (especially v1; we are currently considering out options for the new v2 though)

Understand. but Providing direct API is more conducive to the convenient use of other ecological partners.
waitting v2 hhhh

[rvagg]

convenient

Yes, but the list of "convenient" APIs is very very long and the v1 API is already full of functions that are there because 1 person said that they want convenience. Each one of these we add is more complexity we have to deal with going forward - for testing, security, exposing on gateways, it's a lot.