[Feature]: Add GasMetering for queries

[ValarDragon]

Summary

Right now queries can DOS nodes. Its currently left up to node operators to just disable certain query routes at higher levels of abstraction, if they want to 1: Enable queries, 2: Don't want their nodes vulnerable.

(e.g. to a TallyVote query)

To get some basic mitigation / resource protection for this by default, we should allow nodes to have a local gas limit for queries. Thus they can configure how complex of a query they are willing to provide.

Proposal

When a new query is made, that is not in consensus, setup a gas meter. Have app.toml have a new field for query gas limit.

As time goes on, we should find a solution to express the difference in cost between historic and live queries, but that can be saved for a second change.

Prior Art

I am told that query providers in Ethereum do something similar to this. Alchemy has its own "query complexity" scoring rule (distinct from gas), and charges for queries according to this metric. (And also halts processing once a query exceeds the allotted complexity)

Many RPC providers use gas directly as the metric though.

[alexanderbez]

With historical queries directly going to SS soon, I imagine we wouldn't need to really investigate the cost differences between old and live state. Perhaps queries that go against live state can have a gas meter? Not sure...but we need to think of this in the context of SS and SC separation IMO

[ValarDragon]

Gas metering for queries makes sense regardless of SS and SC though? I don't see how that changes the dynamic of wanting to measure the compute / cost done?

Agreed that measuring the difference between historic and live state isn't as near term important if were about to change that though!

[alexanderbez]

Yes, you're right gas metering should happen on both. It's difficult to have the full mental model of how all this will work. I think queries that route to SS should be significantly cheaper.