Wasm view functions

[kianenigma]

@xlc

We lost this nice property in the current storage based API. Most of the Substrate UI are accessing the storage directly and sometimes have to reimplement the additional calculation logic to convert them to user friendly representation. This means duplicated code between the Rust runtime logic and UI JS/TS logic. The more code, the more work, and the more bug.

This is totally the case in nomination pools point/balance logic as well. Points is almost always the same as balance, and all wallets have to re-implement it.

In the short term, we will fix it with runtime API. Long term, this could be a good excuse to try out the wasm view functions as well.

@shawntabrizi

I just wanted to note in the context of creating community standards for Wallets or other UIs to interface with, I still believe something at the level of XCM makes more sense to me.

I think this only applies to the Balance example and XCM is not so relevant for the broader use cases

@xlc

To make this working e2e, we need:

• Rust framework to create Wasm accessor functions
• Custom wasm execution env similar to the one in Chopsticks and collect all the accessed storages within a wasm function
• Some helper JS library to put everything together

Here’s an alternative: tap into the existing machinery for RPC-based storage update notifications. The runtime would be allowed to declare a set of “virtual storage items”. these are never stored anywhere and are instead “getter functions” as you said. They have a key in the trie as well, ergo a client can subscribe to them in the same way that it can subscribe to a normal storage item.