Limit resource usage of state_call

[xlc]

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.

[bkchr]

We would need this: https://forum.polkadot.network/t/eliminating-pre-dispatch-weight/400 to support adding some block weight limit and aborting.

[xlc]

Without this, we need to either

• make state_call unsafe (which will cause big troubles given now custom RPCs are effectively deprecated in favor of runtime APIs)
• or ensure all runtime APIs are not DoS vector (which is not possible due to the block builder API)
• or require node to filter & whitelist the API calls to state_call.

[bkchr]

• or ensure all runtime APIs are not DoS vector (which is not possible due to the block builder API)

If you would use apply_extrinsic, it would reject the extrinsic if it would use too much weight. So, that is already "safe".

[athei]

or require node to filter & whitelist the API calls to state_call.

This would destroy the whole point of why we want to use state_call: Don't require client updates when exposing a RuntimeAPI which is not used by the client.

or ensure all runtime APIs are not DoS vector (which is not possible due to the block builder API)

I think at least none of the RuntimeAPIs are unbounded. This doesn't mean they are not a DoS vector, though. For example, the RuntimeAPI that allows to dry run with pallet-contracts takes a gas limit and the runtime author can cap this when implementing the RuntimeAPI. The problem here is that this cap is defined by the runtime and is the same for every node using the runtime. But it is a specific node (usually a public RPC node) that wants to cap or at least inspect this value to apply rate limiting or charge users on it.

This is a more general problem that arises because the node has (purposefully and by definition) no insight of what a state_call does. I think we want to keep it this way for the same reason we don't want to filter those calls in the client.

We would need this: https://forum.polkadot.network/t/eliminating-pre-dispatch-weight/400 to support adding some block weight limit and aborting.

There we are trying to solve a much harder issue: Making weights optional for actual on-chain execution where they need to be deterministic. Here we just want to limit resources of an individual node. So it doesn't need to be particularly precise or objective across nodes.

If I am not missing anything we could just add an additional parameter to state_call like resource_limit and use wasmtime's fuel metering only when using state_call. The downside is that we need to differentiate between different instances/modules in our instance cache (with and without metering). And that it will be a bit slower with metering.

Not sure if necessarily easier but we could execute the wasm code in a sub process in case of a state_call and just kill it on a timer (based on the passed resource_limit). A timer is fine here because it doesn't need to be objective. It is just for the individual node to apply rate limiting.

[xlc]

The long term solution is simple, run them on the client side in the light client and remove state_call.
But we do need a short term solution and a timer + memory limiter could be enough. It doesn’t need to be precise and deterministic. In fact, I think every single safe rpc call should be guarded with a resource limiter.

[athei]

The long term solution is simple, run them on the client side in the light client and remove state_call.

Fully agreed. RPC nodes shouldn't be a thing.

But we do need a short term solution and a timer + memory limiter could be enough. It doesn’t need to be precise and deterministic. In fact, I think every single safe rpc call should be guarded with a resource limiter.

Exactly. As you said. We don't need preciseness or determinism or even stability in numbers. So we can just come up with something that works well enough. But not sure if we should pass in memory limit. I think we create all instances with the same amount of linear pages anyways and all calls are limited by that. Having different sizes for different instances might make it more complicated. On the other hand: Allowing for different classes of instances (some with smaller memory) might allow RPC nodes to spawn more Wasm instances in parallel and utilize more cores.

[bkchr]

The long term solution is simple, run them on the client side in the light client and remove state_call.

The funny thing is that light clients are also allowed to execute runtime calls :P So, we just move the problem. Doing one execution proof is probably also much more resource efficient than executing the call on the light client and then dispatching every read (for sure depends on the number of reads).

But we do need a short term solution and a timer + memory limiter could be enough.

Jsonrpsee is already prepared for this and there is an issue for this: paritytech/polkadot-sdk#47

But not sure if we should pass in memory limit. I think we create all instances with the same amount of linear pages anyways and all calls are limited by that. Having different sizes for different instances might make it more complicated.

Part of what I'm working on this will be added, aka that you can specify the amount of memory to use for your call.

[xlc]

Light clients are only used locally so there won't be an issue. Any dapp can just run while(true) i++ and that's fine (ish).

[bkchr]

I know that light clients are only used locally. But there is a remote_call_request message that light clients are allowed to send and this is basically the same as state_call and will execute the runtime call on a full and return an execution proof of this to the light client.

[xlc]

Oh ok. I am not aware of this. I guess we really need a proper resource limitation setup. Shouldn't be too hard as I will image the wasm executor should already have this feature.