-
Notifications
You must be signed in to change notification settings - Fork 83
feat: add MAX_GAS_ALLOWANCE_HBAR configuration #3865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -103,6 +103,7 @@ Unless you need to set a non-default value, it is recommended to only populate o | |
| `TX_DEFAULT_GAS` | "400000" | Default gas for transactions that do not specify gas. | | ||
| `USE_ASYNC_TX_PROCESSING` | "true" | Set to `true` to enable `eth_sendRawTransaction` to return the transaction hash immediately after passing all prechecks, while processing the transaction asynchronously in the background. | | ||
| `MAX_TRANSACTION_FEE_THRESHOLD` | "15000000" | Used to set the max transaction fee. This is the HAPI fee which is paid by the relay operator account. | | ||
| `MAX_GAS_ALLOWANCE_HBAR` | "0" | The maximum amount, in hbars, that the relay is willing to pay to complete the transaction in case the senders don't provide enough funds to pay for their transactions. Please note, in case of full subsidized transactions, the sender must set the gas price to `0` and the relay must configure both the `GAS_PRICE_TINY_BAR_BUFFER`, to a number big enough to cover the discrepancy between the base gas price and `0`, and the `MAX_GAS_ALLOWANCE_HBAR` parameters, with the max amount of hbars the relay is willing to spend to execute the transaction. | | ||
Neurone marked this conversation as resolved.
Show resolved
Hide resolved
Neurone marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure about setting There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The About That parameter is mentioned here only as a reference, because in case the user set gasPrice=0, a low buffer value (that is probably what you want in a classic JSON-RPC relay configuration) will block those transactions during the pre-check. So, in case an operator want to support gasPrice=0 transactions, it must update the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Exactly. I believe this is not the best UX for operators, as we are requiring them to update the unrelated There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can think about improving the operators UX in general, but probably just providing a preset of config values for the different use cases they want to achieve is enough. The BTW, the scope of this PR is very limited: it's just enable operators setting the |
||
| `USE_MIRROR_NODE_MODULARIZED_SERVICES` | null | Controls routing of Mirror Node traffic through modularized services. When set to `true`, enables routing a percentage of traffic to modularized services. When set to `false`, ensures traffic follows the traditional non-modularized flow. When not set (i.e. `null` by default), no specific routing preference is applied. As Mirror Node gradually transitions to a fully modularized architecture across all networks, this setting will eventually default to `true`. | | ||
|
||
## Server | ||
|
Uh oh!
There was an error while loading. Please reload this page.