Skip to content
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

Deprecate gas_adjustment in favor of new gas_multiplier setting #2353

Merged
merged 10 commits into from
Jun 30, 2022

Conversation

romac
Copy link
Member

@romac romac commented Jun 29, 2022

Closes: #2174

Description

This PR does the following: (cf. #2174 (comment))

  1. Let's deprecate gas_adjustment. The name of the setting does not properly convey what is used for imho, and its semantics (multiply the estimated gas by the value and add it to the estimation) are confusing.
  2. Instead, replace it with a gas_multiplier setting, with the following semantics: take the estimated gas and multiply it by the value of the setting.

Meaning that when we previously had gas_adjustment = 0.1, which increases the gas by 10%, we would now have gas_multiplier = 1.1.

This PR enforces a lower bound of 1.0 for the new setting but no upper bound so that people are free to use as high gas as they want.

@loredanacirstea That's perfect. Your proposal is also consistent with how cosmos sdk uses the gas-adjustment flag - as a multiplier for the gas value. #2174 (comment)

Note regarding backward incompatibility

This PR aims to hand-hold operators to use the new setting instead of the old one whenever they update to the Hermes version including these changes (1.0.0).

If an operator is still using the gas_adjustment setting in their config, they will be greeted with the following message when they try to run any command, as well as config validate:

config file specifies deprecated setting gas_adjustment for the chain 'ibc-0', instead please use the gas_multiplier setting with value 1.1

Note: the message above arises when gas_adjustment is set to 0.1 in the config of chain ibc-0.


PR author checklist:

  • Added changelog entry, using unclog.
  • Added tests: integration (for Hermes) or unit/mock tests (for modules).
  • Linked to GitHub issue.
  • Updated code comments and documentation (e.g., docs/).

Reviewer checklist:

  • Reviewed Files changed in the GitHub PR explorer.
  • Manually tested (in case integration/unit/mock tests are absent).

@romac romac force-pushed the romac/2174-gas-multiplier branch from 13592de to d39d677 Compare June 29, 2022 14:11
@romac romac force-pushed the romac/2174-gas-multiplier branch from d39d677 to e4cb25c Compare June 29, 2022 14:22
@romac romac force-pushed the romac/2174-gas-multiplier branch from 9b67d25 to 54d2899 Compare June 29, 2022 14:54
@romac romac marked this pull request as ready for review June 29, 2022 15:18
@romac romac closed this Jun 29, 2022
@romac romac reopened this Jun 29, 2022
@romac romac requested a review from ljoss17 June 29, 2022 15:19
@ljoss17 ljoss17 self-assigned this Jun 30, 2022
Comment on lines 79 to 85
let gas = if digits.len() == 1 {
// If the result fits in a u64, use that
digits[0]
} else {
// Otherwise, use u64::MAX
u64::MAX
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The case where the gas_amount is simulated to 0 will cause to have the computed gas being u64::MAX, and thus the value returned by adjust_estimated_gas to be the max_gas configured.
Is this expected ? In the case this is expected, should there be a trace warning or error to inform that the simulated gas for the tx was 0 ?

Copy link
Member Author

@romac romac Jun 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks! Fixed in b0cbc4f and added short-circuiting for when gas_amount = 0 or gas_multiplier = 1.0 in 341774d

@romac romac merged commit e3d0b10 into master Jun 30, 2022
@romac romac deleted the romac/2174-gas-multiplier branch June 30, 2022 14:58
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
…nformalsystems#2353)

# Description

This PR does the following: (cf. informalsystems#2174 (comment))

1. Let's deprecate `gas_adjustment`. The name of the setting does not properly convey what is used for imho, and its semantics (multiply the estimated gas by the value and add it to the estimation) are confusing.
2. Instead, replace it with a `gas_multiplier` setting, with the following semantics: take the estimated gas and multiply it by the value of the setting.

Meaning that when we previously had `gas_adjustment = 0.1`, which increases the gas by 10%, we would now have `gas_multiplier = 1.1`.

This PR enforces a lower bound of `1.0` for the new setting but no upper bound so that people are free to use as high gas as they want.

# Commits

* Deprecate `gas_adjustment` in favor of new `gas_multiplier` setting

* Add changelog entry

* Add tests for `adjust_gas`

* Fix `unused_variable` warning

* Improve tests

* Fix typo in test code

* Use 1.1 gas_multiplier in mock tests

* Return zero when `gas_amount` is zero, instead of max_gas

* Short-circuit when gas_amount = 0 or gas_multiplier = 1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Configuration and problems with gas_adjustment parameter
2 participants