storage keys paged and query storage at not implemented in light client

[dvc94ch]

I can emulate query storage at by fetching each key individually, but I don't see how I can substitute storage keys paged.

[kianenigma]

I was informed in #6847 through reviews that it is intentional to not implement some of the heavy ones for the light clients. Not sure if it is the case here, just pointing out.

[dvc94ch]

Well, we can't use the light client in this case, which is a shame

[bkchr]

Hmm, the question is why do you not send the request directly to the full node?

Basically we could forward any request, but this increases the latency of the request.

[dvc94ch]

Well we're using the light client so all our requests are serialized to a string and passed to the light client task. We don't do any networking, so forwarding the request is fine. I don't see why we'd have more latency.

[bkchr]

Because you first do a RPC request to the light client which than forwards the request to a full node. While when directly connecting to a full node, you only need to send the request to one peer (less latency).

However, I'm not entirely sure what you strategy is for light clients and RPC requests.

@tomusdrw @svyatonik can someone of you shed some light on this? Do we want to support for RPC requests in the future for light clients?

[dvc94ch]

Just to explain why I opened this issue and what my expectations were:

When using the light client the expectation is that I do not need to trust the full node as the light client verifies the responses, so just forwarding the requests to a full node is not really what I'm after.

storage keys paged

hopefully the light client can make sure that the keys are produced in a deterministic order, making sure that the full node can not selectively ignore keys or reorder them and that the returned keys are part of the storage root.

query storage at

should make sure that the right value for the key and that the full node can't just return garbage for example

[tomusdrw]

I don't think we have a way to generate efficient proofs for a range of storage keys, so the RPC would essentially end up the same as querying keys one-by-one. I assume that RPCs will be supported selectively (perhaps we should document it properly somewhere?) and the decisions will be driven by:

• Proof efficiency
• Costs

I think up until when we come up with some micro-payment (or at least ranking) scheme to avoid light client leeching on full nodes we should be very careful with implementing particular RPCs for light nodes.

[svyatonik]

I'd add that "query storage" part may be implemented (quite) efficiently using changes tries. But since they're not enabled (yet?), then the only possible impl would be to query storage one-by-one.

[dvc94ch]

Since we are hoping to use the substrate networking stack as a core component of our client #7133, it no longer makes sense for us to support rpc requests to a full node at all anymore. Is there a way I can help move this issue forward?