As far as I understand, introduction of gas is to avoid halt problem that exists in Turing Complete smart contract in blockchain like Ethereum. Gas can help miner to evaluate computation price in agnostic transactions processing procedure and thus can prevent DDoS.
However, in cosmos smart contract is not supported and limited different types of messages are hardcoded. There will be no indeterminate processes dealing with message and you can expect everything that may happen. As a message is hardcoded clearly, no infinite computation loop or large storage occupancy will occur. Fee is enough and no need for gas. Bitcoin is just an example.
So here I wonder why bring gas in cosmos? It is not beautiful.
There are two bottle necks to a blockchain. Computation per node, and network delay. Network delay is directly proportional to block size, hence block size limits. To measure computational bottlenecks (amount of work you must do before relaying a block / tx) you have to account for it in some way. This is the purpose of gas.
Even though we have ‘hardcoded’ messages, not at all messages induce the same amount of computation. And even within a message type, the exact amount of computation may differ.
Unlike Bitcoin, CosmosSDK apps like the hub have state storage. Different transactions can take up varying amount of state storage so we need some sort metric like gas. We can’t just use transaction size like in Bitcoin.
As far as I see, the cosmos source code only defines the number of gas for storage operations. I am not quiet understand the computation you mean here, as cosmos does not support any computationally intensive operations. The reason behind is that smart contract can not run in cosmos and a message can not be divided into atomic operations. You can set a very large gas needed without any limit at will for a newly added type of message (as I see, the amount of gas consumed is defined in message handler and is not related with anything), as long as it is accepted by validators. There is not a standard to evaluate such computation cost even after using gas design, which exists in name only.
Cosmos could work well with absence of gas. To say the least, even if in the future a type of message with high computation is accepted by network, validators could also be capable to evaluate what price they should charge to transaction sender by their own, because operations of all messages are ruled in code . We can leave it to market, and can expect it works better.
Let me restate my point: design of gas is to evaluate cost of transactions better that is hard to know in Turing-complete-smart-contract-supported blockchain. Gas is a standard for the cost evaluation system, while all opeartions is tx can be decomposed into smaller atomic operations that are indivisible units for gas calculation. A miner in Ethereum don’t know what will happen even after he deserializes a transaction, so they should evaluate its price with the help of gas mechanism. However, in cosmos a validator can clearly know the result that a certain kind of message will lead to after receiving and deserializing it. As they have alreay known the price, why should we introduce gas?
Yeah I know it. Fee can achieve what you said above and it should be kept as before. I do not intend to cancel it. My point is that gas design in cosmos is meaningless.
Currently cosmos block structure does not have any field about gas limit. Suppose I construct two transactions with the same fee such as 1 photon, but set them with different gas like 100 gas and 1million gas. What is the difference between them? The final result is that validator will get 1 photon as a transactions fee. How much the gas is has nothing to do with their decision.
Blocks actually do have a Gas limit. I don’t know if gas is currently getting communicated over ABCI though.
Additionally, gas is useful as a validator would ideally (#postlaunch) make the expected fee for a message a function of the msg size + gas. (Or even fancier, have mempool reaping be a function which attempts to maximize fees under the maximum bytes and maximum gas restrictions)