[chain] Gas Estimations

[zivkovicmilos]

Description

This effort covers the introduction of gas estimation functionality for transactions.

Copied from an issue on the Gno repo:
For users to send transactions that will eventually be committed to the Gno chain, they essentially need to provided 2 pieces of information gas-wise:

• Gas Limit - the amount of gas (units of gas) the user is willing to pay for a given transaction to go through
• Gas Price - the amount of native currency the user is willing to pay for a single unit of gas

Currently, gas estimation is not possible for a client application interacting with gno, and therefore applications and users need to guess the gas limit. If they guess incorrectly (too low), their transaction is rejected as being underpriced.
Additionally, there is the problem of gas fees being fixed to 1GNOT (1000000ugnot), as outlined in issue #649.

Ethereum has support for gas estimations with the following RPC endpoints:

• eth_estimateGas - returns the lowest gas limit at which the transaction is successful. It finds the lowest value by doing a binary search over the gas range, and executing the transaction for each (middle) value in that range
• eth_gasPrice - returns the current average gas price for a (any) transaction, in wei. Usually, this average is implemented as a rolling average value, and is tied temporally to the node serving the call (the average is reset when the node is restarted)

Successful outcome of this effort:

• A user can estimate the minimum amount of gas their transaction will use
• A user can see the current average gas price for the network

[thehowl]

Note that at the time of writing, -gas-fee is completely ignored; you can even set it to 1ugnot. the keeper will detract 1GNOT independently of what is passed to -gas-fee (ideally, I'd say, keeper calculates a minimum gas fee for the given gas wanted, checks it against gas-fee, then detracts the value of gas-fee -- this AFAIK is part of the work being undertaken by @piux2 @deelawn)

The reason I'm writing here, though, is relating to the latest work undertaken in #1702, which improves the UX for simulating transactions on gnokey.

it seems to me that the approach you quoted @zivkovicmilos with eth_estimateGas will work well once there is enough historical data for a transaction; and one which can probably also better be provided by a transaction indexer rather than the main node, what do you think?

(I think we can still reasonably provide something like eth_gasPrice, which maps a unit of "gas" into the corresponding GNOT fee based on network congestion?)

For what concerns test4; after #1702 is merged, I propose setting up a "gas estimation system" which would work as follows:

• the -gas-wanted parameter of gnokey accepts a new format: auto and auto+<integer>, and to auto+10000 by default
  • this works only when the -simulate parameter is set to test
  • the transaction simulation is made by making a transaction with the -gas-limit set to the max gas per block (currently 10M), and executed on the node
  • auto is substituted with the amount of used gas in the simulation, and added with the value of <integer> if given
• the -gas-fee parameter of gnokey is set to 1ugnot for now
  • but eventually, once the chain actually respects this, it can be set to the value of gas wanted * gasPrice?

[zivkovicmilos]

@thehowl
I like the syntax suggestion for gnokey, I think it's gonna bump UX a lot

We need to have an estimation endpoint on the node and not (just) on the indexer because we actually want to "simulate" transactions which are unsigned, and have no specified gas values yet.
The flow here is:
client creates tx -> estimates gas -> sends transaction to node

Gas price delegation to the indexer makes sense, since this value is actually historical, while the estimation depends on the VM