Custom getters

[xlc]

paritytech/substrate#2271

Currently we are using custom RPC to implement custom getters to avoid code duplication between runtime logic and frontend.

It is an essential feature and we simply cannot convert to Substrate Connect without this feature.

No smart contract chain is able to use Substrate connect without this.

[tomaka]

If the logic is already in the runtime, then you can declare a function with decl_runtime_apis! that invokes this logic. This should in principle add less than a hundred bytes or so per call to the size of the Wasm.
You can then call the function with state_call (the current API supported by both Substrate and smoldot) or chainHead_unstable_call (better designed but supported only by smoldot).

I don't actually know whether PolkadotJS provides a convenient way to use state_call, but in case it doesn't, it's not very difficult to use. For example if you want to call this function, you'd call something like state.call("GrandpaApi_current_set_id", "0x", <optional_block_hash>). The returned value is the SCALE-encoded SetId.

Calling functions that are declared in the runtime is the "correct" way to do this, rather than custom RPCs.
We have a network request specifically for these runtime calls, thanks to which a light client will download all the storage values accessed by the function call at once, whereas if you implemented the logic on the client side you might need a lot of round trips.
It also guarantees that, if there's a runtime upgrade that changes the logic, there's no mismatch between the logic in the runtime and the logic in the client.

If the runtime bloat of exposing these functions is too large (for example if the runtime never actually uses that function internally), we want to add in the future a different way to provide custom logic where the user of the JSON-RPC layer provides a Wasm file containing just the logic that they need.

[xlc]

ok state_call can solve my issue. will open issue on polkadot.js side for a convenient way to use it.

[wirednkod]

ok state_call can solve my issue. will open issue on polkadot.js side for a convenient way to use it.

@xlc I think maybe this is what you are searching for. (interface: api.rpc.state.call)

[xlc]

Not exactly. Instead of calling api.rpc.state.call("GrandpaApi_current_set_id", "0x", <optional_block_hash>), I would like to make it api.call.grandpa.currentSetId(<optional_block_hash>)

[tomaka]

I just realized that state_call isn't implemented in smoldot. But I think that this is just an overlook: all the code necessary to implement it is there, and I should be able to fix that quickly.

[shunjizhan]

@tomaka is there any example of state_call that has parameters? Let's say the parameter is an object whose shape is

{ data: string }

I tried something like this but didn't seem to work, I might be encoding the params incorrectly?

const encodedCallData = SCALE-encode({ data: '0xSomeData' });
const res = api.rpc.state.call('method_name', encodedCallData);

the error I got is

RPC-CORE: call(method: Text, data: Bytes, at?: BlockHash): Bytes:: -32000: Client error: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
WASM backtrace:

    0: 0x9e45 - <unknown>!rust_begin_unwind
    1: 0x8f3b - <unknown>!core::panicking::panic_fmt::h1b465604beffa55a
    2: 0x472148 - <unknown>!EVMRuntimeRPCApi_call