docs: adr-13 - automatic gas price estimation #4048
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| # 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. | ||
|
There was a problem hiding this comment. [quesion] 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. 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. should we still use There was a problem hiding this comment. Good point. Tbh, I think we should remove the There was a problem hiding this comment. We can use it only in case of a fallback solution when requesting There was a problem hiding this comment.
Double checked and the test failed with There was a problem hiding this comment. 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 |
||
|
|
||
| ### 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 | ||
cmwaters marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ### 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. | ||
|
There was a problem hiding this comment. Unclear what you mean by "a grpc address that can be used instead" Node has one entrypoint for tx submission and it's through a core node's gRPC. So you're saying the GasEstimator will also be available through exactly the same gRPC conn as other state-related queries we perform on the core node? There was a problem hiding this comment. My understanding is that we should provide new config field/flag for this service and try core GRPC if not specified. There was a problem hiding this comment. yes by default the consensus node will provide the There was a problem hiding this comment. So an entirely new config field in the This should be included in ADR There was a problem hiding this comment. Yeah I wasn't sure how exactly it would be implemented. Should I just add that line There was a problem hiding this comment. Is there any chance that connection with this endpoint will be secured and we'll need a tls config or xToken to communicate with? |
||
|
|
||
| ### Fallback | ||
|
|
||
| If there are any errors with interacting with the `GasEstimator` service, the node should log an error and fallback to using the minimum gas price. | ||
|
There was a problem hiding this comment. Should you propagate this error back to the user somehow? Otherwise caller will have no idea why their txs might be taking relatively long. There was a problem hiding this comment. Are there negative financial consequences for doing this fallback? Is it possible that by looping in fallback we spend much more gas then expected? If that's possible, I think we should error back to user. There was a problem hiding this comment. It's not an error to take a long time. There are other ways a user can view the progress of their transaction and with something like replace-by-fee in the future, they will even be able to boost the gas price of their transaction There was a problem hiding this comment. But utilising the fallback is unexpected behaviour. I guess maybe if it's well documented enough how the estimator works then no error returned is fine. There was a problem hiding this comment. Yeah I don't think it's unexpected if it's specified but I was conscious that it may be better to fail loudly if the estimation service is unavailable. An idea could be, in the manual submission path, allow for someone to specify the minimum that way users can easily encode that fallback. There was a problem hiding this comment. What if the error occurs after submitting the transaction( e.g There was a problem hiding this comment. Let's clarify this please @cmwaters There was a problem hiding this comment. I've come back around on this and think that we should remove the fallback. It should just error to the user in the case that their service is unavailable. |
||
|
|
||
| ## 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 | ||
cmwaters marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ### 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
|
||
|
|
||
| ### Neutral | ||
|
|
||
| ## References | ||
|
|
||
| - [CIP 18](https://github.com/celestiaorg/CIPs/blob/main/cips/cip-18.md) | ||
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.