This is a forum post centred on discussion about a possible new CIP which would introduce a standardised querying interface for clients to use to estimate gas usage and gas pricing for transactions. This is designed to promote the entry of third party providers specialising in this service and competing to offer the most reliable and accurate estimations.
7 Likes
The notion of urgency, or within how many blocks does the user want their transaction to be submitted may be a useful parameter in the future but is currently left out of the original interface.
How do you think the notion of urgency should be presented in the interface in the future? Do you think it will be likely a feature that is required from the get-go?
I think the best unit to describe urgency is âwithin how many heights do you expect your transaction to be committedâ. I would likely modify the request object to allow the user to specify the urgency in blocks (with 1 being the most urgent). The response would still remain the same.
Alternatively, this could be reduced into three levels of urgency (say within 1 block, within 10 blocks, within 1000 blocks) with the response containing an estimated price for each of them
Here are some ideas around that. The probability of being included in the xth block could be more expressive. If I say, for example, that I want to be included in 1 block time, the gas estimator cannot guarantee the inclusion no matter the fee. Still, it can express the probability of being included.
For this strawman, letâs assume that the demand for the blockspace is constant and that the probability of inclusion does not change on a block-per-block basis.
With a 50% chance of being included per block, it would take ten blocks to get a 1 - (1 - 0.5)šⰠ= 0.999 % chance of being included. With that, you could create a mapping of the number of blocks and the percentage. If I want to be included within 10 Blocks, the chance of me succeeding should be >0.999% after 10 Blocks, which then means that I should pay the amount of fees that get me a 50% chance of inclusion.
Being included on average after 10 Blocks and âdefinitelyâ (>0.999% chance ) is also a difference that could be differentiated in the Interface.
Just some random bits of context in my mind.
-
Cosmos has lacked a congestion control mechanism in the fee system. In a world where fees are generally manually set by validators, the gas price API had limited utility because it would tell you the gas prices of the node you are connected to but that has no bearing on if a proposer was likely to see your transaction.
-
Osmosis became the first Cosmos chain to run an adaptive congestion control algorithm in general. EIP-1559 | Osmosis Docs . Itâs really unclear how widely cosmos tooling has adopted this mechanism and what will and wonât break under congestion.
-
Skip has been building a general congestion control system into their block SDK that was intended to be widely adopted as a module in Cosmos chain. @hxrts might be able comment more.
Alignment has been hard to reach here!
1 Like
Small update. Weâre working with Binary and Informal to upstream our EIP-1559 implementation. Weâre touching up a few things in our repo then plan to make a PR against SDK main. Tracking issue here. You can also read more about the design in this RFC.
x/feemarket doesnât have any dependency on the Block SDK if that makes things any easier.
The fact that there can be different entry criteria to a nodes mempool was something we looked at addressing with the global minimum gas price. Itâs really poor UI if one node accepts a transaction but it never reaches a proposer because they have a different criteria but in theory this is basically impossible to enforce (without trying to submit your transactions directly to the proposer). At least in practice, it seems that validators are complying and set the same default minimum gas price.
This API was intended to be a little more intelligent and consider heuristics like the price paid for the previous n blocks, the current congestion of the mempool etc. to provide estimations with âhigh confidenceâ.
I am aware that Osmosis is using an EIP 1559 styled fee mechanism and am curious to see how it is faring for them. Iâm still currently critical of EIP 1559âs effectiveness especially in the context of Celestia which isnât as concerned with state bloat and more with bandwidth (which should be independent on prior usage). Celestia should be able to run âmax speed all the timeâ.
Another factor is how the target amount gets set. There is a natural demand that will fluctuate over the life of the product. If you set the target at capacity (or too high) price will go to zero. If you set it too low, price will be higher than necessary (i.e. the net revenue will be less even if the price is higher)
Alignment has been hard to reach here!
Couldnât agree more. I am a little skeptical about being able to create a standard Cosmos wide. Maybe itâs just something within Celestia.