Remove gas a user facing feature of the cosmos sdk

[zmanian]

The Cosmos SDK has had a gas feature since launch that was loosely inspired by Ethereum gas features.

Gas functioned as way of helping the poorly informed Comet BFT block proposer about how to fill blocks

This feature has never worked well. The simulation function has always been unreliable.

Gas functions as defense in depth against programming mistakes by module developers that introduce states or arguments that consume large amount of resources.

The concept of gas refunds have never really worked well in the Cosmos context.

My proposal is that we remove gas as user facing concept.

Developers should set one resource bounds on their message types. They can have variants. Users might need to pick one of N gas variants and pay a higher fee for the larger variants.

Developers can choose to enable metering on a message or not on a per message basis .

[hxrts]

Not against this in principle, but it seems like the core problem is we don't have good tools for determining how to meter operations. Whether we simulate in-situ or pre-price compute, both require much better tools for benchmarking.

Notably this is kind of close to what Solana has today (computation is metered by signature only) and it looks like they're now starting to back into something that looks closer to gas metering per operation because signatures don't accurately capture compute load.

[ctrl-Felix]

Gas functions as defense in depth against programming mistakes by module developers that introduce states or arguments that consume large amount of resources.

I‘d add that gas also acts as Defense against transactions in CosmWasm smart contracts.

Removing gas on a SDK level would require a solution for CosmWasm then.

How do we avoid people from crafting complex smart contract transactions taking an eternity to compute (or simply bugs).

[zmanian]

The meter should be abstract.

It should be a multidimensional vector and not an integer.

Permissionless Cosmwasm needs some kind of meter but not really sure gas is the right one especially if want more advanced features like parallelism and write locks

[webmaster128]

Permissionless Cosmwasm needs some kind of meter but not really sure gas is the right one especially if want more advanced features like parallelism and write locks

I support this. While compute is relatively simple to map to a number, things like state usage are not. E.g. DB writes and things like DB removals are heavily underpriced these days.

[ctrl-Felix]

What does "abstract" in this context mean?

Defined by the dev(s) implementing a message?

[prasincs]

It should be a multidimensional vector and not an integer.

wouldn't this be more complicated to explain to user than gas fees that they're likely familiar with from other chains at least as a concept if not how it works. I agree that simulation hasn't quite worked well.

Permissionless Cosmwasm needs some kind of meter but not really sure gas is the right one especially if want more advanced features like parallelism and write locks

true. I don't see how removing gas as an integer helps with parallelism and write locks though, unless the write lock/parallelism is on the account. ie it'd be highly dependent on the way we decide to implement parallelism.

While compute is relatively simple to map to a number, things like state usage are not

I agree with this

[alexanderbez]

@ctrl-Felix essentially, yes. Abstract or generic in the sense the application can define the vector or metering more broadly. The SDK could provide easy to use primitives to allow this. Given that Go has generics now, this should be pretty straightforward.