Limit resource usage of state_call

[xlc]

Previous issue: paritytech/substrate#12698

Do we have any resource limits of making runtime API calls via state_call RPC?

For Ethereum nodes, we can submit RPC call to ask it to arbitrary EVM computation but up to some hard coded gas limit, which could be like 10x of the block gas limit. This ensures a single RPC call cannot consume too much CPU on the node.

I think we need a similar mechanism for state_call. Make it accept an optional Weight which capped to like 10x block weight limit and interrupt the wasm function call when it is taking too long.

[pepyakin]

Related: paritytech/substrate#10648

[bkchr]

Yeah, I think we should use the fuel mechanism and not weight. weight would require that we also start benchmarking the runtime apis.

[ggwpez]

Make it accept an optional Weight which capped to like 10x block weight limit and interrupt the wasm function call when it is taking too long.

We can just use a tokio timeout and kill the WASM instance? It is not deterministic, but should already prevent DoS vector.

[xlc]

That will be a simple starting point

[pepyakin]

I am not sure how that would work. Imagine that a thread enters in wasm and that wasm just loops indefinitely. When the timeout triggers it drops the future.

If you execute wasm, it is a blocking operation. That means that even if you armed a timeout, it won't ever trigger. It will elapse, but the future cannot be polled while it is blocked in the wasm code!

You can use epochs but that would be pretty involved. fuel seems the most simple option here.