Predict when the next reward will be farmed

[abhi3700]

Background

The issue titled "Predict when the next reward will be farmed" discusses the potential to provide users (farmers) with predictions on when they can expect to receive rewards based on on-chain data regarding space pledged and the last farming reward payment timestamp. This prediction could then be displayed to the user as having a high/low probability of receiving a reward with descriptions like "today", "in about an hour", or "any time now".

Description

So, this PR adds the feature to calculate the expected time in getting the next reward (block/vote) as a part of backend.

The calculation is based on the amount of one's space pledged and total space pledged & time elapsed since the last reward timestamp.

If there is no reward payout yet, then we the current timestamp is multiplied with the inverse of contribution ratio, where contribution_ratio = total_space_pledged/space_pledged.

Details on Notion.

There are 2 main functions:

• get_total_space_pledged: This function returns the total space pledged as per your latest block available in your synced node.
• calculate_expected_reward_duration_from_now: This function returns the intended expected time to get the next reward.
  Now this function can be integrated with frontend UI.

Appendix

Here, the challenge is to fetch the current solution range, runtime constants like Slot probability.
Initially, I attempted with graphql, but due to the fact that it always lags behind 10 blocks in realtime data fetching, so switched to RPC approach using subxt crate. And then I finally switched to runtime API call as the former added technical debt.

As of 02c8c7a, the 3rd approach is implemented.

The 4th approach is:

• to get the total_space_pledged directly as runtime constants without any calculation.

[nazar-pc]

Also this seems to be some WIP version of the PR due to #[allow(dead_code)] and no UI changes

[abhi3700]

As of now, removed RPC based code (done previously using subxtcrate). Instead I replaced with runtime API call fetching current solution range value. And then calculated total_space_pledged. Pushed the code in this branch.

In order to get the total_space_pledged value directly, I pushed changes to subspace::add-tsp-runtime-api branch to declare & implement runtime APIs to subspace-runtime.
If the runtime_api implementation is correct, then I can directly access the total_space_pledged without any calculations like this:

client
        .runtime_api()
        .get_total_space_pledged(block_hash)
        .expect("Failed to get total space pledged");

replacing this

[nazar-pc]

Overall this is closer to what it should be, but there are unrelated changes in the lock file for some reason and frontend is still missing (I see you renamed the PR, but it needs to be shipped together).

In order to get the total_space_pledged value directly, I pushed changes to subspace::add-tsp-runtime-api branch to declare & implement runtime APIs to subspace-runtime.
If the runtime_api implementation is correct, then I can directly access the total_space_pledged without any calculations like this:

That will only work for fully upgraded runtime, not for older runtimes of Gemini 3h. Also as I repeated a few times already, the whole thing is a runtime constant, did you look into a way to query runtime constants are all?

[abhi3700]

....did you look into a way to query runtime constants are all?

I searched in substrate docs, paritytech docs for sp-api, etc. But couldn't find a way to query the runtime constants.
Everywhere, it was mentioned either to use RPC (via subxt) to get the runtime constant or expose the constant as a function to runtime_api, hence upgrade the runtime.

[nazar-pc]

I searched in substrate docs, paritytech docs for sp-api, etc. But couldn't find a way to query the runtime constants.

Not everything in Substrate is well documented, but since RPC does it, there is a way to query it. Not critical though.

[abhi3700]

In terms of frontend, do you think this would look nice here?

The green-colored text.

💭 Should we attach the webpage url as well, that shows rewards distributed to all the addresses?..may be block no. or so where the rewards were distributed. I guess that would require querying the synced node 🤔 .

[nazar-pc]

In terms of frontend, do you think this would look nice here?

Hard to say, but for sure not where the green text for sure. That whole area is for farms and has scrolling. Should be somewhere around tSSC. Something like this would be nice, but it would require rendering manually with plotters library, so probably tiny https://docs.gtk.org/gtk4/class.ProgressBar.html to start is sufficient, which has [pulse-step](https://docs.gtk.org/gtk4/property.ProgressBar.pulse-step.html) property.

💭 Should we attach the webpage url as well, that shows rewards distributed to all the addresses?..may be block no. or so where the rewards were distributed. I guess that would require querying the synced node 🤔 .

Don't think I understood what you wanted to say here.

[abhi3700]

Okay, I will look into it.

Don't think I understood what you wanted to say here.

I was basically suggesting a feature where a farmer could query for all an address in the rewards list. May be putting a link to the rewards page in block explorer would work. Not sure. Need to think on this.

[nazar-pc]

I was basically suggesting a feature where a farmer could query for all an address in the rewards list. May be putting a link to the rewards page in block explorer would work. Not sure. Need to think on this.

Still didn't understand what you meant. Did you try to click on the balance yet, is that what you meant?

[abhi3700]

I was basically suggesting a feature where a farmer could query for all an address in the rewards list. May be putting a link to the rewards page in block explorer would work. Not sure. Need to think on this.

Still didn't understand what you meant. Did you try to click on the balance yet, is that what you meant?

Nevermind, I get it.

[nazar-pc]

I'm closing this PR since we can't merge it as is. We can reopen it later once both frontend and backend parts are implemented, tested and organized cleanly in a state that is ready for review.