docs: adr-13 - automatic gas price estimation #4048
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| # ADR #013: Automatic Gas Price Estimation | ||
|
|
||
| ## Changelog | ||
|
|
||
| - 17.01.2024: Initial design | ||
|
|
||
| ## Status | ||
|
|
||
| Proposed | ||
|
|
||
| ## Context | ||
|
|
||
| [CIP 18](https://github.com/celestiaorg/CIPs/blob/main/cips/cip-18.md) defines an interface that a light node can use for transaction submission to retrieve an estimate of the gas price and amount of gas required to include their transaction on Celestia. This predominantly is to allow for greater dynamism during times of congestions where gas prices become greater than the global minimum. | ||
|
|
||
| This ADR defines how the go light node will interact with the service as a client. Note this does not cover how the server will actually estimate the gas prices and gas required. | ||
|
|
||
| ## Decision | ||
|
|
||
| Allow users of Celestia nodes to opt in to automatic gas price and gas usage estimation for every write method. | ||
|
|
||
| ## Detailed Design | ||
|
|
||
| ### When to estimate the gas price | ||
|
|
||
| Users can opt in to automatic price estimation by using the existing `TxConfig.isGasPriceSet`. Previously, if this was false, the `DefaultGasPrice` was used, now if a user isn't manually setting the gas price, the node will query it from the `GasEstimator` service. | ||
|
|
||
| ### When to estimate the gas required | ||
|
|
||
| Depending on the message types submitted, the node will decide whether to also query for the amount of gas that is required to submit the transaction. In the case of the following messages, the gas can be reliably estimated using a simple linear model: | ||
|
|
||
| - `MsgPayForBlob` | ||
|
|
||
| For all other messages (or combination of messages), the node will call the `GasEstimator` service. | ||
|
|
||
| ### Setting guardrails | ||
|
|
||
| A new field in the `TxConfig` will be introduced allowing for a user to use the gas price estimation but setting a maximum gas price as a cap that the user is willing to pay. If the price returned by the estimator is greater than the cap, likely due to a price spike, an error will be returned informing the user that the gas price required is currently greater than the user is willing to pay. If the user doesn't specify a cap, a hardcoded value that is 100x the default min gas price will be used (i.e. 0.2 utia). | ||
|
There was a problem hiding this comment. Can we assume that tx priority is medium in case the user wants us to use gas estimator? Otherwise, we need to add one more field specifying the priority. There was a problem hiding this comment. or we can configure the node during the startup to use some priority by default. There was a problem hiding this comment. Q: why do we need to have any limits if the user hasn't specified them? There was a problem hiding this comment. The default is medium priority - users don't have to specify it if they don't want to. I guess it should also be present in the Node API as part of the config There was a problem hiding this comment.
Out of an abundance of caution (i.e. limit the damage this can do if the GasEstimation service is faulty) There was a problem hiding this comment. I think it is worth adding that we should not use queried gas price that is less than minGasPrice |
||
|
|
||
| ### Defaults | ||
|
|
||
| By default, the same consensus node that the node is connected with, should be used as the `GasEstimator`. During construction, a user can optionally provide a grpc address that can be used instead. This will require a new config field in the `state` config that can specify addr of estimator service. | ||
|
|
||
| ## Alternative Approaches | ||
|
|
||
| There has been some discussion of a pricing mechanism built in to the protocol. This would be more complex but would remove the reliance on a trusted third party. This may be explored in the future but given resource constraints, the `GasEstimator` service has been prioritized | ||
|
|
||
| ## Consequences | ||
|
|
||
| ### Positive | ||
|
|
||
| - Light nodes should be able to automatically adjust to congestion so long as it falls under the maximum they are willing to pay. | ||
|
|
||
| ### Negative | ||
|
|
||
| - Extra round trip with either the consensus node or someone offering the `GasEstimator` service before the transaction is submitted | ||
cmwaters marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Reliance on a third party service which could become unavailable. | ||
|
|
||
| ### Neutral | ||
|
|
||
| ## References | ||
|
|
||
| - [CIP 18](https://github.com/celestiaorg/CIPs/blob/main/cips/cip-18.md) | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[quesion]
is this for full nodes? if so, how would light nodes get the estimation? would it be something like:
light node -> full node -> consensus full node gRPC? but aren't full nodes only connected to bridge nodes?
if so, should the requests pass by the bridge node?
Or, will all type of Celestia-node nodes take a consensus gRPC endpoint?
I guess that having a third party provider would make this way easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't full nodes also be connected to consensus node (or whatever the user defines as the grpc service)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we still use
gasMultiplier? Or does It assume that results will be more accurate?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Tbh, I think we should remove the
gasMultiplierand assume that is taken care of on the server side. What do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can use it only in case of a fallback solution when requesting
EstimateGaswhich simulates the transaction.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double checked and the test failed with
out of gas. So I'll keep it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think we should remove it and have it in the server side. We can just multiply the result by 1.1 on the server side