Create an RPC / or State chain storage endpoint for the Current Stakers

[kylezs]

Currently we can fetch the current validators, but not the current stakers i.e. those who have locked up coins on the StakeManager contract and the events registered on the State Chain.

Would make it much easier to get an insight into what's happening if there were a query to get a list of current stakers and their staked balances according to the state chain.

[morelazers]

@Janislav @dandanlen is it possible to make an RPC for this? Or would we need to change some code on the State Chain to allow this to be queryable from storage?

[Janislav]

First of all, custom RPCs in combination with accessing stuff from a pallet is a bit of a PITA and even if we decide to do this, we probably need to touch the pallet anyway. I would recommend just implement a new storage item CurrentStakers which holds a list of the current stakers with their stake. You then should be able to access it over standard storage query API.

[kylezs]

That works for me, as long as it's easily available and I don't need to read an event stream and then calculate who the stakers are / what their stake is from an event stream.

[Janislav]

How do you want to access it? From PolkadotJS or with a similar library in Rust? From the state-chain, the CFE or somewhere else?

[kylezs]

For now, polka js, but maybe Rust in the future (and probably the block explorer). This ought not to change the implementation though?

[Janislav]

Okay, perfect. Shouldn't be a problem anyway - in the worst case you can make raw RPC calls (I guess).

[dandanlen]

I think the only way to do this currently is using getKeys to get the keys of the Accounts storage item in the flip pallet - this will give you the list of accounts. Then you can query each account balance to get how much is staked.

I'm not a fan of adding a dedicated storage item with a list of balances - this will require a bunch of callbacks etc to keep in sync with the real balances. Better to define a custom rpc. Rpc might be a pain, but in this case I think it's the right tool for the job.

[kylezs]

Yeah seems that way. @Janislav I'm curious to know what the pain points actually were on getting a custom RPC to work? I remember it being painful but I did have some custom RPCs working on substrate at one point when experimenting with methods of witnessing. After I had one working it was pretty easy to make others. Lack of documentation was the problem really.

[dandanlen]

Was just chatting to @andyjsbell and he made a good point that we can expose an rpc in the node without having to expose anything extra in the runtime, ie. the node rpc can call into existing runtime rpc endpoints to build up the return value. Might simplify things.

[Janislav]

There is one point that comes to mind right now... I think we always need to consider, that everything we do outside of the runtime, is not updatable via a runtime upgrade. For now, this is not an issue, but if we have a huge network one day it's much harder to update the nodes.

[kylezs]

@dandanlen @Janislav is this task recorded anywhere? If not, I'll create one

[Janislav]

No, currently not.

[kylezs]

There is now! https://app.clubhouse.io/chainflip/story/1590/create-rpc-endpoint-for-getting-the-current-stakers