Support gas and gas price estimation from third party providers

[cmwaters]

Summary

Implement a standard interface for clients to query gas and gas price from a trusted endpoint of their choosing.

Problem Definition

All clients wishing to submit transactions to the network need to obtain two things:

• An estimation of the amount of gas required to execute the transaction
• An estimation of the gas-price that will be sufficient to be included in a block.

All other aspects of signing and submission can remain local i.e. chainID, account number or sequence number.

Currently both these things can be provided if you have access to a trusted full node (which can simulate the transaction and return the global min gas price - which is sufficient in non-congested periods). This could be improved on in a few dimensions:

• Estimating the gas by simulating the execution of a transaction is a heavy procedure
• The minimum gas price is insufficient when there is congestion
• Not all nodes expose these endpoints and it may not be so simple to find endpoints that are trusted

In addition, Keplr provides some form of gas estimation but no gas price estimation. Users have to pick from "low", "medium", or "high"

Proposal

Define a standard interface where third party providers (like Celenium for example) can provide clients with an estimation of the gas price and the gas limit.

I imagine a setup where a Keplr user can use a default provider or pick their own provider for gas estimation and gas pricing. Opening this up can create competition which will help improve the accuracy of these estimations.

In a similar vein, a Celestia light node can take in an endpoint as part of the constructor and continually rely on it for transaction submission.

As merely a starting point, we could have the following API (defined using gRPC because that seems to be the most common medium in Cosmos):

service GasEstimator {
    rpc GasEstimate(GasEstimateRequest) returns (GasEstimateResponse) {}
    rpc GasPrice(GasPriceRequest) returns (GasPriceResponse) {}
}

message GasEstimateRequest {
    cosmos.tx.Tx tx = 1;
}

message GasEstimateResponse {
    uint64 gasLimit = 1;
}

message GasPriceRequest {}

message GasPriceResponse {
    double gas_price = 1;
}

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[rootulp]

Thanks for writing up this issue, sounds good to me. Out of curiosity, how confident should a user be for their transaction to be included (in N blocks) if they use the gas_price returned by GasPriceResponse (i.e. 95%, 99%, or 99.9%)?

One potential alternative for the format of GasPriceResponse is to include multiple values (i.e. gas_price_low, gas_price_medium, gas_price_high) with varying levels of guarantees. The varying levels of guarantees could be based on:

1. likelihood to be included in the next block where low (95%), medium (99%), high (99.9%)
2. expected time to inclusion where low (10 mins), medium (1 min), high (next block)

The second option is inspired by Etherscan which provides an estimate time to inclusion based on base fee and priority.

[cmwaters]

Yeah I had thought of time based estimates for when the transaction is estimated to be included which should capture a users preference to the urgency of the transaction

[evan-forbes]

is this the same as #3236 ? if so can we close one? cc @cmwaters

[rootulp]

IMO the proposal in this issue is achieved via celestiaorg/CIPs#244 so seems safe to close. #3236 tracks the celestia-app portion of implementing that CIP.